---
name: "SLONIK_UNINSTALL_NODE"
section: "7"
platform: "linux"
package: "slony1-2-doc"
version: "2.2.11-6"
release: "Debian 13 (Trixie)"
platforms: ["linux"]
url: "https://new.carta.tech/SLONIK_UNINSTALL_NODE"
---

# SLONIK\_UNINSTALL\_NODE(7)

Decommission Slony-I node

## NAME

UNINSTALL NODE - Decommission Slony-I node

## SYNOPSIS

FC**UNINSTALL NODE (options);**F\[0\]

## 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.

- FCID = ival F\[0\]

  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

```
FC  UNINSTALL NODE ( ID = 2 );
    F[0]
```

## 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