> ----- Original Message ----
> > From: Christopher Browne 
> > To: Glyn Astill 
> > Cc: slony1-general at lists.slony.info
> > Sent: Friday, 11 April, 2008 3:37:41 PM
> > Subject: Re: [Slony1-general] Triggers on slave tables
> >
> > >Once in replication I can no longer
> > > see the "replicate_users" trigger on the slave, I presume it is
> > > just dropped? 
> > Actually, you presume wrong :-).
> >
> 
 \o/ Excellent
> 
> > The triggers are not dropped; they are altered (via a direct update to
> > pg_trigger) to point them to the primary key's index rather than the
> > table.
> > 
> > That way, they can be restored when/if:
> > 
> > a) You run a DDL script, and
> > b) You decide to drop replication from the node.
> > 
> > If you add back a trigger "by hand," then you will eventually (when
> > running DDL/dropping replication) run into the problem that there will
> > be multiple instances of that trigger.  Could cause problems :-).
> >
 
 I'm thinking this did cause my last problem
 
> > There is a slonik command, "STORE TRIGGER" that can be used to
> > indicate that certain triggers *are* supposed to run on one/all nodes.
> > 
 
 I've had a peek in the docs, but do I run store trigger before or after I 
 subscribe the table? And I presume the trigger needs to be uniform across all 
 nodes too.
 
> > Note that in PostgreSQL 8..3, there is new functionality that triggers
> > can have "replication control" put on them via having an extra trigger
> > attribute and a GUC variable.  This eliminates the need to do the
> > pg_trigger trickery.
> > 
> > The support for the 8.3 functionality is nearly done in CVS HEAD which
> > will become Slony-I v2.0 Real Soon Now.
> 
 
 Very interesting, is there any estimated time frome for 2.0?
 
 





      ___________________________________________________________ 
Yahoo! For Good helps you make a difference  

http://uk.promotions.yahoo.com/forgood/