MERGE SET - Merge Slony-I replication sets together
MERGE SET (options);
Merge a set of tables and sequences into another one. This function is a
workaround for the problem that it is not possible to add tables/sequences to
already-subscribed sets. One may create a temporary set, add the new objects
to that, subscribe all nodes currently subscribed to the other set to this new
one, and then merge the two together, eliminating the set ID that was being
This operation will refuse to be run if the two sets do not have exactly
the same set of subscribers.
- ID = ival
- Unique ID of the set to contain the union of the two
formerly separate sets.
- ADD ID = ival
- Unique ID of the set whose objects should be transferred
into the above set.
- ORIGIN = ival
- Current origin node for both sets.
This uses “schemadocmergeset(p_add_id integer, p_set_id integer)”
[not available as a man page].
# Assuming that node 1 is the origin of set 999 that has direct subscribers 2 and 3
SUBSCRIBE SET (ID = 999, PROVIDER = 1, RECEIVER = 2);
SUBSCRIBE SET (ID = 999, PROVIDER = 1, RECEIVER = 3);
MERGE SET ( ID = 1, ADD ID = 999, ORIGIN = 1 );
No application-visible locking should take place.
Merging takes place based on the configuration on the origin node. If a merge is
requested while subscriptions are still being processed, this can cause
in-progress subscribers' replication to break, as they'll be looking for
configuration for this set which the merge request deletes. Do not be too
quick to merge sets.
Slonik waits for the command submitted to the previous event node to be
confirmed on the specified event node before submitting this command. Slonik
will also wait for any in progress subscriptions involving the ADD ID to be
subscribed before submitting the MERGE SET command.
This command was introduced in Slony-I 1.0.5. In 1.2.1, a race condition was
rectified where the merge request would be submitted while subscriptions were
still in process on subscribers; it refuses to merge before subscriptions are