I am revisiting this issue as it seems I may have left something out of 
my slony solution.  Note from below we are trying to set the slony 
triggers to 'fire always' so that we can take advantage of 
session_replication_role.

That being said, I'm back to trying to figure out how I can be sure that 
I set the slony triggers to 'fire always' at the 'right time' so as to 
insure our replication is working.

As I understand it, we need the creation of the slony triggers and the 
setting of those triggers to 'fire always' to reside in the same 
transaction.

I hope that all makes sense, and I apologize for revisting this old 
issue.  I thought that I had addressed this concern in my scripts, but 
apparently that is not the case.

Thanks for any insight/assistance.


Christopher Browne wrote:
> Geoffrey <lists at serioustechnology.com> writes:
>> 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.
> 
> In a sense, it's *ALL* a big indirection.
> 
> Slony-I started by implementing an event management system, to get
> events propagating between the nodes.
> 
> Once you've got that, replicating data is a convenient side-effect
> :-).
> 
> Having replication working requires several things cooperating...
> 
> - The "logtrigger" triggers running on the origin collect data into
>   sl_log_*.
> 
> - You need to have a slon working against the origin, marking off SYNC
>   events every so often, which allows us to do incremental processing
>   of replication data.
> 
> - The slon process connected to the subscriber listens for SYNC
>   events, which tell it "Hey, we may have some new data for you!"
>   SYNC information allows the subscriber to identify which data to
>   look for in sl_log_*.
> 
> At the end of all that, you have replication.


-- 
Until later, Geoffrey

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