SUBSCRIBE SET --  Start replication of Slony-I set


SUBSCRIBE SET (options);


This performs one of two actions:

ID = ival

ID of the set to subscribe


Node ID of the data provider from which this node draws data.


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. Any node that is intended to be a candidate for FAILOVER must have FORWARD = yes.

This uses schemadocsubscribeset( integer, integer, integer, boolean ).


   ID = 1,
   PROVIDER = 1,
   RECEIVER = 3,

Forwarding Behaviour

The FORWARD=boolean flag indicates whether the subscriber will store log information in tables sl_log_1 and sl_log_2. Several implications fall from this...

By storing the data in these tables on the subscriber, there is some additional processing burden. If you are certain that you would never want to SLONIK MOVE SET or SLONIK FAILOVER to a particular subscriber, it is worth considering turning off forwarding on that node.

There is, however, a case where having forwarding turned off opens up a perhaps-unexpected failure condition; a rule of thumb should be that all nodes that connect directly to the origin should have forwarding turned on. Supposing one such "direct subscriber" has forwarding turned off, it is possible for that node to be forcibly lost in a case of failover. The problem comes if that node gets ahead of other nodes.

Let's suppose that the origin, node 1 is at SYNC number 88901, a non-forwarding node, node 2 has processed up to SYNC 88897, and other forwarding nodes, 3, 4, and 5, have only processed data up to SYNC 88895. At that moment, the disk system on the origin node catches fire. Node 2 has the data up to SYNC 88897, but there is no remaining node that contains, in sl_log_1 or sl_log_2, the data for SYNCs 88896 and 88897, so there is no way to bring nodes 3-5 up to that point.

At that point, there are only two choices: To drop node 2, because there is no way to continue managing it, or to drop all nodes but 2, because there is no way to bring them up to SYNC 88897.

That dilemma may be avoided by making sure that all nodes directly subscribing to the origin have forwarding turned on.

Dangerous/Unintuitive Behaviour

Locking Behaviour

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.

Version Information

This command was introduced in Slony-I 1.0