Christopher Browne wrote:
> Geoffrey <lists at serioustechnology.com> writes:

>> So, I'm confused, but that's easy to do.  Are you saying that in the
>> version of slony we are using (1.2.14), that session_replication_role
>> does not exist, and therefore by trying to use that functionality
>> within our code, we are not accomplishing what we are trying to do?
> 
> That's nearly it.
> 
> In the version of Slony that you are using, *Slony* does not use
> session_replication_role, whether it exists in the PostgreSQL build or
> not.

I'm not thinking straight here.  It doesn't really matter if Slony uses 
session_replication_role or not.  All we want to insure is that the 
Slony triggers that are in our 'producer' still fire when we turn off 
all the other triggers in our databases.

The key issue is how do we insure that the slony triggers are created 
and set to 'enable always' in the same transaction.

It would be possible, but a burden to set up slony and set the triggers 
manually to 'enable always' while restricting access to the databases. 
The optimal solution is to be able to set up slony and get replication 
running while our databases are active.  In particular, when we have a 
process running that routinely turns off all triggers (hence the need to 
set the slony triggers to 'enable always').

-- 
Until later, Geoffrey

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