Glyn Astill <glynastill at yahoo.co.uk> writes:
> When a table on a slave is put into slony replication, what happens
> to the driggers on the table?
>
> E.g I have a table "replicated_users" on each server and the table
> has a trigger "replicate_users". Once in replication I can no longer
> asee the "replicate_users" trigger on the slave, I presume it is
> just dropped? At the moment I'm just recreating the trigger after
> putting the table into replication, however I wondered if this could
> cause any problems?
>
> I guess it would be better to create a slonik script to create the
> tables with execute_script, then subscribe them, and then add int he
> triggers with execute_script?

Actually, you presume wrong :-).

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

There is a slonik command, "STORE TRIGGER" that can be used to
indicate that certain triggers *are* supposed to run on one/all nodes.

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.
-- 
output = ("cbbrowne" "@" "linuxfinances.info")
http://www3.sympatico.ca/cbbrowne/x.html
"IBM may have originated Not Invented Here, but Microsoft has managed
to squander their mountain of technical talent by not harvesting prior
art until the rain of flaming hardware makes it difficult for the
executives to drive to the Redmond campus.)" -- david parsons