Provided by: slony1-2-doc_2.1.4-1ubuntu1_all bug

NAME

       UNINSTALL NODE - Decommission Slony-I node

SYNOPSIS

       UNINSTALL NODE (options);

DESCRIPTION

       Restores  all  tables  to the unlocked state, with all original user triggers, constraints
       and rules, eventually added Slony-I specific serial key columns dropped  and  the  Slony-I
       schema dropped. The node becomes a standalone database. The data is left untouched.

       ID = ival
              Node ID of the node to uninstall.

       This uses “schemadocuninstallnode()” [not available as a man page].

       The  difference between UNINSTALL NODE and DROP NODE is that all UNINSTALL NODE does is to
       remove  the  Slony-I  configuration;  it  doesn't  drop  the  node's  configuration   from
       replication.

EXAMPLE

         UNINSTALL NODE ( ID = 2 );

LOCKING BEHAVIOUR

       When  dropping  triggers  off of application tables, this will require exclusive access to
       each replicated table on the node being discarded.

DANGEROUS/UNINTUITIVE BEHAVIOUR

       If you are using connections that cache query plans (this is particularly common for  Java
       application  frameworks with connection pools), the connections may cache query plans that
       include the pre-UNINSTALL NODE state of things, and you will get error messages indicating
       missing OIDs [“[MISSING TEXT]” [not available as a man page]].

       After dropping a node, you may also need to recycle connections in your application.

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

                                         6 February 2014                 SLONIK UNINSTALL NODE(7)