SUBSCRIBE SET — Start replication of Slony-I set
SUBSCRIBE SET (options);
Causes a node (subscriber) to start replicating a set of tables either from the origin or from another provider node, which must itself already be be an active, forwarding subscriber.
The application tables contained in the set must already exist and should ideally be empty. The current version of Slony-I will not attempt to copy the schema of the set. The replication daemon will start copying the current content of the set from the given provider and then try to catch up with any update activity that happened during that copy process. After successful subscription, the tables are guarded on the subscriber, using triggers, against accidental updates by the application.
If the tables on the subscriber are not empty, then
the COPY SET
process winds up doing more work than should be
strictly necessary:
It deletes all “old” entries in the table
Those old entries
clutter up the table until it is next
VACUUM
ed after the
subscription process is complete
The indices for the table will contain entries for the old, deleted entries, which will slow the process of inserting new entries into the index.
If you need to revise subscription information for a node, you also submit the new information using this command, and the new configuration will be propagated throughout the replication network. The normal reason to revise this information is that you want a node to subscribe to a different provider node, or for a node to become a “forwarding” subscriber so it may later become the provider for a later subscriber.
ID = ival
ID of the set to subscribe
PROVIDER = ival
Node ID of the data provider from which this node draws data.
RECEIVER = ival
Node ID of the new subscriber
FORWARD = boolean
Flag whether or not the new subscriber should store the log information during replication to make it possible candidate for the provider role for future nodes.
This uses schemadocsubscribeset( integer, integer, integer, boolean ).
This operation does not require acquiring any locks on the provider node.
On the subscriber node, it will have the effect of locking every table in the replication set. In version 1.2, exclusive locks are acquired at the beginning of the process; in earlier versions, locks were acquired implicitly as activity mandated it, which left some risk of deadlock if other applications could access the subscriber database at this time.