I can't seem to figure out what 'mechanism' actually causes replication. 
  That may be a too simplistic view of the whole process, but the bottom 
line is, I have to make sure that our manipulation of the 
'session_replication_role' is going to properly address the issue of 
insuring slony continues to replicate our data.

Is it the '_pro_cluster_logtrigger_1' trigger in the NODE 1 Database 
that is responsible for the actual replication process?

That is, if I do the following:

ALTER TABLE foo ENABLE ALWAYS TRIGGER _pro_cluster_logtrigger_1;

I'm assuming that the replication will not be interrupted as this 
trigger will always fire regardless of the 'session_replication_role' 
setting.

Another way of putting it is, is it the '*_logtrigger_1' trigger that is 
added to replicated tables responsible (directly or indirectly) for the 
actual replication of data.

I say 'directly or indirectly' as I see that this trigger runs the 
procedure _pro_cluster.logtrigger, and without looking into that 
procedure mechanism, it's possible that it has a cascading effect that 
ultimately effects the replication of data.

Please understand, I realize our current approach is not the best 
solution, but, I don't set the priorities and replication is higher on 
the list, then changing the way our application works.


-- 
Until later, Geoffrey

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
  - Benjamin Franklin