SLONIK LOCK SET(7) Slony-I 2.2.6 Documentation SLONIK LOCK SET(7)
NAME
LOCK SET - Guard Slony-I replication set to prepare for MOVE SET
SYNOPSIS
LOCK SET (options);
DESCRIPTION
Guards a replication set against client application updates in preparation for a SLONIK
MOVE SET(7) command.
This command must be the first in a possible statement group (try). The reason for this is
that it needs to commit the changes made to the tables (adding a special trigger function)
before it can wait for every concurrent transaction to finish. At the same time it cannot
hold an open transaction to the same database itself since this would result in blocking
itself forever.
Note that this is a locking operation, which means that it can get stuck behind other
database activity.
The operation waits for transaction IDs to advance in order that data is not missed on the
new origin. Thus, if you have long-running transactions running on the source node, this
operation will wait for those transactions to complete. Unfortunately, if you have anoth‐
er database on the same postmaster as the origin node, long running transactions on that
database will also be considered even though they are essentially independent.
ID = ival
ID of the set to lock
ORIGIN = ival
Node ID of the current set origin
This uses “schemadoclockset(p_set_id integer)” [not available as a man page].
EXAMPLE
LOCK SET (
ID = 1,
ORIGIN = 3
);
LOCKING BEHAVIOUR
Exclusive locks on each replicated table will be taken out on the origin node, and trig‐
gers are added to each such table that reject table updates.
SLONIK EVENT CONFIRMATION BEHAVIOUR
Slonik does not wait for event confirmations before performing this command.
This command was introduced in Slony-I 1.0
21 September 2017 SLONIK LOCK SET(7)