Christopher Browne wrote:

> 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.

I'm learning more then I ever wanted to about Slony. ;)  Thanks again 
Christopher for your detailed response.

What I'm trying to avoid is the situation we had the last time we tried 
setting up Slony.  At that time, we were on 7.4.19 Postgresql and we 
would 'disable all triggers' while our distributed database process did 
it's thing.  The problem was, this would cause our replication 
subscriber to get out of sync with the origin.

The expectation is that if we set the 'right slony triggers' to 'fire 
always' we can avoid this issue and take advantage of the 'SET 
session_replication_role' functionality in Postgresql 8.3, we can 
eliminate our original problem with the earlier 7.4 Postgresql.

My problem is, defining the 'right slony triggers.'

 From the perspective of Slony is it sufficient to insure the 
'logtrigger' triggers fire?  As those are the only triggers I see on the 
replicated tables, I assume that is the case.  You know what they say 
about assumptions though.


-- 
Until later, Geoffrey

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