Provided by: slony1-2-bin_2.2.7-2_amd64 bug

NAME

       slonik - Slony-I command processor

SYNOPSIS

       slonik [options] [filename]

OPTIONS

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

DESCRIPTION

       slonik  is  the  command  processor  application  that  is  used  to  set  up  and  modify
       configurations of Slony-I replication clusters.

OUTLINE

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

ENVIRONMENT VARIABLES

       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.

EXIT STATUS

       slonik returns 0 to the shell if it finished normally. Scripts may specify return codes.