In PostgreSQL version 8.3, new functionality was added where triggers and rules may have their behaviour altered via ALTER TABLE, to specify the following alterations:
DISABLE TRIGGER trigger_name
ENABLE TRIGGER trigger_name
ENABLE REPLICA TRIGGER trigger_name
ENABLE ALWAYS TRIGGER trigger_name
DISABLE RULE rewrite_rule_name
ENABLE RULE rewrite_rule_name
ENABLE REPLICA RULE rewrite_rule_name
ENABLE ALWAYS RULE rewrite_rule_name
A new GUC variable, session_replication_role controls whether the session is in origin, replica, or local mode, which then, in combination with the above enabling/disabling options, controls whether or not the trigger function actually runs.
We may characterize when triggers fire, under Slony-I replication, based on the following table; the same rules apply to PostgreSQL rules.
Table 4-1. Trigger Behaviour
|Trigger Form||When Established||Log Trigger||denyaccess Trigger||Action - origin||Action - replica||Action - local|
|DISABLE TRIGGER||User request||disabled on subscriber||enabled on subscriber||does not fire||does not fire||does not fire|
|ENABLE TRIGGER||Default||enabled on subscriber||disabled on subscriber||fires||does not fire||fires|
|ENABLE REPLICA TRIGGER||User request||inappropriate||inappropriate||does not fire||fires||does not fire|
|ENABLE ALWAYS TRIGGER||User request||inappropriate||inappropriate||fires||fires||fires|
There are, correspondingly, now, several ways in which Slony-I interacts with this. Let us outline those times that are interesting:
Before replication is set up, every database starts out in "origin" status, and, by default, all triggers are of the ENABLE TRIGGER form, so they all run, as is normal in a system uninvolved in replication.
When a Slony-I subscription is set up, on the origin node, both the
denyaccesstriggers are added, the former being enabled, and running, the latter being disabled, so it does not run.
From a locking perspective, each SLONIK SET ADD TABLE request will need to briefly take out an exclusive lock on each table as it attaches these triggers, which is much the same as has always been the case with Slony-I.
On the subscriber, the subscription process will add the same triggers, but with the polarities "reversed", to protect data from accidental corruption on subscribers.
From a locking perspective, again, there is not much difference from earlier Slony-I behaviour, as the subscription process, due to running TRUNCATE, copying data, and altering table schemas, requires extensive exclusive table locks, and the changes in trigger behaviour do not change those requirements.
If you restore a backup of a Slony-I node (taken by pg_dump or any other method), and drop the Slony-I namespace, this now cleanly removes all Slony-I components, leaving the database, including its schema, in a "pristine", consistent fashion, ready for whatever use may be desired.
Section 3.2 is now performed in quite a different way: rather than altering each replicated table to "take it out of replicated mode", Slony-I instead simply shifts into the local status for the duration of this event.
On the origin, this deactivates the
On each subscriber, this deactivates the
At the time of invoking SLONIK MOVE SET against the former origin, Slony-I must transform that node into a subscriber, which requires dropping the
locksettriggers, disabling the
logtriggertriggers, and enabling the
At about the same time, when processing SLONIK MOVE SET against the new origin, Slony-I must transform that node into an origin, which requires disabling the formerly active
denyaccesstriggers, and enabling the
From a locking perspective Slony-I will need to take out exclusive locks to disable and enable the respective triggers.
Similarly to SLONIK MOVE SET, SLONIK FAILOVER transforms a subscriber node into an origin, which requires disabling the formerly active
denyaccesstriggers, and enabling the
logtriggertriggers. The locking implications are again, much the same, requiring an exclusive lock on each such table.