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 preparation for a SLONIK MOVE SET(7) com‐
       mand.

       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 data‐
       base 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(p_set_id integer)” [not available as a man page].

EXAMPLE

       LOCK SET (
          ID = 1,
          ORIGIN = 3
       );

LOCKING BEHAVIOUR

       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.

SLONIK EVENT CONFIRMATION BEHAVIOUR

       Slonik does not wait for event confirmations before performing this command.

VERSION INFORMATION

       This command was introduced in Slony-I 1.0

                                                19 September 2024                             SLONIK LOCK SET(7)