Provided by: slony1-2-doc_2.2.11-4_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

                                                  28 July 2024                          SLONIK UNINSTALL NODE(7)