Provided by: slony1-2-doc_2.0.7-3build1_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 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

                                3 December 2011             SLONIK LOCK SET(7)