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