Christopher Browne wrote:
> Geoffrey <lists at serioustechnology.com> writes:
>> 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.
> 
> Note that this is only the case with Slony-I version 2.0, which hasn't
> yet been officially released.  (We've had rc2; I should "bake" rc3
> this afternoon so we can hopefully finalize 2.0.0 next week...)
> 
> With versions 1.0, 1.1, 1.2 (and sub-versions under that), it is
> necessary to handle the "fire always" triggers via the slonik STORE
> TRIGGER command (which disappears in v2.0).
> 
> So, if you're using the earlier versions of Slony-I, then
> session_replication_role isn't of any use; it didn't exist then, so
> isn't used in the earlier versions.

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?

The underlying issue here is that we have a process that transfers data 
from many databases to a master database on a regular basis.  In order 
to accomplish this, this process does:

  $rvalue = session_role ($conn[$x], "session","replica");

With the intent of turning off all triggers except for those that are 
set 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