# Slonik Command Summary

## Index

- Introduction
- General outline
- Commands affecting Slonik
  - CLUSTER NAME
  - ADMIN CONNINFO
  - ECHO
  - EXIT
- Configuration and Action commands
  - INIT CLUSTER
  - STORE NODE
  - DROP NODE
  - UNINSTALL NODE
  - RESTART NODE
  - STORE PATH
  - DROP PATH
  - STORE LISTEN
  - DROP LISTEN
  - TABLE ADD KEY
  - CREATE SET
  - DROP SET
  - MERGE SET
  - SET ADD TABLE
  - SET ADD SEQUENCE
  - SET DROP TABLE
  - SET DROP SEQUENCE
  - SET MOVE TABLE
  - SET MOVE SEQUENCE
  - STORE TRIGGER
  - DROP TRIGGER
  - SUBSCRIBE SET
  - UNSUBSCRIBE SET
  - LOCK SET
  - UNLOCK SET
  - MOVE SET
  - FAILOVER
  - EXECUTE SCRIPT
  - WAIT FOR EVENT
  - REPAIR CONFIG

## Introduction

Slonik is a commandline utility designed specifically to setup and modify configurations of the Slony-I replication system.

This document is meant as a developer syntax-booklet, not as a manual on how to configure and set up a replication system.

Back to Index

## General outline

The slonik commandline utility is supposed to be used embedded into shell scripts and reads commands from files or stdin (via here documents for example). Nearly all of the real configuration work is done by calling stored procedures after loading the Slony-I support base into a database. You may find documentation for those procedures in the Slony-I Schema Documentation , as well as in comments associated with them in the database.

Slonik was created because:

- The stored procedures have special requirements as to on which particular node in the replication system they are called,
- the lack of named parameters for stored procedures makes it rather hard to do this from the psql prompt, and
- psql lacks the ability to maintain multiple connections with open transactions.

### Commands

The slonik command language is format free. Commands begin with keywords and are terminated with a semicolon. Most commands have a list of parameters, some of which have default values and are therefore optional. The parameters of commands are enclosed in parentheses. Each option consists of one or more keywords, followed by an equal sign, followed by a value. Multiple options inside the parentheses are separated by commas. All keywords are case insensitive. The language should remind the reader of SQL.

Option values may be:

- integer values
- string literals enclosed in single quotes
- boolean values {TRUE|ON|YES} or {FALSE|OFF|NO}
- keywords for special cases

### Comments

