Geoffrey <lists at serioustechnology.com> writes:
> Andrew Sullivan wrote:
>> On Thu, Jun 05, 2008 at 01:43:44PM -0400, Geoffrey wrote:
>>> I think I get the gist of this command, but I'm wondering if I'm
>>> missing something.  If I add a trigger to a slave after slony has
>>> been set up, but before any of the nodes have been subscribed, does
>>> slony still stop that trigger from firing?
>> No, subscribe the nodes first.  You don't want your trigger firing
>> on every
>> row that the subscription copies over!
>
> Good point.  Question though, do I still need the STORE TRIGGER
> command in this situation?  That is, if I add new triggers to the
> slave database after I've started replicating, does slony stop those
> triggers from firing?

It is useful to look at this from a "mechanical" perspective, that is,
from the basis of what Slony-I does.

The control that Slony-I imposes on triggers is as follows:

- When you run SET ADD TABLE against an origin node, Slony-I Slony-I runs
  alterTableForReplication() against each table.  This adds a function
  to each table to run the logtrigger() function.  Not directly
  germaine, but I'm being systematic, which means there should be
  fewer additional questions that need to be asked :-).

- When SUBSCRIBE SET runs on the subscriber, Slony-I runs
  alterTableForReplication() against each table.  (Just like on the
  origin.)

  Unlike on the origin, this does two things:
   - Adds the "denyaccess" trigger
   - Disables any triggers not declared via STORE TRIGGER and
     stored in the table sl_trigger.

- UNSUBSCRIBE SET / DROP NODE run alterTableRestore() against each
  table, which undoes the above (differing between origin + subscriber)

- EXECUTE SCRIPT does the following:
    - Runs alterTableRestore() against each table, putting things
      back into "original state," then
    - Runs the DDL script, then
    - Runs alterTableForReplication() against each table to put things
      back into 'replication mode'

This thus indicates 4 times when something can happen that will cause
Slony-I to "fiddle around" with the triggers.

If you add triggers to a subscriber after you start replicating, then
those triggers will immediately start to work as soon as you apply
them.

The "surprising" situation that could happen is that if you run a DDL
script the next day, those triggers will get shut off by
alterTableForReplication() at the end of the DDL script.

You may avoid that surprise by running STORE TRIGGER to indicate that
the trigger should be kept turned on.

Note that it is not important *when* you run STORE TRIGGER; you can
run it before the trigger exists, and that won't cause any problem.
Just be sure to run it before you run DDL or mess about with
subscriptions :-).

Note also that in v2.0, STORE TRIGGER goes away because there is a
much better "native" feature in PG 8.3 to allow for automating
activation/de-activation.

Given those 4 "times when things can happen," hopefully that allows
you to reason about what is going on.  That tends to be more useful
than taking a trajectory around the matter by needing to ask "20
questions :-)."
-- 
select 'cbbrowne' || '@' || 'linuxdatabases.info';
http://linuxdatabases.info/info/multiplexor.html
"It's a pretty rare beginner who isn't clueless.  If beginners weren't
clueless, the infamous Unix learning cliff wouldn't be a problem."
-- david parsons