Provided by: slony1-doc_1.2.15-1_all bug
 

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)