Provided by: slony1-2-doc_2.2.10-3_all 
      
    
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, even‐
       tually 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
                                                 1 November 2021                        SLONIK UNINSTALL NODE(7)