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
This command was introduced in Slony-I 1.0