Slony-i command processor
FCslonikF [0]
[options]
[filename]
-wF[0]Suppress slonik's behaviour of automatically waiting for event confirmations before submitting events to a different node. If this option is specified, your slonik script may require explicit SLONIK WAIT FOR EVENT(7) commands in order to behave properly, as was the behaviour of slonik prior to version 2.1.
slonik is the command processor application that is used to set up and modify configurations of Slony-I replication clusters.
The slonik command line utility is supposed to be used embedded into shell scripts; it reads commands from files or stdin.
It reads a set of Slonik statements, which are written in a scripting language with syntax similar to that of SQL, and performs the set of configuration changes on the slony nodes specified in the script.
Nearly all of the real configuration work is actually done by calling stored procedures after loading the Slony-I support base into a database. Slonik was created because these stored procedures have special requirements as to on which particular node in the replication system they are called. The absence 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 to multiple databases.
The format of the Slonik ‘language’ is very similar to that of SQL, and the parser is based on a similar set of formatting rules for such things as numbers and strings. Note that slonik is declarative, using literal values throughout. It is anticipated that Slonik scripts will typically be generated by scripts, such as Bash or Perl, and these sorts of scripting languages already have perfectly good ways of managing variables, doing iteration, and such.
See also Slonik Command Language reference [“Slonik Command Summary” [not available as a man page]].
SLONY_SHARE_DIR
Sets the path to the directory containing the slony .sql scripts. When this is unset Slonik will try to determine the path of the postgresql share files based on the compiled in defaults or based on the location of the slonik binary. Usually the share directory under the Postgresql installation.
slonik returns 0 to the shell if it finished normally. Scripts may specify return codes.
9 releases since Debian 4.0 (Etch); the text changed 8 times.