Comments begin at a hash sign (#) and extend to the end of the line.

### Command groups

Commands can be combined into groups of commands with optional on error and on success conditionals. The syntax for this is:
try {
<commands>
}
[on error { <commands> }]
[on success { <commands> }]
Those commands are grouped together into one transaction per participating node.

Back to Index

## Commands affecting Slonik

The following commands must appear as a "preamble" at the very top of every slonik command script. They do not cause any direct action on any of the nodes in the replication system, but affect the execution of the entire script.

### CLUSTER NAME

### Synopsis:

CLUSTER NAME = <string>;

### Description:

Must be the very first command in every slonik script. Defines the namespace in which all Slony-I specific functions, procedures, tables and sequences are defined. The namespace name is built by prefixing the given string literal with an underscore. This namespace will be identical in all databases that participate in the same replication group.

No user objects are supposed to live in this namespace and the namespace is not allowed to exist prior to adding a database to the replication system. Thus, if you add a new node using `pg_dump -s` on a database that is already in the cluster of replicated databases, you will need to drop the namespace via the SQL command `DROP SCHEMA _testcluster CASCADE;` .

### Example:

CLUSTER NAME = 'testcluster';

Back to Index

### ADMIN CONNINFO

### Synopsis:

NODE <ival> ADMIN CONNINFO = <string>;

### Description:

Describes how the slonik utility can reach a nodes database in the cluster from where it is run (likely the DBA's workstation). The conninfo string is the string agrument given to the PQconnectdb() libpq function. The user as to connect must be the special replication superuser, as some of the actions performed later may include operations that are strictly reserved for database superusers by PostgreSQL.

The slonik utility will not try to connect to the databases unless some subsequent command requires the connection.

Note: As mentioned in the original documents, Slony-I is designed as an enterprise replication system for data centers. It has been assumed throughout the entire development that the database servers and administrative workstations involved in replication and/or setup and configuration activities can use simple authentication schemes like `trust`. Alternatively, libpq can read passwords from `.pgpass` .

Note: If you need to change the DSN information for a node, as would happen if the IP address for a host were to change, you may submit the new information using this command, and that configuration will be propagated. Existing `slon` processes will need to be restarted in order to become aware of the configuration change.

### Example:

NODE 1 ADMIN CONNINFO = 'dbname=testdb host=server1 user=slony';

Back to Index

### ECHO

### Synopsis:

ECHO <string>;

### Description:

Prints the string literal on standard output.

### Example:

ECHO 'Node 1 initialized successfully';

Back to Index

### EXIT

### Synopsis:

EXIT [-]<ival>;

### Description:

Terminates script execution immediately, rolling back every open transaction on all database connections. The slonik utility will return the given value as its program termination code.

### Example:

EXIT 0;

Back to Index

## Configuration and Action commmands

### INIT CLUSTER

### Synopsis:

INIT CLUSTER ( <options> );

### Description:

Initialize the first node in a new Slony-I replication cluster. The initialization process consists of creating the cluster namespace, loading all the base tables, functions, procedures and initializing the node.

For this process to work, the SQL scripts of the Slony-I system must be installed on the DBA workstation (the computer currently executing the slonik utility), while on the system where the node database is running the shared objects of the Slony-I system must be installed in the PostgreSQL library directory. Also the procedural language PL/pgSQL is assumed to be installed in the target database already.

ID = <ival> | The unique, numeric ID number of the node. This MUST be 1.
COMMENT = <string> | A descriptive text added to the node entry in the table sl_node.

### Example:

INIT CLUSTER (
ID = 1,
COMMENT = 'Node 1'
);

Back to Index

### STORE NODE

### Synopsis:

STORE NODE ( <options> );

### Description:

Initialize a new node and add it to the configuration of an existing cluster.

The initialization process consists of creating the cluster namespace in the new node (the database itself must already exist), loading all the base tables, functions, procedures and initializing the node. The existing configuration of the rest of the cluster is copied from the event node.

The same installation requirements as for the init cluster command apply.

ID = <ival> | The unique, numeric ID number of the new node.
COMMENT = <string> | A descriptive text added to the node entry in the table sl_node.
SPOOLNODE = <boolean> | Specifies that the new node is a virtual spool node for file archiving of replication log. If true slonik will not attempt to initialize a database with the replication schema.
EVENT NODE = <ival> | (Optional) The ID of the node used to create the configuration event that tells all existing nodes about the new node. Default value is 1.

### Example:

STORE NODE (
ID = 2,
COMMENT = 'Node 2'
);

Back to Index

### DROP NODE

### Synopsis:

DROP NODE ( <options> );

### Description:

Drop a node. This command removes the specified node entirely from the replication systems configuration. If the replication daemon is still running on that node (and processing events), it will attempt to uninstall the replication system and terminate itself.

ID = <ival> | Node ID of the system to remove.
EVENT NODE = <ival> | Node ID of the system to generate the event.

### Example:

DROP NODE (
ID = 2
);

Back to Index

### UNINSTALL 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 system to uninstall.

### Example:

UNINSTALL NODE (
ID = 3
);

Back to Index

### RESTART NODE

### Synopsis:

RESTART NODE <ival>;

### Description:

Causes an eventually running replication daemon on the specified node to shutdown and restart itself. Theoretically this command should be obsolete. In practice, TCP timeouts can delay critical configuration changes to actually happen in the case where a former forwarding node failed and needs to be bypassed by subscribers.

### Example:

RESTART NODE 2;

Back to Index

### STORE PATH

### Synopsis:

STORE PATH ( <options> );

### Description:

Configures how the replication daemon of one node connects to the database of another node. If the replication system is supposed to use a special backbone network segment, this is the place to user the special IP addresses or hostnames. An existing configuration can be overwritten.

The conninfo string must contain all information to connect to the database as the replication superuser. The names server or client have nothing to do with the particular role of a node within the cluster configuration. It should be simply viewed as "the server has the message or data that the client is supposed to get". For a simple 2 node setup, paths into both directions must be configured.

It does not do any harm to configure path information from every node to every other node (full cross product). The connections are not established unless they are required to actually transfer events or confirmations because of listen entries or data because of subscriptions.

SERVER = <ival> | Node ID of the database to connect to.
CLIENT = <ival> | Node ID of the replication daemon connecting.
CONNINFO = <string> | PQconnectdb() argument to establish the connection.
CONNRETRY = <ival> | (Optional) Number of seconds to wait before another attempt to connect is made in case the server is unavailable. Default is 10.

### Example:

STORE PATH (
SERVER = 1,
CLIENT = 2,
CONNINFO = 'dbname=testdb host=server1 user=slony'
);

Back to Index

### DROP PATH

### Synopsis:

DROP PATH ( <options> );

### Description:

Remove the connection information between server and client.

SERVER = <ival> | Node ID of the server of this connection.
CLIENT = <ival> | Node ID of the client.
EVENT NODE = <ival> | (Optional) The ID of the node used to create the configuration event that tells all existing nodes about dropping the path. Defaults to the client.

### Example:

DROP PATH (
SERVER = 1,
CLIENT = 2
);

Back to Index

### STORE LISTEN

### Synopsis:

STORE LISTEN ( <options> );

### Description:

A listen entry causes a node (receiver) to query an event provider for events that originate from a specific node, as well as confirmations from every existing node. It requires a path to exist so that the receiver (as client) can connect to the provider (as server).

Every node in the system must listen for events from every other node in the system. As a general rule of thumb, a subscriber (see SUBSCRIBE SET) should listen for events of the set's origin on the same provider, where it receives the data from. In turn, the origin of the data set should listen for events from the origin in the opposite direction. A node can listen for events from one and the same origin on different providers at the same time. However, to process SYNC events from that origin, all data providers must have the same or higher sync status, so this will not result in any faster replication behaviour.

ORIGIN = <ival> | ID of the event origin the receiver is listening for.
PROVIDER = <ival> | (Optional) ID of the node from which the receiver gets events from the origin. Default is the origin.
RECEIVER = <ival> | ID of the node receiving the events.

### Example:

STORE LISTEN (
ORIGIN = 1,
RECEIVER = 2,
);

Back to Index

### DROP LISTEN

### Synopsis:

DROP LISTEN ( <options> );

### Description:

Remove a listen configuration entry.

ORIGIN = <ival> | ID of the event origin the receiver is listening for.
PROVIDER = <ival> | (Optional) ID of the node from which the receiver gets events from the origin. Default is the origin.
RECEIVER = <ival> | ID of the node receiving the events.

### Example:

DROP LISTEN (
ORIGIN = 1,
RECEIVER = 2,
);

Back to Index

### TABLE ADD KEY

### Synopsis:

TABLE ADD KEY ( <options> );

### Description:

In the Slony-I replication system, every replicated table is required to have at least one UNIQUE constraint who's columns are declared `NOT NULL.` Any primary key satisfies this requirement.

As a last resort, this command can be used to add such an attribute to a table that does not have a primary key. Since this modification can have unwanted side effects, it is strongly recommended that users add a unique and not null attribute by other means.

NODE ID = <ival> | ID of the set origin where the table will be added as set member (See SET ADD TABLE).
FULLY QUALIFIED NAME = <string> | The full name of the table consisting of the schema and table name as the expression quote_ident(nspname) || '.' || quote_ident(relname) would return it.

### Example:

TABLE ADD KEY (
NODE ID = 1,
FULLY QUALIFIED NAME = 'public.history'
);

Back to Index

### CREATE SET

### Synopsis:

CREATE SET ( <options> );

### Description:

In the Slony-I replication system, replicated tables are organized in sets. As a general rule of thumb, a set should contain all the tables of one application, that have relationships. In a well designed application, this is equal to all the tables in one schema.

The smallest unit one node can subscribe for replication from another node is a set. A set always has an origin. In classical replication terms, that would be the "master." Since in Slony-I a node can be the "master" over one set, while receiving replication data in the "slave" role for another at the same time, this terminology may easily become misleading and should therefore be replaced with set origin and subscriber.

ID = <ival> | Unique ID of the set to be created.
ORIGIN = <ival> | Initial origin of the set.
COMMENT = <string> | A descriptive text added to the set entry.

### Example:

CREATE SET (
ID = 1,
ORIGIN = 1,
COMMENT = 'Tables of ticket system'
);

Back to Index

### DROP SET

### Synopsis:

DROP SET ( <options> );

### Description:

Drop a set of tables from the Slony-I configuration. This automatically unsubscribes all nodes from the set and restores the original triggers and rules on all subscribers.

ID = <ival> | Unique ID of the set to be dropped.
ORIGIN = <ival> | The current origin of the set.

### Example:

DROP SET (
ID = 5,
ORIGIN = 1
);

Back to Index

### MERGE SET

### Synopsis:

MERGE SET ( <options> );

### Description:

Merge a set of tables and sequences into another one. This function is a workaround for the problem that it is not possible to add tables/sequences to already-subscribed sets. One may create a temporary set, add the new objects to that, subscribe all nodes currently subscribed to the other set to this new one, and then merge the two together.

This request will fail if the two sets do not have exactly the same set of subscribers.

ID = <ival> | Unique ID of the set to contain the union of the two separate sets.
ADD ID = <ival> | Unique ID of the set whos objects should be transferred.
ORIGIN = <ival> | The current origin of the two sets.

### Example:

MERGE SET (
ID = 2,
ADD ID = 9999,
ORIGIN = 1
);

Back to Index

### SET ADD TABLE

### Synopsis:

SET ADD TABLE ( <options> );

### Description:

Add an existing user table to a replication set. The set cannot currently be subscribed by any other node - that functionality is supported by the`MERGE SET` command.

SET ID = <ival> | ID of the set to which the table is added.
ORIGIN = <ival> | The current origin of the set. A future version of slonik might figure out this information by itself.

ID = <ival>

Unique ID of the table. These ID's are not only used to uniquely identify the individual table within the replication system. The numeric value of this ID also determines the order in which the tables are locked in a LOCK SET command for example. So these numbers should represent any applicable table hierarchy to make sure the slonik command scripts do not deadlock at any critical moment.

FULLY QUALIFIED NAME = <string> | The full table name as described in TABLE ADD KEY.
KEY = { <string> | SERIAL } | (Optional) The index name that covers the unique and not null column set to be used as the row identifier for replication purposes. Or the keyword SERIAL to use the special column added with a previous TABLE ADD KEY command. Default is to use the table's primary key. The index name is not fully qualified; you must omit the namespace.
COMMENT = <string> | A descriptive text added to the Slony-I configuration data.

### Example:

SET ADD TABLE (
SET ID = 1,
ORIGIN = 1,
ID = 20,
FULLY QUALIFIED NAME = 'public.tracker_ticket',
COMMENT = 'Support ticket'
);

Back to Index

### SET ADD SEQUENCE

### Synopsis:

SET ADD SEQUENCE ( <options> );

### Description:

Add an existing user sequence to a replication set. The set cannot currently be subscribed by any other node - that functionality is supported by the MERGE SET command.

SET ID = <ival> | ID of the set to which the sequence is added.
ORIGIN = <ival> | The current origin of the set. A future version of slonik might figure out this information by itself.
ID = <ival> | Unique ID of the sequence.
FULLY QUALIFIED NAME = <string> | The full sequence name as described in TABLE ADD KEY.
COMMENT = <string> | A descriptive text added to the Slony-I configuration data.

### Example:

SET ADD SEQUENCE (
SET ID = 1,
ORIGIN = 1,
ID = 21,
FULLY QUALIFIED NAME = 'public.tracker_ticket_id_seq',
COMMENT = 'Support ticket id sequence'
);

Back to Index

### SET DROP TABLE

### Synopsis:

SET DROP TABLE ( <options> );

### Description:

Drop an existing user table to a replication set.

Note that this action will not drop a candidate primary key created using `TABLE ADD KEY` .

ORIGIN = <ival> | The current origin of the set. A future version of slonik might figure out this information by itself.
ID = <ival> | Unique ID of the table.

### Example:

SET DROP TABLE (
ORIGIN = 1,
ID = 20,
);

Back to Index

### SET DROP SEQUENCE

### Synopsis:

SET DROP SEQUENCE ( <options> );

### Description:

Drops an existing user sequence from a replication set.

ORIGIN = <ival> | The current origin of the set.
ID = <ival> | Unique ID of the sequence.

### Example:

SET DROP SEQUENCE (
ORIGIN = 1,
ID = 21,
);

Back to Index

### SET MOVE TABLE

### Synopsis:

SET MOVE TABLE ( <options> );

### Description:

Change the set a table belongs to. The current set and the new set must origin on the same node and subscribed by the same nodes. CAUTION: Due to the way subscribing to new sets works make absolutely sure that the subscription of all nodes to the sets is completely processed before moving tables. Moving a table too early to a new set causes the subscriber to try and add the table already during the subscription process, which fails with a duplicate key error and breaks replication.

ORIGIN = <ival> | The current origin of the set. A future version of slonik might figure out this information by itself.
ID = <ival> | Unique ID of the table.
NEW SET = <ival> | Unique ID of the new set.

### Example:

SET MOVE TABLE (
ORIGIN = 1,
ID = 20,
NEW SET = 3
);

Back to Index

### SET MOVE SEQUENCE

### Synopsis:

SET MOVE SEQUENCE ( <options> );

### Description:

Change the set a sequence belongs to. The current set and the new set must origin on the same node and subscribed by the same nodes. CAUTION: Due to the way subscribing to new sets works make absolutely sure that the subscription of all nodes to the sets is completely processed before moving sequences. Moving a sequence too early to a new set causes the subscriber to try and add the sequence already during the subscription process, which fails with a duplicate key error and breaks replication.

ORIGIN = <ival> | The current origin of the set. A future version of slonik might figure out this information by itself.
ID = <ival> | Unique ID of the sequence.
NEW SET = <ival> | Unique ID of the new set.

### Example:

SET MOVE SEQUENCE (
ORIGIN = 1,
ID = 54,
NEW SET = 3
);

Back to Index

### STORE TRIGGER

### Synopsis:

STORE TRIGGER ( <options> );

### Description:

By default, all user defined triggers and constraints are disabled on all subscriber nodes while a table is replicated. This command can be used to explicitly exclude a trigger from being disabled.

TABLE ID = <ival> | The unique, numeric ID number of the table the trigger is defined for.
TRIGGER NAME = <string> | The name of the trigger as it appears in the pg_trigger system catalog.
EVENT NODE = <ival> | (Optional) The ID of the node used to create the configuration event that tells all existing nodes about the special trigger. Default value is 1.

### Example:

STORE TRIGGER (
TABLE ID = 2,
TRIGGER NAME = 'cache_invalidation'
);

Back to Index

### DROP TRIGGER

### Synopsis:

DROP TRIGGER ( <options> );

### Description:

Remove the special handling for the specified trigger.

TABLE ID = <ival> | The unique, numeric ID number of the table the trigger is defined for.
TRIGGER NAME = <string> | The name of the trigger as it appears in the pg_trigger system catalog.
EVENT NODE = <ival> | (Optional) The ID of the node used to create the configuration event that tells all existing nodes about removing the special trigger. Default value is 1.

### Example:

DROP TRIGGER (
TABLE ID = 2,
TRIGGER NAME = 'cache_invalidation'
);

Back to Index

### SUBSCRIBE SET

### Synopsis:

SUBSCRIBE SET ( <options> );

### Description:

Causes a node (subscriber) to start replicating a set of tables either from the origin or from another provider node, which must be a currently forwarding subscriber itself.

The application tables contained in the set must already exist and should ideally be currently empty. The current version of Slony-I will not attempt to copy the schema of the set. The replication daemon will start copying the current content of the set from the given provider and then try to catch up with any update activity that happened during that copy process. After successful subscription, the tables are guarded on the subscriber using triggers against accidental updates by the application.

Note: If you need to revise subscription information for a node, you may submit the new information using this command, and the new configuration will be propagated throughout the replication network. The normal reason to revise this information is that you want a node to subscribe to a different provider node, or for a node to become a "forwarding" subscriber so it may later become the provider for a later subscriber.

ID = <ival> | ID of the set to subscribe
PROVIDER = <ival> | Node ID of the data provider where this set is subscribed from.
RECEIVER = <ival> | Node ID of the new subscriber.
FORWARD = <boolean> | Flag whether or not the new subscriber should store the log information during replication to make it possible candidate for the provider role for future nodes.

### Example:

SUBSCRIBE SET (
ID = 1,
PROVIDER = 1,
RECEIVER = 3,
FORWARD = YES
);

Back to Index

### UNSUBSCRIBE SET

### Synopsis:

UNSUBSCRIBE SET ( <options> );

### Description:

Stops the subscriber from replicating the set. The tables are opened up for full access by the client application on the former subscriber. The tables are not truncated or otherwise modified. All original triggers, rules and constraints are restored.

Warning! Resubscribing an unsubscribed set requires a complete fresh copy of data from the provider to be transferred since the tables have been subject to possible independent modifications.

ID = <ival> | ID of the set to unsubscribe.
RECEIVER = <ival> | Node ID of the subscriber.

### Example:

UNSUBSCRIBE SET (
ID = 1,
RECEIVER = 3
);

Back to Index

### LOCK SET

### Synopsis:

LOCK SET ( <options> );

### Description:

Guards a replication set against client application updates in preparation for a MOVE SET command.

This command must be the first in a possible statement group (`try`). The reason for this is that it needs to commit the changes made to the tables (adding a special trigger function) before it can wait for every concurrent transaction to finish. At the same time it cannot hold an open transaction to the same database itself since this would result in blocking itself forever.

ID = <ival> | ID of the set to lock.
ORIGIN = <ival> | Node ID of the current set origin.

### Example:

LOCK SET (
ID = 1,
ORIGIN = 1
);

Back to Index

### UNLOCK SET

### Synopsis:

UNLOCK SET ( <options> );

### Description:

Unlock a previously locked set.

ID = <ival> | ID of the set to unlock.
ORIGIN = <ival> | Node ID of the current set origin.

### Example:

UNLOCK SET (
ID = 1,
ORIGIN = 1
);

Back to Index

### MOVE SET

### Synopsis:

MOVE SET ( <options> );

### Description:

Changes the origin of a set from one node to another. The new origin must be a current subscriber of the set. The set must currently be locked on the old origin.

After this command, the set cannot be unlocked on the old origin any more. The old origin will continue as a forwarding subscriber of the set and the subscription chain from the old origin to the new origin will be reversed, hop by hop. As soon as the new origin has finished processing the event (that includes any outstanding sync events that happened before, i.e. fully catching up), the new origin will take over and open all tables in the set for client application update activity.

This is not failover, as it requires a fully functional old origin node.

ID = <ival> | ID of the set to transfer.
OLD ORIGIN = <ival> | Node ID of the current set origin.
NEW ORIGIN = <ival> | Node ID of the new set origin.

### Example:

MOVE SET (
ID = 1,
OLD ORIGIN = 1,
NEW ORIGIN = 3
);

Back to Index

### FAILOVER

### Synopsis:

FAILOVER ( <options> );

### Description:

WARNING: This command will abandon the status of the failed node. There is no possibility to let the failed node join the cluster again without rebuilding it from scratch as a slave slave.

The failover command causes the backup node to take over all sets that currently originate on the failed node. Slonik will contact all other direct subscribers of the failed node to determine which node has the highest sync status for each set. If another node has a higher sync status than the backup node, the replication will first be redirected so that the backup node replicates against that other node, before assuming the origin role and allowing update activity.

After successful failover, all former direct subscribers of the failed node become direct subscribers of the backup node. The failed node can and should be removed from the configuration with `DROP NODE`.

ID = <ival> | ID of the failed node.
BACKUP NODE = <ival> | ID of the node that will take over all sets.

### Example:

FAILOVER (
ID = 1,
BACKUP NODE = 1,
);

Back to Index

### EXECUTE SCRIPT

### Synopsis:

EXECUTE SCRIPT ( <options> );

### Description:

Executes a script containing arbitrary SQL statements on all nodes that are subscribed to a set at a common controlled point within the replication transaction stream.

The specified event origin must be the origin of the set. The script file must not contain any START or COMMIT TRANSACTION calls. (This may change in PostgreSQL 8.0 once nested transactions, aka savepoints, are supported) In addition, non-deterministic DML statements (like updating a field with CURRENT_TIMESTAMP) must be avoided, since the data changes done by the script are explicitly not replicated.

SET ID = <ival> | The unique, numeric ID number of the set affected by the script.
FILENAME = <string> | The name of the file containing the SQL script to execute.
EVENT NODE = <ival> | (Optional) The ID of the current origin of the set. The default value is 1.
EXECUTE ONLY ON = <ival> | (Optional) The ID of the only node to actually execute the script. This option causes the script to be propagated by all nodes but executed only by one. The default is to execute the script on all nodes that are subscribed to the set.

### Example:

EXECUTE SCRIPT (
SET ID = 1,
FILENAME = 'changes_20040510.sql',
EVENT NODE = 1
);

Back to Index

### WAIT FOR EVENT

### Synopsis:

WAIT FOR EVENT ( <options> );

### Description:

Waits for event confirmation.

Slonik remembers the last event generated on every node during script execution (events generated by earlier calls are currently not checked). In certain situations it is necessary that events generated on one node (such as `CREATE SET`) are processed on another node before issuing more commands (for instance, SUBSCRIBE SET). `WAIT FOR EVENT` may be used to cause the slonik script to wait until the subscriber node is ready for the next action.

`WAIT FOR EVENT` must be called outside of any try block in order to work, since new confirm messages don't become visible within a transaction.

ORIGIN = <ival>|ALL | The origin of the event(s) to wait for.
CONFIRMED = <ival>|ALL | The node ID of the receiver that must have confirmed the event(s).
WAIT ON = <ival> | The ID of the node where to check the sl_confirm table. The default value is 1.
TIMEOUT = <ival> | The number of seconds to wait. Default is 600 (10 minutes), 0 means wait forever.

### Example:

### REINIT NODE

### Synopsis:

REPAIR CONFIG ( <options> );

### Description:

Resets the name to oid mapping, usefull for restoring after a pg_dump.

SET ID = <ival> | The unique, numeric ID number of the set affected by the script.
EVENT NODE = <ival> | (Optional) The ID of the current origin of the set. The default value is 1.
EXECUTE ONLY ON = <ival> | (Optional) The ID of the only node to actually update the mapping on. The default is to execute this on all nodes that are subscribed to the set.

### Example:

REPAIR CONFIG (
SET ID = 1,
EVENT NODE = 2
);

Back to Index

WAIT FOR EVENT (
ORIGIN = ALL,
CONFIRMED = ALL,
WAIT ON = 1
);

Back to Index

# Stored Procedures

The commands used in Slonik invoke stored procedures in the namespace created for the replication instance. Slonik provides one convenient way to invoke these procedures; it is just as possible to invoke them directly to manage the Slony-I instances.

See the Schema Documentation for more details.