'\" -*- coding: us-ascii -*-
.if \n(.g .ds T< \\FC
.if \n(.g .ds T> \\F[\n[.fam]]
.de URL
\\$2 \(la\\$1\(ra\\$3
..
.if \n(.g .mso www.tmac
.TH "SLONIK UNINSTALL NODE" 7 "24 July 2014" "" "Slony-I 2.2.3 Documentation"
.SH NAME
UNINSTALL NODE \- Decommission Slony-I node 
.SH SYNOPSIS
'nh
.fi
.ad l
\fBUNINSTALL NODE (options);\fR \kx
.if (\nx>(\n(.l/2)) .nr x (\n(.l/5)
'in \n(.iu+\nxu
'in \n(.iu-\nxu
.ad b
'hy
.SH 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.
.TP 
\*(T<ID = ival \*(T>
Node ID of the node to uninstall.
.PP
This uses \(lqschemadocuninstallnode()\(rq [not available as a man page]. 
.PP
The difference between \fBUNINSTALL NODE\fR
and \fBDROP NODE\fR is that all \fBUNINSTALL
NODE\fR does is to remove the Slony-I configuration; it
doesn't drop the node's configuration from replication.
.SH EXAMPLE
.nf
\*(T<  UNINSTALL NODE ( ID = 2 );
    \*(T>
.fi
.SH "LOCKING BEHAVIOUR "
When dropping triggers off of application tables, this will
require exclusive access to each replicated table on the node
being discarded.
.SH "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-\fBUNINSTALL NODE\fR state of things,
and you will get error messages indicating missing OIDs [\(lq[MISSING TEXT]\(rq [not available as a man page]].
.PP
After dropping a node, you may also need to recycle
connections in your application.
.SH "SLONIK EVENT CONFIRMATION BEHAVIOUR "
Slonik does not wait for event confirmations before 
performing this command
.SH "VERSION INFORMATION "
This command was introduced in Slony-I 1.0