Provided by:
slony1-doc_1.2.15-1_all 
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 prepara‐
tion for a 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 ta‐
bles (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 [“Locking Issues” [not available as a man
page]] 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 trans‐
actions 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( integer )” [not available as a man page].
EXAMPLE
LOCK SET (
ID = 1,
ORIGIN = 3
);
Exclusive locks on each replicated table will be taken out on the ori‐
gin node, and triggers are added to each such table that reject table
updates.
This command was introduced in Slony-I 1.0
17 November 2008 LOCK SET(7)