Provided by: slony1-doc_1.2.22-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
       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 ["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
       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( 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
       origin node, and triggers are added to  each  such  table  that  reject
       table updates.


       This command was introduced in Slony-I 1.0

                                9 December 2010             SLONIK LOCK SET(7)