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


        LOCK SET - Guard Slony-I replication set to prepare for MOVE SET


        LOCK SET (options);


        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
        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].


        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
        This command was introduced in Slony-I 1.0
                                17 November 2008                    LOCK SET(7)