Man Linux: Main Page and Category List


       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

                                  12 May 2010               SLONIK LOCK SET(7)