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 another 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 triggers 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