Thu Dec 16 20:28:09 PST 2004
- Previous message: [Slony1-commit] By cbbrowne: Added in docs on new Perl script to generate SET LISTEN
- Next message: [Slony1-commit] By darcyb: More build environment changes to better support cbrowne's
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Log Message:
-----------
Added full Slonik reference in DocBook form, along with a rich set of
linkages to it in the other materials in the admin guide.
Modified Files:
--------------
slony1-engine/doc/adminguide:
addthings.sgml (r1.3 -> r1.4)
adminscripts.sgml (r1.5 -> r1.6)
cluster.sgml (r1.4 -> r1.5)
concepts.sgml (r1.4 -> r1.5)
ddlchanges.sgml (r1.3 -> r1.4)
defineset.sgml (r1.5 -> r1.6)
dropthings.sgml (r1.4 -> r1.5)
failover.sgml (r1.4 -> r1.5)
faq.sgml (r1.4 -> r1.5)
filelist.sgml (r1.3 -> r1.4)
listenpaths.sgml (r1.5 -> r1.6)
maintenance.sgml (r1.4 -> r1.5)
reference.sgml (r1.1 -> r1.2)
reshape.sgml (r1.4 -> r1.5)
slonik_ref.sgml (r1.1 -> r1.2)
startslons.sgml (r1.3 -> r1.4)
subscribenodes.sgml (r1.4 -> r1.5)
-------------- next part --------------
Index: defineset.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/defineset.sgml,v
retrieving revision 1.5
retrieving revision 1.6
diff -Ldoc/adminguide/defineset.sgml -Ldoc/adminguide/defineset.sgml -u -w -r1.5 -r1.6
--- doc/adminguide/defineset.sgml
+++ doc/adminguide/defineset.sgml
@@ -28,9 +28,10 @@
<itemizedlist>
<listitem><para> If the table has a formally identified primary key,
-<command>SET ADD TABLE</command> can be used without any need to
-reference the primary key. <productname/Slony-I/ will pick up that
-there is a primary key, and use it.
+<command> <link linkend="stmtsetaddtable"> SET ADD
+TABLE</link></command> can be used without any need to reference the
+primary key. <productname/Slony-I/ will pick up that there is a
+primary key, and use it.
<listitem><para> If the table hasn't got a primary key, but has some
<emphasis>candidate</emphasis> primary key, that is, some index on a
@@ -50,11 +51,12 @@
<listitem><para> If the table hasn't even got a candidate primary key,
you can ask <productname/Slony-I/ to provide one. This is done by
-first using <command>TABLE ADD KEY</command> to add a column populated
-using a <productname/Slony-I/ sequence, and then having the
-<command>SET ADD TABLE</command> include the directive
-<option>key=serial</option>, to indicate that <productname/Slony-I/'s
-own column should be used.</para></listitem>
+first using <command><link linkend="stmttableaddkey"> TABLE ADD KEY
+</link> </command> to add a column populated using a
+<productname/Slony-I/ sequence, and then having the <command> <link
+linkend="stmtsetaddtable"> SET ADD TABLE</link></command> include the
+directive <option>key=serial</option>, to indicate that
+<productname/Slony-I/'s own column should be used.</para></listitem>
</itemizedlist>
Index: adminscripts.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/adminscripts.sgml,v
retrieving revision 1.5
retrieving revision 1.6
diff -Ldoc/adminguide/adminscripts.sgml -Ldoc/adminguide/adminscripts.sgml -u -w -r1.5 -r1.6
--- doc/adminguide/adminscripts.sgml
+++ doc/adminguide/adminscripts.sgml
@@ -204,15 +204,17 @@
Slony-I functions. This will typically be needed when you upgrade
from one version of <productname/Slony-I/ to another.
-<sect2 id="regenlisten"><title/ regenerate-listens.pl/
+<sect2 id="regenlisten"><title> regenerate-listens.pl</title>
-<para> This script connects to a <productname/Slony-I/ node, and
-queries various tables (sl_set, sl_node, sl_subscribe, sl_path) to
-compute what <command/SET LISTEN/ requests should be submitted to the
-cluster.
+<para> This script connects to a <productname>Slony-I</productname>
+node, and queries various tables (sl_set, sl_node, sl_subscribe,
+sl_path) to compute what <command><link linkend="stmtstorelisten">
+STORE LISTEN </link> </command> requests should be submitted to the
+cluster.</para>
<para> See the documentation on <link linkend="autolisten"> Automated
-Listen Path Generation </link> for more details on how this works.
+Listen Path Generation </link> for more details on how this
+works.</para></sect2>
</sect1>
Index: slonik_ref.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/slonik_ref.sgml,v
retrieving revision 1.1
retrieving revision 1.2
diff -Ldoc/adminguide/slonik_ref.sgml -Ldoc/adminguide/slonik_ref.sgml -u -w -r1.1 -r1.2
--- doc/adminguide/slonik_ref.sgml
+++ doc/adminguide/slonik_ref.sgml
@@ -1,12 +1,12 @@
-<article id="slonikcommands><title/Slonik Command Summary/
-<sect1 id="introduction"><title/Slonik Command Summary/
+<article id="slonikcommands"><title/Slonik Command Summary/
+<sect1 id="slonikintro"><title/Slonik Command Summary/
<sect2><title/Introduction/
<para>
<application/Slonik/ is a command line utility designed
specifically to setup and modify configurations of the
<productname/Slony-I/ replication system.
-
+</para>
<sect2 id="outline">
<title>General outline</title>
@@ -18,9 +18,9 @@
<emphasis>real</emphasis> configuration work is done by
calling stored procedures after loading the
<productname/Slony-I/ support base into a database. You may
- find documentation for those procedures in the <a
- href="schemadoc.html"> <productname/Slony-I/ Schema
- Documentation </a>, as well as in comments associated with
+ find documentation for those procedures in the <ulink
+ url="schemadoc.html"> <productname/Slony-I/ Schema
+ Documentation </ulink>, as well as in comments associated with
them in the database.
</para>
@@ -28,15 +28,16 @@
<Application/Slonik/ was created because:
<itemizedlist>
- <listitem><para> The stored procedures have special requirements as to on
- which particular node in the replication system they are
- called,
-
- <listitem><para> the lack of named parameters for stored procedures makes
- it rather hard to do this from the psql prompt, and
+ <listitem><para> The stored procedures have special
+ requirements as to on which particular node in the replication
+ system they are called,
+
+ <listitem><para> The lack of named parameters for stored
+ procedures makes it rather difficult to do this from the
+ <application/psql/ prompt, and
- <listitem><para> psql lacks the ability to maintain multiple connections
- with open transactions.
+ <listitem><para> <application/psql/ lacks the ability to
+ maintain multiple connections with open transactions.
</itemizedlist>
</para>
<para>
@@ -71,40 +72,44 @@
Commands can be combined into groups of commands with optional
<command>on error</command> and <command>on success</command> conditionals.
The syntax for this is:
- <br>
- <br> try {
- <br> <commands>
- <br> }
- <br> [on error { <commands> }]
- <br> [on success { <commands> }]
- <br>
- <br>
- Those commands are grouped together into one transaction per
+<programlisting>
+try {
+ commands;
+}
+[on error { commands; }
+[on success { commands; }
+</programlisting>
+<para> Those commands are grouped together into one transaction per
participating node.
</para>
-</div>
-
<!-- ************************************************************ -->
-<sect2 id="hdrcmds">
-<title>Commands affecting Slonik</title>
-</a>
+<reference id="hdrcmds">
+<title>Slonik Header Commands</title>
+<partintro>
<para>
The following commands must appear as a <quote/preamble/ at the very
top of every <application/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.
</para>
-
+</partintro>
<!-- **************************************** -->
-<sect3 ="clustername"><title>CLUSTER NAME</title>
+<refentry id ="clustername"><refmeta><refentrytitle>CLUSTER NAME</refentrytitle> </refmeta>
+<refnamediv><refname>CLUSTER NAME</refname>
-<sect3><title>Synopsis:</title>
- CLUSTER NAME = <string>;
-<sect3><title>Description:</title>
+<refpurpose> preamble - identifying <productname/Slony-I/ cluster </refpurpose>
+<refsynopsisdiv>
+<cmdsynopsis>
+<command>CLUSTER NAME = </command>
+<arg><replaceable class="parameter"> 'clustername';</replaceable></arg>
+</cmdsynopsis>
+</refsynopsisdiv>
+<refsect1>
+<title>Description</title>
<para>
Must be the very first command in every <application/slonik/ script. Defines
the namespace in which all <productname/Slony-I/ specific functions,
@@ -118,589 +123,646 @@
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 <tt>
- pg_dump -s </tt> on a database that is already in
+ system. Thus, if you add a new node using <command>
+ pg_dump -s </command> on a database that is already in
the cluster of replicated databases, you will need
- to drop the namespace via the SQL command <tt> DROP
- SCHEMA _testcluster CASCADE; </tt>.
+ to drop the namespace via the SQL command <command> DROP
+ SCHEMA _testcluster CASCADE; </command>.
</para>
-<sect3><title>Example:</title>
-<para>
+</refsect1>
+<refsect1><title>Example</title>
+<programlisting>
CLUSTER NAME = 'testcluster';
-</para>
-
+</programlisting>
+</refsect1>
+</refentry>
<!-- **************************************** -->
-<sect3 ="admconninfo"><title>ADMIN CONNINFO</title>
+<refentry id ="admconninfo"><refmeta><refentrytitle>ADMIN CONNINFO</refentrytitle> </refmeta>
+
+<refnamediv><refname>ADMIN CONNINFO</refname>
-<sect3><title>Synopsis:</title>
- NODE <ival> ADMIN CONNINFO = <string>;
-<sect3><title>Description:</title>
+<refpurpose> preamble - identifying <productname/PostgreSQL/ database </refpurpose>
+<refsynopsisdiv>
+<cmdsynopsis>
+<command>NODE ival ADMIN CONNINFO = 'DSN';</command>
+<arg><replaceable class="parameter"> ival;</replaceable></arg>
+<arg><replaceable class="parameter"> 'conninfo'</replaceable></arg>
+</cmdsynopsis>
+</refsynopsisdiv>
+<refsect1>
+<title>Description</title>
<para>
Describes how the <application/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
+ to the <function/PQconnectdb()/ libpq function. The user used 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.
</para>
+
<para>
The <application/slonik/ utility will not try to connect to the databases
unless some subsequent command requires the connection.
-</para>
+ </Para>
+
<para>
Note: As mentioned in the original documents, <productname/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 <tt>trust</tt>. Alternatively, libpq can read passwords from
- <tt> .pgpass </tt>.
+ 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 <quote>trust</quote>.
+ Alternatively, libpq can read passwords from <filename>
+ .pgpass </filename>.
</para>
-
<para>
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 <tt> slon </tt>
+ configuration will be propagated. Existing <application/>
+ slon </application>
processes will need to be restarted in order to become aware
of the configuration change.
</para>
-<sect3><title>Example:</title>
-<para>
+</Refsect1>
+<Refsect1><Title>Example</Title>
+<Programlisting>
NODE 1 ADMIN CONNINFO = 'dbname=testdb host=server1 user=slony';
-</para>
-</div>
+</Programlisting>
+</Refsect1>
+</Refentry>
<!-- **************************************** -->
-<sect3 ="stmt_echo"><title>ECHO</title>
+<refentry id ="stmtecho"><refmeta><refentrytitle>ECHO</refentrytitle> </refmeta>
+
+<refnamediv><refname>ECHO</refname>
+<refpurpose> Generic debugging tool </refpurpose>
-<sect3><title>Synopsis:</title>
- ECHO <string>;
-<sect3><title>Description:</title>
+<refsynopsisdiv>
+<cmdsynopsis>
+<command>echo </command>
+<arg><replaceable class="parameter"> 'string'</replaceable></arg>
+</cmdsynopsis>
+</refsynopsisdiv>
+<refsect1>
+<title>Description</title>
<para>
Prints the string literal on standard output.
</para>
-<sect3><title>Example:</title>
-<para>
+</Refsect1>
+<Refsect1><Title>Example</Title>
+<Programlisting>
ECHO 'Node 1 initialized successfully';
-</para>
-</div>
-
+</Programlisting>
+</Refsect1>
+</Refentry>
<!-- **************************************** -->
-<sect3 id="stmt_exit"><title>EXIT</title>
+<refentry id ="stmtexit"><refmeta><refentrytitle>EXIT</refentrytitle> </refmeta>
+
+<refnamediv><refname>EXIT</refname>
+
+<refpurpose> Generic debugging tool </refpurpose>
-<sect3><title>Synopsis:</title>
- EXIT [-]<ival>;
-<sect3><title>Description:</title>
+<refsynopsisdiv>
+<cmdsynopsis>
+<command>exit</command>
+<arg><replaceable class="parameter"> [-]ival</replaceable></arg>
+</cmdsynopsis>
+</refsynopsisdiv>
+<refsect1>
+<title>Description</title>
<para>
Terminates script execution immediately, rolling back every
- open transaction on all database connections. The <application/slonik/ utility
+ open transaction on all database connections. The
+ <application/slonik/ utility
will return the given value as its program termination code.
</para>
-<sect3><title>Example:</title>
-<para>
+</Refsect1>
+<Refsect1><Title>Example</Title>
+<Programlisting>
EXIT 0;
-</para>
-</div>
-
-
-</div>
-
+</Programlisting>
+</Refsect1>
+</Refentry>
+</reference>
<!-- ************************************************************ -->
-<sect2 id="cmds">
-<title>Configuration and Action commmands</title>
-<div style="margin-left:40px; margin-right:80px;">
<!-- **************************************** -->
+<reference id="cmds"><title>Configuration and Action commmands</title>
-<sect3 id="stmt_init_cluster"><title>INIT CLUSTER</title>
-
-<div style="margin-left:40px; margin-right:0px;">
-<sect3><title>Synopsis:</title>
- INIT CLUSTER ( <options> );
-<sect3><title>Description:</title>
-<para>
- Initialize the first node in a new <productname/Slony-I/ replication cluster.
- The initialization process consists of creating the cluster
- namespace, loading all the base tables, functions, procedures
- and initializing the node.
-</para>
-<para>
- For this process to work, the SQL scripts of the <productname/Slony-I/ system
- must be installed on the DBA workstation (the computer currently
- executing the <application/slonik/ utility), while on the system where the
- node database is running the shared objects of the <productname/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.
-</para>
-<table border="0" cellpadding="10">
-<tr>
- <td align="left" valign="top" nowrap><b>ID = <ival></b></td>
- <td align="left" valign="top"><para>
- The unique, numeric ID number of the node. This MUST be 1.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>COMMENT = <string></b></td>
- <td align="left" valign="top"><para>
- A descriptive text added to the node entry in the
- table sl_node.
- </para></td>
-</tr>
-</table>
-<sect3><title>Example:</title>
-<para>
- INIT CLUSTER (
- <br> ID = 1,
- <br> COMMENT = 'Node 1'
- <br>);
-</para>
-</div>
+<refentry id ="stmtinitcluster"><refmeta><refentrytitle>INIT CLUSTER</refentrytitle> </refmeta>
+<refnamediv><refname>INIT CLUSTER</refname>
-<!-- **************************************** -->
+<refpurpose> Initialize <productname/Slony-I/ cluster </refpurpose>
+<refsynopsisdiv>
+<cmdsynopsis>
+<command>INIT CLUSTER </command>
+<arg>ID = <replaceable class="parameter">integer</replaceable></arg>
+<arg>COMMENT = <replaceable class="parameter">'string'</replaceable></arg>
+</cmdsynopsis>
+</refsynopsisdiv>
+<refsect1>
+<title>Description</title>
+
+<para> Initialize the first node in a new <productname/Slony-I/
+replication cluster. The initialization process consists of creating
+the cluster namespace, loading all the base tables, functions,
+procedures and initializing the node.
+
+<variablelist>
+ <varlistentry><term><literal> ID </literal></term>
+ <listitem><para> The unique, numeric ID number of the node. </para>
+ </varlistentry>
+
+ <varlistentry><term><literal> COMMENT = 'comment text' </literal></term>
+ <listitem><para> A descriptive text added to the node entry in the table sl_node.</para>
+ </varlistentry>
+</variablelist>
-<sect3 id="stmt_store_node"><title>STORE NODE</title>
-
-<div style="margin-left:40px; margin-right:0px;">
-<sect3><title>Synopsis:</title>
- STORE NODE ( <options> );
-<sect3><title>Description:</title>
-<para>
- Initialize a new node and add it to the configuration of
- an existing cluster.
-</para>
-<para>
- 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 <b>event node</b>.
-</para>
-<para>
- The same installation requirements as for the <command>init cluster</command>
- command apply.
-</para>
-<table border="0" cellpadding="10">
-<tr>
- <td align="left" valign="top" nowrap><b>ID = <ival></b></td>
- <td align="left" valign="top"><para>
- The unique, numeric ID number of the new node.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>COMMENT = <string></b></td>
- <td align="left" valign="top"><para>
- A descriptive text added to the node entry in the
- table sl_node.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>SPOOLNODE = <boolean></b></td>
- <td align="left" valign="top"><para>
- Specifies that the new node is a virtual spool node for
- file archiving of replication log. If true <application/slonik/ will not
- attempt to initialize a database with the replication
- schema.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>EVENT NODE = <ival></b></td>
- <td align="left" valign="top"><para>
- <b>(Optional)</b>
- The ID of the node used to create the configuration event
- that tells all existing nodes about the new node. Default
- value is 1.
- </para></td>
-</tr>
-</table>
-<sect3><title>Example:</title>
-<para>
- STORE NODE (
- <br> ID = 2,
- <br> COMMENT = 'Node 2'
- <br>);
</para>
-</div>
-
-
-<!-- **************************************** -->
-<sect3 ="stmt_drop_node"><title>DROP NODE</title>
+<para> For this process to work, the SQL scripts of the
+<productname>Slony-I</productname> system must be installed on the DBA workstation
+(the computer currently executing the <application>slonik</application> utility),
+while on the system where the node database is running the shared
+objects of the <productname>Slony-I</productname> system must be installed in the
+PostgreSQL library directory. Also the procedural language PL/pgSQL is
+assumed to already be installed in the target database. </para>
+
+</Refsect1>
+<Refsect1><Title>Example</Title>
+<Programlisting>
+ INIT CLUSTER (
+ ID = 1,
+ COMMENT = 'Node 1'
+ );
+</Programlisting>
+</Refsect1>
+</Refentry>
+
+<!-- **************************************** -->
+
+<refentry id ="stmtstorenode"><refmeta><refentrytitle>STORE NODE</refentrytitle> </refmeta>
+
+<refnamediv><refname>STORE NODE</refname>
+
+
+<refpurpose> Initialize <productname/Slony-I/ node </refpurpose>
+<refsynopsisdiv>
+<cmdsynopsis>
+<command>STORE NODE (options);</command>
+</cmdsynopsis>
+</refsynopsisdiv>
+<refsect1>
+<title>Description</title>
+
+<para> Initialize a new node and add it to the configuration of an
+existing cluster.
+
+<para> 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 <quote>event node</quote>.
+
+<variablelist>
+ <varlistentry><term><literal> ID = ival </literal></term>
+ <listitem><para> The unique, numeric ID number of the new node. </para>
+ </varlistentry>
+
+ <varlistentry><term><literal> COMMENT = 'description' </literal></term>
+ <listitem><para> A descriptive text added to the node entry in the table sl_node.</para>
+ </varlistentry>
+
+ <varlistentry><term><literal> SPOOLNODE = boolean </literal></term>
+
+ <listitem><para> Specifies that the new node is a virtual spool node
+ for file archiving of replication log. If true <application/slonik/
+ will not attempt to initialize a database with the replication
+ schema. </para>
+
+ </varlistentry>
+ <varlistentry><term><literal> EVENT NODE = ival </literal></term>
+
+ <listitem><para> The ID of the node used to create the configuration
+ event that tells all existing nodes about the new node. Default
+ value is 1. </para>
+ </varlistentry>
+</variablelist>
+</para>
+</Refsect1>
+<Refsect1><Title>Example</Title>
+<Programlisting>
+ STORE NODE ( ID = 2, COMMENT = 'Node 2');
+</Programlisting>
+</Refsect1>
+</Refentry>
+
+<!-- **************************************** -->
+<refentry id ="stmtdropnode"><refmeta><refentrytitle>DROP NODE</refentrytitle> </refmeta>
+
+<refnamediv><refname>DROP NODE</refname>
+
+<refpurpose> Decommission <productname/Slony-I/ node </refpurpose>
+<refsynopsisdiv>
+<cmdsynopsis>
+<command>DROP NODE (options);</command>
+</cmdsynopsis>
+</refsynopsisdiv>
+<refsect1>
+<title>Description</title>
-<div style="margin-left:40px; margin-right:0px;">
-<sect3><title>Synopsis:</title>
- DROP NODE ( <options> );
-<sect3><title>Description:</title>
<para>
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.
-</para>
-<table border="0" cellpadding="10">
-<tr>
- <td align="left" valign="top" nowrap><b>ID = <ival></b></td>
- <td align="left" valign="top"><para>
- Node ID of the system to remove.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>EVENT NODE = <ival></b></td>
- <td align="left" valign="top"><para>
- Node ID of the system to generate the event.
- </para></td>
-</tr>
-</table>
-<sect3><title>Example:</title>
-<para>
- DROP NODE (
- <br> ID = 2
- <br>);
-</para>
-</div>
+<variablelist>
+ <varlistentry><term><literal> ID = ival </literal></term>
+ <listitem><para> Node ID of the node to remove. </para>
+ </varlistentry>
+ <varlistentry><term><literal> EVENT NODE = ival </literal></term>
+ <listitem><para> Node ID of the node to generate the event. </para>
+ </varlistentry>
+</variablelist>
+</para>
+</Refsect1>
+<Refsect1><Title>Example</Title>
+<Programlisting>
+ DROP NODE ( ID = 2 );
+</Programlisting>
+</Refsect1>
+</Refentry>
+
+<!-- **************************************** -->
+<refentry id ="stmtuninstallnode"><refmeta><refentrytitle>UNINSTALL NODE</refentrytitle> </refmeta>
+
+<refnamediv><refname>UNINSTALL NODE</refname>
+
+<refpurpose> Decommission <productname/Slony-I/ node </refpurpose>
+<refsynopsisdiv>
+<cmdsynopsis>
+<command>UNINSTALL NODE (options);</command>
+</cmdsynopsis>
+</refsynopsisdiv>
+<refsect1>
+<title>Description</title>
-<!-- **************************************** -->
-
-<sect3 ="stmt_uninstall_node"><title>UNINSTALL NODE</title>
-
-<div style="margin-left:40px; margin-right:0px;">
-<sect3><title>Synopsis:</title>
- UNINSTALL NODE ( <options> );
-<sect3><title>Description:</title>
<para>
Restores all tables to the unlocked state, with all original
user triggers, constraints and rules, eventually added <productname/Slony-I/
specific serial key columns dropped and the <productname/Slony-I/ schema
dropped. The node becomes a standalone database. The data is
left untouched.
+
+<variablelist>
+ <varlistentry><term><literal> ID = ival </literal></term>
+ <listitem><para> Node ID of the node to uninstall. </para>
+ </varlistentry>
+</variablelist>
+</para>
+</Refsect1>
+<Refsect1><Title>Example</Title>
+<Programlisting>
+ UNINSTALL NODE ( ID = 2 );
+</Programlisting>
+</Refsect1>
+</Refentry>
+
+<!-- **************************************** -->
+
+<refentry id ="stmtrestartnode"><refmeta><refentrytitle>RESTART NODE</refentrytitle> </refmeta>
+
+<refnamediv><refname>RESTART NODE</refname>
+
+<refpurpose> Restart <productname/Slony-I/ node </refpurpose>
+
+<refsynopsisdiv>
+<cmdsynopsis>
+<command>RESTART NODE (options);</command>
+</cmdsynopsis>
+</refsynopsisdiv>
+<refsect1>
+<title>Description</title>
+
+<para> 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.
+
+<variablelist>
+ <varlistentry><term><literal> ID = ival </literal></term>
+ <listitem><para> Node ID of the node to restart. </para>
+ </varlistentry>
+</variablelist>
+</para>
+</Refsect1>
+<Refsect1><Title>Example</Title>
+<Programlisting>
+ RESTART NODE ( ID = 2 );
+</Programlisting>
+</Refsect1>
+</Refentry>
+
+
+<!-- **************************************** -->
+
+<refentry id ="stmtstorepath"><refmeta><refentrytitle>STORE PATH</refentrytitle> </refmeta>
+
+<refnamediv><refname>STORE PATH</refname>
+
+<refpurpose> Configure <productname/Slony-I/ node </refpurpose>
+
+<refsynopsisdiv>
+<cmdsynopsis>
+<command>STORE PATH (options);</command>
+</cmdsynopsis>
+</refsynopsisdiv>
+<refsect1>
+<title>Description</title>
+
+<para> 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.</para>
+
+<para> The conninfo string must contain all information to connect to the
+ database as the replication superuser. The names <quote/server/ or
+ <quote/client/ have nothing to do with the particular role of a node
+ within the cluster configuration. It should be simply viewed as
+ <quote/the server/ has the message or data that <quote/the client
+ is supposed to get./ For a simple 2 node setup, paths into both
+ directions must be configured.
</para>
-<table border="0" cellpadding="10">
-<tr>
- <td align="left" valign="top" nowrap><b>ID = <ival></b></td>
- <td align="left" valign="top"><para>
- Node ID of the system to uninstall.
- </para></td>
-</tr>
-</table>
-<sect3><title>Example:</title>
<para>
- UNINSTALL NODE (
- <br> ID = 3
- <br>);
+ 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 <emphasis/listen/ entries or data
+ because of <emphasis/subscriptions/.
+
+<variablelist>
+ <varlistentry><term><literal> SERVER = ival </literal></term>
+ <listitem><para> Node ID of the database to connect to. </para>
+ </varlistentry>
+ <varlistentry><term><literal> CLIENT = ival </literal></term>
+ <listitem><para> Node ID of the replication daemon connecting. </para>
+ </varlistentry>
+ <varlistentry><term><literal> CONNINFO = string </literal></term>
+ <listitem><para> <function/PQconnectdb()/ argument to establish the connection. </para>
+ </varlistentry>
+ <varlistentry><term><literal> CONNRETRY = ival </literal></term>
+ <listitem><para> Number of seconds to wait before another attempt to
+ connect is made in case the server is unavailable. Default is 10.
</para>
-</div>
+ </varlistentry>
+</variablelist>
+</para>
+</Refsect1>
+<Refsect1><Title>Example</Title>
+<Programlisting>
+ STORE PATH ( SERVER = 1, CLIENT = 2,
+ CONNINFO = 'dbname=testdb host=server1 user=slony'
+ );
+</Programlisting>
+</Refsect1>
+</Refentry>
<!-- **************************************** -->
-<sect3 ="stmt_restart_node"><title>RESTART NODE</title>
+<refentry id ="stmtdroppath"><refmeta><refentrytitle>DROP PATH</refentrytitle> </refmeta>
-<div style="margin-left:40px; margin-right:0px;">
-<sect3><title>Synopsis:</title>
- RESTART NODE <ival>;
-<sect3><title>Description:</title>
-<para>
- 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.
+<refnamediv><refname>DROP PATH</refname>
+
+<refpurpose> Configure <productname/Slony-I/ node </refpurpose>
+
+<refsynopsisdiv>
+<cmdsynopsis>
+<command>DROP PATH (options);</command>
+</cmdsynopsis>
+</refsynopsisdiv>
+<refsect1>
+<title>Description</title>
+
+<para> Remove the connection information between <quote/server/ and
+ <quote/client/.
+
+
+
+<variablelist>
+ <varlistentry><term><literal> SERVER = ival </literal></term>
+ <listitem><para> Node ID of the database to connect to. </para>
+ </varlistentry>
+ <varlistentry><term><literal> CLIENT = ival </literal></term>
+ <listitem><para> Node ID of the replication daemon connecting. </para>
+ </varlistentry>
+ <varlistentry><term><literal> EVENT NODE = ival </literal></term>
+
+ <listitem><para> The ID of the node used to create the configuration
+ event that tells all existing nodes about dropping the path.
+ Defaults to the <quote/client/, if omitted.
</para>
-<sect3><title>Example:</title>
-<para>
- RESTART NODE 2;
+ </varlistentry>
+</variablelist>
</para>
-</div>
+</Refsect1>
+<Refsect1><Title>Example</Title>
+<Programlisting>
+ DROP PATH ( SERVER = 1, CLIENT = 2 );
+</Programlisting>
+</Refsect1>
+</Refentry>
<!-- **************************************** -->
-<sect3 ="stmt_store_path"><title>STORE PATH</title>
+<refentry id ="stmtstorelisten"><refmeta><refentrytitle>STORE LISTEN</refentrytitle> </refmeta>
-<div style="margin-left:40px; margin-right:0px;">
-<sect3><title>Synopsis:</title>
- STORE PATH ( <options> );
-<sect3><title>Description:</title>
-<para>
- 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.
-</para>
-<para>
- The conninfo string must contain all information to connect to the
- database as the replication superuser. The names <b>server</b> or
- <b>client</b> have nothing to do with the particular role of a node
- within the cluster configuration. It should be simply viewed as
- "the <b>server</b> has the message or data that the <b>client</b>
- is supposed to get". For a simple 2 node setup, paths into both
- directions must be configured.
-</para>
-<para>
- 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 <b>listen</b> entries or data
- because of <b>subscriptions</b>.
-</para>
-<table border="0" cellpadding="10">
-<tr>
- <td align="left" valign="top" nowrap><b>SERVER = <ival></b></td>
- <td align="left" valign="top"><para>
- Node ID of the database to connect to.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>CLIENT = <ival></b></td>
- <td align="left" valign="top"><para>
- Node ID of the replication daemon connecting.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>CONNINFO = <string></b></td>
- <td align="left" valign="top"><para>
- PQconnectdb() argument to establish the connection.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>CONNRETRY = <ival></b></td>
- <td align="left" valign="top"><para>
- <b>(Optional)</b>
- Number of seconds to wait before another attempt to connect
- is made in case the server is unavailable. Default is 10.
- </para></td>
-</tr>
-</table>
-<sect3><title>Example:</title>
-<para>
- STORE PATH (
- <br> SERVER = 1,
- <br> CLIENT = 2,
- <br> CONNINFO = 'dbname=testdb host=server1 user=slony'
- <br>);
-</para>
-</div>
-
-
-<!-- **************************************** -->
-
-<sect3 ="stmt_drop_path"><title>DROP PATH</title>
-
-<div style="margin-left:40px; margin-right:0px;">
-<sect3><title>Synopsis:</title>
- DROP PATH ( <options> );
-<sect3><title>Description:</title>
-<para>
- Remove the connection information between <b>server</b> and
- <b>client</b>.
-</para>
-<table border="0" cellpadding="10">
-<tr>
- <td align="left" valign="top" nowrap><b>SERVER = <ival></b></td>
- <td align="left" valign="top"><para>
- Node ID of the server of this connection.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>CLIENT = <ival></b></td>
- <td align="left" valign="top"><para>
- Node ID of the client.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>EVENT NODE = <ival></b></td>
- <td align="left" valign="top"><para>
- <b>(Optional)</b>
- The ID of the node used to create the configuration event
- that tells all existing nodes about dropping the path.
- Defaults to the <b>client</b>.
- </para></td>
-</tr>
-</table>
-<sect3><title>Example:</title>
-<para>
- DROP PATH (
- <br> SERVER = 1,
- <br> CLIENT = 2
- <br>);
-</para>
-</div>
-
-
-<!-- **************************************** -->
-
-<sect3 ="stmt_store_listen"><title>STORE LISTEN</title>
-
-<div style="margin-left:40px; margin-right:0px;">
-<sect3><title>Synopsis:</title>
- STORE LISTEN ( <options> );
-<sect3><title>Description:</title>
-<para>
- A <b>listen</b> 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 <b>path</b>
+<refnamediv><refname>STORE LISTEN</refname>
+
+<refpurpose> Configure <productname/Slony-I/ node </refpurpose>
+
+<refsynopsisdiv>
+<cmdsynopsis>
+<command>STORE LISTEN (options);</command>
+</cmdsynopsis>
+</refsynopsisdiv>
+<refsect1>
+<title>Description</title>
+
+<para> A <quote/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 <quote/path/
to exist so that the receiver (as client) can connect to the provider
(as server).
-</para>
+
<para>
- 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
- <a href="#stmt_subscribe_set">SUBSCRIBE SET</a>) 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.
-</para>
-<table border="0" cellpadding="10">
-<tr>
- <td align="left" valign="top" nowrap><b>ORIGIN = <ival></b></td>
- <td align="left" valign="top"><para>
- ID of the event origin the receiver is listening for.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>PROVIDER = <ival></b></td>
- <td align="left" valign="top"><para>
- <b>(Optional)</b>
- ID of the node from which the receiver gets events from
- the origin. Default is the origin.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>RECEIVER = <ival></b></td>
- <td align="left" valign="top"><para>
- ID of the node receiving the events.
- </para></td>
-</tr>
-</table>
-<sect3><title>Example:</title>
-<para>
- STORE LISTEN (
- <br> ORIGIN = 1,
- <br> RECEIVER = 2,
- <br>);
-</para>
-</div>
-
-
-<!-- **************************************** -->
-
-<sect3 ="stmt_drop_listen"><title>DROP LISTEN</title>
-
-<div style="margin-left:40px; margin-right:0px;">
-<sect3><title>Synopsis:</title>
- DROP LISTEN ( <options> );
-<sect3><title>Description:</title>
-<para>
- Remove a <b>listen</b> configuration entry.
-</para>
-<table border="0" cellpadding="10">
-<tr>
- <td align="left" valign="top" nowrap><b>ORIGIN = <ival></b></td>
- <td align="left" valign="top"><para>
- ID of the event origin the receiver is listening for.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>PROVIDER = <ival></b></td>
- <td align="left" valign="top"><para>
- <b>(Optional)</b>
- ID of the node from which the receiver gets events from
- the origin. Default is the origin.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>RECEIVER = <ival></b></td>
- <td align="left" valign="top"><para>
- ID of the node receiving the events.
- </para></td>
-</tr>
-</table>
-<sect3><title>Example:</title>
-<para>
- DROP LISTEN (
- <br> ORIGIN = 1,
- <br> RECEIVER = 2,
- <br>);
-</para>
-</div>
-
-
-<!-- **************************************** -->
-
-<sect3 ="stmt_table_add_key"><title>TABLE ADD KEY</title>
-
-<div style="margin-left:40px; margin-right:0px;">
-<sect3><title>Synopsis:</title>
- TABLE ADD KEY ( <options> );
-<sect3><title>Description:</title>
+ 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 <link linkend="stmtsubscribeset">SUBSCRIBE
+ SET</link>) 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 <command/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.
+</para>
+
+<variablelist>
+ <varlistentry><term><literal> ORIGIN = ival </literal></term>
+ <listitem><para> Node ID of the event origin the receiver is listening for. </para>
+ </varlistentry>
+ <varlistentry><term><literal> PROVIDER = ival </literal></term>
+ <listitem><para> Node ID of the node from which the receiver gets events that come from the origin. If not specified, default is the origin.</para>
+ </varlistentry>
+ <varlistentry><term><literal> RECEIVER = ival </literal></term>
+
+ <listitem><para> The ID of the node receiving the events. </para>
+ </varlistentry>
+</variablelist>
+
+<para> For more details, see the section on <link
+linkend="listenpaths"> Slony-I Listen Paths. </link>
+</Refsect1>
+<Refsect1><Title>Example</Title>
+<Programlisting>
+ STORE LISTEN ( ORIGIN = 1, RECEIVER = 2, PROVIDER = 3 );
+</Programlisting>
+</Refsect1>
+</Refentry>
+
+
+<!-- **************************************** -->
+
+<refentry id ="stmtdroplisten"><refmeta><refentrytitle>DROP LISTEN</refentrytitle> </refmeta>
+
+<refnamediv><refname>DROP LISTEN</refname>
+
+<refpurpose> Configure <productname/Slony-I/ node </refpurpose>
+
+<refsynopsisdiv>
+<cmdsynopsis>
+<command>DROP LISTEN (options);</command>
+</cmdsynopsis>
+</refsynopsisdiv>
+<refsect1>
+<title>Description</title>
+
+<para> Remove a <quote/listen/ configuration entry. </para>
+
+<variablelist>
+ <varlistentry><term><literal> ORIGIN = ival </literal></term>
+ <listitem><para> Node ID of the event origin the receiver is listening for. </para>
+ </varlistentry>
+ <varlistentry><term><literal> PROVIDER = ival </literal></term>
+ <listitem><para> Node ID of the node from which the receiver gets events that come from the origin. If not specified, default is the origin.</para>
+ </varlistentry>
+ <varlistentry><term><literal> RECEIVER = ival </literal></term>
+
+ <listitem><para> The ID of the node receiving the events. </para>
+ </varlistentry>
+</variablelist>
+
+</Refsect1>
+<Refsect1><Title>Example</Title>
+<Programlisting>
+ DROP LISTEN ( ORIGIN = 1, RECEIVER = 2, PROVIDER = 3 );
+</Programlisting>
+</Refsect1>
+</Refentry>
+
+
+<!-- **************************************** -->
+
+<refentry id ="stmttableaddkey"><refmeta><refentrytitle>TABLE ADD KEY</refentrytitle> </refmeta>
+
+<refnamediv><refname>TABLE ADD KEY</refname>
+
+<refpurpose> Configure <productname/Slony-I/ set </refpurpose>
+
+<refsynopsisdiv>
+<cmdsynopsis>
+<command>TABLE ADD KEY (options);</command>
+</cmdsynopsis>
+</refsynopsisdiv>
+<refsect1>
+<title>Description</title>
+
<para>
In the <productname/Slony-I/ replication system, every replicated table is
- required to have at least one UNIQUE constraint who's columns
- are declared <tt>NOT NULL.</tt> Any primary key satisfies this
+ required to have at least one <command/UNIQUE/ constraint
+ whose columns are declared <command>NOT NULL.</command> Any
+ primary key satisfies this
requirement.
</para>
<para>
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, <b>it is
+ this modification can have unwanted side effects, <emphasis>it is
strongly recommended that users add a unique and not null
- attribute by other means.</b>
+ attribute by other means.</emphasis>
</para>
-<table border="0" cellpadding="10">
-<tr>
- <td align="left" valign="top" nowrap><b>NODE ID = <ival></b></td>
- <td align="left" valign="top"><para>
- ID of the set origin where the table will be added as
- set member (See <a href="stmt_set_add_table">SET ADD TABLE</a>).
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>FULLY QUALIFIED NAME = <string></b></td>
- <td align="left" valign="top"><para>
- The full name of the table consisting of the schema and table name
- as the expression
- <br><emphasis>quote_ident(nspname) || '.' || quote_ident(relname)</emphasis>
- <br>would return it.
- </para></td>
-</tr>
-</table>
-<sect3><title>Example:</title>
-<para>
- TABLE ADD KEY (
- <br> NODE ID = 1,
- <br> FULLY QUALIFIED NAME = 'public.history'
- <br>);
-</para>
-</div>
+
+
+<variablelist>
+ <varlistentry><term><literal> NODE ID = ival </literal></term>
+ <listitem><para> Node ID of the set origin where the table will be
+ added as a set member. (See <link linkend="stmtsetaddtable">
+ <command/ SET ADD TABLE / </link>.) </para>
+ </varlistentry>
+ <varlistentry><term><literal> FULLY QUALIFIED NAME = 'string' </literal></term>
+ <listitem><para> The full name of the table consisting of the schema
+ and table name as the SQL expression <command>quote_ident(nspname)
+ || '.' || quote_ident(relname)</command>
+ would return it. </para>
+ </varlistentry>
+</variablelist>
+
+</Refsect1>
+<Refsect1><Title>Example</Title>
+<Programlisting>
+ TABLE ADD KEY ( NODE ID = 1,
+ FULLY QUALIFIED NAME = 'public.history' );
+</Programlisting>
+</Refsect1>
+</Refentry>
<!-- **************************************** -->
-<sect3 ="stmt_create_set"><title>CREATE SET</title>
-
-<div style="margin-left:40px; margin-right:0px;">
-<sect3><title>Synopsis:</title>
- CREATE SET ( <options> );
-<sect3><title>Description:</title>
+<refentry id ="stmtcreateset"><refmeta><refentrytitle>CREATE SET</refentrytitle> </refmeta>
+
+<refnamediv><refname>CREATE SET</refname>
+
+<refpurpose> Configure <productname/Slony-I/ set </refpurpose>
+
+<refsynopsisdiv>
+<cmdsynopsis>
+<command>CREATE SET (options);</command>
+</cmdsynopsis>
+</refsynopsisdiv>
+<refsect1>
+<title>Description</title>
+
<para>
In the <productname/Slony-I/ replication system, replicated tables are
organized in sets. As a general rule of thumb, a set should
@@ -711,89 +773,95 @@
<para>
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 <productname/Slony-I/ a node can be the "master" over one set,
- while receiving replication data in the "slave" role for
+ classical replication terms, that would be the <quote/master./
+ Since in <productname/Slony-I/ a node can be the <quote/master/ over one set,
+ while receiving replication data in the <quote/slave/ role for
another at the same time, this terminology may easily become
- misleading and should therefore be replaced with <b>set
- origin</b> and <b>subscriber</b>.
+ misleading and should therefore be replaced with <quote>set
+ origin</quote> and <quote>subscriber</quote>.
</para>
-<table border="0" cellpadding="10">
-<tr>
- <td align="left" valign="top" nowrap><b>ID = <ival></b></td>
- <td align="left" valign="top"><para>
- Unique ID of the set to be created.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>ORIGIN = <ival></b></td>
- <td align="left" valign="top"><para>
- Initial origin of the set.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>COMMENT = <string></b></td>
- <td align="left" valign="top"><para>
- A descriptive text added to the set entry.
- </para></td>
-</tr>
-</table>
-<sect3><title>Example:</title>
-<para>
- CREATE SET (
- <br> ID = 1,
- <br> ORIGIN = 1,
- <br> COMMENT = 'Tables of ticket system'
- <br>);
-</para>
-</div>
+
+
+<variablelist>
+ <varlistentry><term><literal> ID = ival </literal></term>
+ <listitem><para> ID of the set to be created. </para>
+ </varlistentry>
+ <varlistentry><term><literal> ORIGIN = ival </literal></term>
+ <listitem><para> Initial origin node of the set. </para>
+ </varlistentry>
+ <varlistentry><term><literal> COMMENT = 'string' </literal></term>
+ <listitem><para> A descriptive text added to the set entry. </para>
+ </varlistentry>
+</variablelist>
+
+</Refsect1>
+<Refsect1><Title>Example</Title>
+<Programlisting>
+ CREATE SET ( ID = 1,
+ ORIGIN = 1,
+ COMMENT = 'Tables for ticketing system' );
+</Programlisting>
+</Refsect1>
+</Refentry>
<!-- **************************************** -->
-<sect3 ="stmt_drop_set"><title>DROP SET</title>
-
-<div style="margin-left:40px; margin-right:0px;">
-<sect3><title>Synopsis:</title>
- DROP SET ( <options> );
-<sect3><title>Description:</title>
+<refentry id ="stmtdropset"><refmeta><refentrytitle>DROP SET</refentrytitle> </refmeta>
+
+<refnamediv><refname>DROP SET</refname>
+
+<refpurpose> Configure <productname/Slony-I/ set </refpurpose>
+
+<refsynopsisdiv>
+<cmdsynopsis>
+<command>DROP SET (options);</command>
+</cmdsynopsis>
+</refsynopsisdiv>
+<refsect1>
+<title>Description</title>
+
<para>
Drop a set of tables from the <productname/Slony-I/ configuration. This
automatically unsubscribes all nodes from the set and restores
the original triggers and rules on all subscribers.
</para>
-<table border="0" cellpadding="10">
-<tr>
- <td align="left" valign="top" nowrap><b>ID = <ival></b></td>
- <td align="left" valign="top"><para>
- Unique ID of the set to be dropped.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>ORIGIN = <ival></b></td>
- <td align="left" valign="top"><para>
- The current origin of the set.
- </para></td>
-</tr>
-</table>
-<sect3><title>Example:</title>
-<para>
- DROP SET (
- <br> ID = 5,
- <br> ORIGIN = 1
- <br>);
-</para>
-</div>
+
+<variablelist>
+ <varlistentry><term><literal> ID = ival </literal></term>
+ <listitem><para> ID of the set to be dropped. </para>
+ </varlistentry>
+ <varlistentry><term><literal> ORIGIN = ival </literal></term>
+ <listitem><para> Current origin node of the set. </para>
+ </varlistentry>
+</variablelist>
+
+</Refsect1>
+<Refsect1><Title>Example</Title>
+<Programlisting>
+ DROP SET ( ID = 5,
+ ORIGIN = 2 );
+</Programlisting>
+</Refsect1>
+</Refentry>
<!-- **************************************** -->
-<sect3 ="stmt_merge_set"><title>MERGE SET</title>
-
-<div style="margin-left:40px; margin-right:0px;">
-<sect3><title>Synopsis:</title>
- MERGE SET ( <options> );
-<sect3><title>Description:</title>
+<refentry id ="stmtmergeset"><refmeta><refentrytitle>MERGE SET</refentrytitle> </refmeta>
+
+<refnamediv><refname>MERGE SET</refname>
+
+<refpurpose> Reconfigure <productname/Slony-I/ sets </refpurpose>
+
+<refsynopsisdiv>
+<cmdsynopsis>
+<command>MERGE SET (options);</command>
+</cmdsynopsis>
+</refsynopsisdiv>
+<refsect1>
+<title>Description</title>
+
<para>
Merge a set of tables and sequences into another one. This
function is a workaround for the problem that it is not
@@ -803,664 +871,730 @@
set to this new one, and then merge the two together.
</para>
<para>
- This request will fail if the two sets do not have exactly the
- same set of subscribers.
-</para>
-<table border="0" cellpadding="10">
-<tr>
- <td align="left" valign="top" nowrap><b>ID = <ival></b></td>
- <td align="left" valign="top"><para>
- Unique ID of the set to contain the union of the two separate sets.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>ADD ID = <ival></b></td>
- <td align="left" valign="top"><para>
- Unique ID of the set whos objects should be transferred.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>ORIGIN = <ival></b></td>
- <td align="left" valign="top"><para>
- The current origin of the two sets.
- </para></td>
-</tr>
-</table>
-<sect3><title>Example:</title>
-<para>
- MERGE SET (
- <br> ID = 2,
- <br> ADD ID = 9999,
- <br> ORIGIN = 1
- <br>);
-</para>
-</div>
+ This request will fail if the two sets do not have
+ <emphasis/exactly/ the same set of subscribers. </para>
+
+<variablelist>
+ <varlistentry><term><literal> ID = ival </literal></term>
+ <listitem><para> Unique ID of the set to contain the union of the two separate sets. </para>
+ </varlistentry>
+ <varlistentry><term><literal> ADD ID = ival </literal></term>
+ <listitem><para> Unique ID of the set whose objects should be transferred. </para>
+ </varlistentry>
+ <varlistentry><term><literal> ORIGIN = ival </literal></term>
+ <listitem><para> Current origin node for both sets. </para>
+ </varlistentry>
+</variablelist>
+
+</Refsect1>
+<Refsect1><Title>Example</Title>
+<Programlisting>
+ MERGE SET ( ID = 2,
+ ADD ID = 9999,
+ ORIGIN = 1 );
+</Programlisting>
+</Refsect1>
+</Refentry>
<!-- **************************************** -->
-<sect3 ="stmt_set_add_table"><title>SET ADD TABLE</title>
-
-<div style="margin-left:40px; margin-right:0px;">
-<sect3><title>Synopsis:</title>
- SET ADD TABLE ( <options> );
-<sect3><title>Description:</title>
+<refentry id ="stmtsetaddtable"><refmeta><refentrytitle>SET ADD TABLE</refentrytitle> </refmeta>
+
+<refnamediv><refname>SET ADD TABLE</refname>
+
+<refpurpose> Configure <productname/Slony-I/ set </refpurpose>
+
+<refsynopsisdiv>
+<cmdsynopsis>
+<command>SET ADD TABLE (options);</command>
+</cmdsynopsis>
+</refsynopsisdiv>
+<refsect1>
+<title>Description</title>
+
<para>
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<tt>MERGE SET</tt> command.
-</para>
-<table border="0" cellpadding="10">
-<tr>
- <td align="left" valign="top" nowrap><b>SET ID = <ival></b></td>
- <td align="left" valign="top"><para>
- ID of the set to which the table is added.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>ORIGIN = <ival></b></td>
- <td align="left" valign="top"><para>
- The current origin of the set. A future version of <application/slonik/
- might figure out this information by itself.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>ID = <ival></b></td>
- <td align="left" valign="top"><para>
- 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
- <a href="#stmt_lock_set">LOCK SET</a> command for example. So these
- numbers should represent any applicable table hierarchy to
- make sure the <application/slonik/ command scripts do not deadlock at any
- critical moment.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>FULLY QUALIFIED NAME = <string></b></td>
- <td align="left" valign="top"><para>
- The full table name as described in
- <a href="#table_add_key">TABLE ADD KEY</a>.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>KEY = { <string> | SERIAL }</b></td>
- <td align="left" valign="top"><para>
- <b>(Optional)</b>
+ functionality is supported by the <command><link
+ linkend="stmtmergeset"> MERGE SET</link> </command> command.
+
+<variablelist>
+ <varlistentry><term><literal> SET ID = ival </literal></term>
+ <listitem><para> ID of the set to which the table is to be added. </para>
+ </varlistentry>
+ <varlistentry><term><literal> ORIGIN = ival </literal></term>
+ <listitem><para> Origin node for the set. A future version of <application/slonik/
+ might figure out this information by itself.</para>
+ </varlistentry>
+ <varlistentry><term><literal> ID = ival </literal></term>
+
+ <listitem><para> 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 <link
+ linkend="stmtlockset">LOCK SET</link> command for example. So
+ these numbers should represent any applicable table hierarchy to
+ make sure the <application/slonik/ command scripts do not deadlock
+ at any critical moment.
+ </varlistentry>
+ <varlistentry><term><literal> FULLY QUALIFIED NAME = 'string' </literal></term>
+ <listitem><para> The full table name as described in
+ <link linkend="stmttableaddkey">TABLE ADD KEY</link>.</para>
+ </varlistentry>
+ <varlistentry><term><literal> KEY = { 'string' | SERIAL } </literal></term>
+ <listitem><para>
+ <emphasis>(Optional)</emphasis>
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
- <a href="#table_add_key">TABLE ADD KEY</a> command. Default
+ <link linkend="stmttableaddkey">TABLE ADD KEY</link> command. Default
is to use the table's primary key. The index name is <emphasis> not </emphasis>
fully qualified; you must omit the namespace.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>COMMENT = <string></b></td>
- <td align="left" valign="top"><para>
- A descriptive text added to the <productname/Slony-I/ configuration data.
- </para></td>
-</tr>
-</table>
-<sect3><title>Example:</title>
-<para>
+
+ </varlistentry>
+ <varlistentry><term><literal> COMMENT = 'string' </literal></term>
+ <listitem><para> A descriptive text added to the table entry. </para>
+ </varlistentry>
+</variablelist>
+</para>
+</Refsect1>
+<Refsect1><Title>Example</Title>
+<Programlisting>
SET ADD TABLE (
- <br> SET ID = 1,
- <br> ORIGIN = 1,
- <br> ID = 20,
- <br> FULLY QUALIFIED NAME = 'public.tracker_ticket',
- <br> COMMENT = 'Support ticket'
- <br>);
-</para>
-</div>
+ SET ID = 1,
+ ORIGIN = 1,
+ ID = 20,
+ FULLY QUALIFIED NAME = 'public.tracker_ticket',
+ COMMENT = 'Support ticket'
+);
+</Programlisting>
+</Refsect1>
+</Refentry>
<!-- **************************************** -->
-<sect3 ="stmt_set_add_sequence"><title>SET ADD SEQUENCE</title>
+<refentry id ="stmtsetaddsequence"><refmeta><refentrytitle>SET ADD SEQUENCE</refentrytitle> </refmeta>
+
+<refnamediv><refname>SET ADD SEQUENCE</refname>
+
+<refpurpose> Configure <productname/Slony-I/ set </refpurpose>
+
+<refsynopsisdiv>
+<cmdsynopsis>
+<command>SET ADD SEQUENCE (options);</command>
+</cmdsynopsis>
+</refsynopsisdiv>
+<refsect1>
+<title>Description</title>
-<div style="margin-left:40px; margin-right:0px;">
-<sect3><title>Synopsis:</title>
- SET ADD SEQUENCE ( <options> );
-<sect3><title>Description:</title>
<para>
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.
-</para>
-<table border="0" cellpadding="10">
-<tr>
- <td align="left" valign="top" nowrap><b>SET ID = <ival></b></td>
- <td align="left" valign="top"><para>
- ID of the set to which the sequence is added.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>ORIGIN = <ival></b></td>
- <td align="left" valign="top"><para>
- The current origin of the set. A future version of <application/slonik/
- might figure out this information by itself.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>ID = <ival></b></td>
- <td align="left" valign="top"><para>
- Unique ID of the sequence.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>FULLY QUALIFIED NAME = <string></b></td>
- <td align="left" valign="top"><para>
- The full sequence name as described in
- <a href="#table_add_key">TABLE ADD KEY</a>.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>COMMENT = <string></b></td>
- <td align="left" valign="top"><para>
- A descriptive text added to the <productname/Slony-I/ configuration data.
- </para></td>
-</tr>
-</table>
-<sect3><title>Example:</title>
-<para>
+ functionality is supported by the <command><link
+ linkend="stmtmergeset"> MERGE SET</link> </command> command.
+
+<variablelist>
+ <varlistentry><term><literal> SET ID = ival </literal></term>
+ <listitem><para> ID of the set to which the sequence is to be added. </para>
+ </varlistentry>
+ <varlistentry><term><literal> ORIGIN = ival </literal></term>
+ <listitem><para> Origin node for the set. A future version of <application/slonik/
+ might figure out this information by itself.</para>
+ </varlistentry>
+ <varlistentry><term><literal> ID = ival </literal></term>
+
+ <listitem><para> Unique ID of the sequence. <note><para> Note that this ID needs to be unique <emphasis/across sequences/ throughout the cluster; the numbering of tables is separate, so you might have a table with ID 20 and a sequence with ID 20, and they would be recognized as separate. </note>
+
+ </varlistentry>
+ <varlistentry><term><literal> FULLY QUALIFIED NAME = 'string' </literal></term>
+ <listitem><para> The full sequence name as described in
+ <link linkend="stmttableaddkey">TABLE ADD KEY</link>.</para>
+ </varlistentry>
+ <varlistentry><term><literal> COMMENT = 'string' </literal></term>
+ <listitem><para> A descriptive text added to the sequence entry. </para>
+ </varlistentry>
+</variablelist>
+</para>
+</Refsect1>
+<Refsect1><Title>Example</Title>
+<Programlisting>
SET ADD SEQUENCE (
- <br> SET ID = 1,
- <br> ORIGIN = 1,
- <br> ID = 21,
- <br> FULLY QUALIFIED NAME = 'public.tracker_ticket_id_seq',
- <br> COMMENT = 'Support ticket id sequence'
- <br>);
-</para>
-</div>
+ SET ID = 1,
+ ORIGIN = 1,
+ ID = 20,
+ FULLY QUALIFIED NAME = 'public.tracker_ticket_id_seq',
+ COMMENT = 'Support ticket ID sequence'
+);
+</Programlisting>
+</Refsect1>
+</Refentry>
<!-- **************************************** -->
-<sect3 ="stmt_set_drop_table"><title>SET DROP TABLE</title>
+<refentry id ="stmtsetdroptable"><refmeta><refentrytitle>SET DROP TABLE</refentrytitle> </refmeta>
-<div style="margin-left:40px; margin-right:0px;">
-<sect3><title>Synopsis:</title>
- SET DROP TABLE ( <options> );
-<sect3><title>Description:</title>
-<para>
- Drop an existing user table to a replication set.
-</para>
+<refnamediv><refname>SET DROP TABLE</refname>
+
+<refpurpose> Configure <productname/Slony-I/ set </refpurpose>
+
+<refsynopsisdiv>
+<cmdsynopsis>
+<command>SET DROP TABLE (options);</command>
+</cmdsynopsis>
+</refsynopsisdiv>
+<refsect1>
+<title>Description</title>
<para>
- Note that this action will <em> not </em> drop a candidate
- primary key created using <TT> TABLE ADD KEY </tt>.
+ Drop a table from a replication set.
</para>
-<table border="0" cellpadding="10">
-<tr>
- <td align="left" valign="top" nowrap><b>ORIGIN = <ival></b></td>
- <td align="left" valign="top"><para>
- The current origin of the set. A future version of <application/slonik/
- might figure out this information by itself.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>ID = <ival></b></td>
- <td align="left" valign="top"><para>
- Unique ID of the table.
- </para></td>
-</tr>
-</table>
-<sect3><title>Example:</title>
<para>
- SET DROP TABLE (
- <br> ORIGIN = 1,
- <br> ID = 20,
- <br>);
+ Note that this action will <emphasis> not </emphasis> drop a candidate
+ primary key created using <link
+ linkend="stmttableaddkey"> <command> TABLE ADD KEY
+ </command></link>.
+
+<variablelist>
+ <varlistentry><term><literal> ORIGIN = ival </literal></term>
+ <listitem><para> Origin node for the set. A future version of <application/slonik/
+ might figure out this information by itself.</para>
+ </varlistentry>
+ <varlistentry><term><literal> ID = ival </literal></term>
+
+ <listitem><para> Unique ID of the table.
+</variablelist>
</para>
-</div>
+</Refsect1>
+<Refsect1><Title>Example</Title>
+<Programlisting>
+SET DROP TABLE (
+ ORIGIN = 1,
+ ID = 20,
+);
+</Programlisting>
+</Refsect1>
+</Refentry>
+
+<!-- **************************************** -->
<!-- **************************************** -->
-<sect3 ="stmt_set_drop_sequence"><title>SET DROP SEQUENCE</title>
+<refentry id ="stmtsetdropsequence"><refmeta><refentrytitle>SET DROP SEQUENCE</refentrytitle> </refmeta>
+
+<refnamediv><refname>SET DROP SEQUENCE</refname>
+
+<refpurpose> Configure <productname/Slony-I/ set </refpurpose>
+
+<refsynopsisdiv>
+<cmdsynopsis>
+<command>SET DROP SEQUENCE (options);</command>
+</cmdsynopsis>
+</refsynopsisdiv>
+<refsect1>
+<title>Description</title>
-<div style="margin-left:40px; margin-right:0px;">
-<sect3><title>Synopsis:</title>
- SET DROP SEQUENCE ( <options> );
-<sect3><title>Description:</title>
<para>
Drops an existing user sequence from a replication set.
-</para>
-<table border="0" cellpadding="10">
-<tr>
- <td align="left" valign="top" nowrap><b>ORIGIN = <ival></b></td>
- <td align="left" valign="top"><para>
- The current origin of the set.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>ID = <ival></b></td>
- <td align="left" valign="top"><para>
- Unique ID of the sequence.
- </para></td>
-</tr>
-</table>
-<sect3><title>Example:</title>
-<para>
+<variablelist>
+ <varlistentry><term><literal> ORIGIN = ival </literal></term>
+ <listitem><para> Origin node for the set. A future version of <application/slonik/
+ might figure out this information by itself.</para>
+ </varlistentry>
+ <varlistentry><term><literal> ID = ival </literal></term>
+
+ <listitem><para> Unique ID of the sequence.
+
+ </varlistentry>
+</variablelist>
+</para>
+</Refsect1>
+<Refsect1><Title>Example</Title>
+<Programlisting>
SET DROP SEQUENCE (
- <br> ORIGIN = 1,
- <br> ID = 21,
- <br>);
-</para>
-</div>
-
+ ORIGIN = 1,
+ ID = 20,
+);
+</Programlisting>
+</Refsect1>
+</Refentry>
<!-- **************************************** -->
-<sect3 ="stmt_set_move_table"><title>SET MOVE TABLE</title>
-
-<div style="margin-left:40px; margin-right:0px;">
-<sect3><title>Synopsis:</title>
- SET MOVE TABLE ( <options> );
-<sect3><title>Description:</title>
-<para>
- 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.
-</para>
-<table border="0" cellpadding="10">
-<tr>
- <td align="left" valign="top" nowrap><b>ORIGIN = <ival></b></td>
- <td align="left" valign="top"><para>
- The current origin of the set. A future version of <application/slonik/
- might figure out this information by itself.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>ID = <ival></b></td>
- <td align="left" valign="top"><para>
- Unique ID of the table.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>NEW SET = <ival></b></td>
- <td align="left" valign="top"><para>
- Unique ID of the new set.
- </para></td>
-</tr>
-</table>
-<sect3><title>Example:</title>
-<para>
+<refentry id ="stmtsetmovetable"><refmeta><refentrytitle>SET MOVE TABLE</refentrytitle> </refmeta>
+
+<refnamediv><refname>SET MOVE TABLE</refname>
+
+<refpurpose> Reconfigure <productname/Slony-I/ set </refpurpose>
+
+<refsynopsisdiv>
+<cmdsynopsis>
+<command>SET MOVE TABLE (options);</command>
+</cmdsynopsis>
+</refsynopsisdiv>
+<refsect1>
+<title>Description</title>
+
+<para>
+ 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><para> 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.</para></caution>
+
+<variablelist>
+ <varlistentry><term><literal> ORIGIN = ival </literal></term>
+ <listitem><para> Current origin of the set. A future version of <application/slonik/
+ might figure out this information by itself.</para>
+ </varlistentry>
+ <varlistentry><term><literal> ID = ival </literal></term>
+
+ <listitem><para> Unique ID of the table.
+ <varlistentry><term><literal> NEW SET = ival </literal></term>
+
+ <listitem><para> Unique ID of the set to which the table should be added.
+</variablelist>
+</para>
+</Refsect1>
+<Refsect1><Title>Example</Title>
+<Programlisting>
SET MOVE TABLE (
- <br> ORIGIN = 1,
- <br> ID = 20,
- <br> NEW SET = 3
- <br>);
-</para>
-</div>
+ ORIGIN = 1,
+ ID = 20,
+ NEW SET = 3
+);
+</Programlisting>
+</Refsect1>
+</Refentry>
<!-- **************************************** -->
-<sect3 ="stmt_set_move_sequence"><title>SET MOVE SEQUENCE</title>
+<refentry id ="stmtsetmovesequence"><refmeta><refentrytitle>SET MOVE SEQUENCE</refentrytitle> </refmeta>
+
+<refnamediv><refname>SET MOVE SEQUENCE</refname>
+
+<refpurpose> Reconfigure <productname/Slony-I/ set </refpurpose>
+
+<refsynopsisdiv>
+<cmdsynopsis>
+<command>SET MOVE SEQUENCE (options);</command>
+</cmdsynopsis>
+</refsynopsisdiv>
+<refsect1>
+<title>Description</title>
-<div style="margin-left:40px; margin-right:0px;">
-<sect3><title>Synopsis:</title>
- SET MOVE SEQUENCE ( <options> );
-<sect3><title>Description:</title>
<para>
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
+ must originate on the same node and subscribed by the same
+ nodes.
+
+ <caution><Para> 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.
+ key error and breaks replication.</para></caution>
+
+<variablelist>
+ <varlistentry><term><literal> ORIGIN = ival </literal></term>
+ <listitem><para> Origin node for the set. A future version of <application/slonik/
+ might figure out this information by itself.</para>
+ </varlistentry>
+ <varlistentry><term><literal> ID = ival </literal></term>
+
+ <listitem><para> Unique ID of the sequence.
+
+ </varlistentry>
+ <varlistentry><term><literal> NEW SET = ival </literal></term>
+
+ <listitem><para> Unique ID of the set to which the sequence should be moved.
+
+ </varlistentry>
+</variablelist>
</para>
-<table border="0" cellpadding="10">
-<tr>
- <td align="left" valign="top" nowrap><b>ORIGIN = <ival></b></td>
- <td align="left" valign="top"><para>
- The current origin of the set. A future version of <application/slonik/
- might figure out this information by itself.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>ID = <ival></b></td>
- <td align="left" valign="top"><para>
- Unique ID of the sequence.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>NEW SET = <ival></b></td>
- <td align="left" valign="top"><para>
- Unique ID of the new set.
- </para></td>
-</tr>
-</table>
-<sect3><title>Example:</title>
-<para>
+</Refsect1>
+<Refsect1><Title>Example</Title>
+<Programlisting>
SET MOVE SEQUENCE (
- <br> ORIGIN = 1,
- <br> ID = 54,
- <br> NEW SET = 3
- <br>);
-</para>
-</div>
+ ORIGIN = 1,
+ ID = 20,
+ NEW SET = 3
+);
+</Programlisting>
+</Refsect1>
+</Refentry>
<!-- **************************************** -->
-<sect3 ="stmt_store_trigger"><title>STORE TRIGGER</title>
-
-<div style="margin-left:40px; margin-right:0px;">
-<sect3><title>Synopsis:</title>
- STORE TRIGGER ( <options> );
-<sect3><title>Description:</title>
-<para>
- 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.
-</para>
-<table border="0" cellpadding="10">
-<tr>
- <td align="left" valign="top" nowrap><b>TABLE ID = <ival></b></td>
- <td align="left" valign="top"><para>
- The unique, numeric ID number of the table the trigger is defined for.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>TRIGGER NAME = <string></b></td>
- <td align="left" valign="top"><para>
- The name of the trigger as it appears in the pg_trigger
- system catalog.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>EVENT NODE = <ival></b></td>
- <td align="left" valign="top"><para>
- <b>(Optional)</b>
- The ID of the node used to create the configuration event
+<refentry id ="stmtstoretrigger"><refmeta><refentrytitle>STORE TRIGGER</refentrytitle> </refmeta>
+
+<refnamediv><refname>STORE TRIGGER</refname>
+
+<refpurpose> Configure <productname/Slony-I/ set </refpurpose>
+
+<refsynopsisdiv>
+<cmdsynopsis>
+<command>STORE TRIGGER (options);</command>
+</cmdsynopsis>
+</refsynopsisdiv>
+<refsect1>
+<title>Description</title>
+
+<para> 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.
+
+<variablelist>
+ <varlistentry><term><literal> TABLE ID = ival </literal></term>
+ <listitem><para> The unique, numeric ID number of the table the trigger is defined for.
+
+ </varlistentry>
+ <varlistentry><term><literal> TRIGGER NAME = 'string' </literal></term>
+
+ <listitem><para> The name of the trigger as it appears in the
+ <envar/pg_trigger/ system catalog.
+
+ </varlistentry>
+ <varlistentry><term><literal> EVENT NODE = ival </literal></term>
+
+ <listitem><para> (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.
- </para></td>
-</tr>
-</table>
-<sect3><title>Example:</title>
-<para>
- STORE TRIGGER (
- <br> TABLE ID = 2,
- <br> TRIGGER NAME = 'cache_invalidation'
- <br>);
-</para>
-</div>
+ </varlistentry>
+</variablelist>
+</para>
+</Refsect1>
+<Refsect1><Title>Example</Title>
+<Programlisting>
+STORE TRIGGER (
+ TABLE ID = 2,
+ TRIGGER NAME = 'cache_invalidation'
+);
+</Programlisting>
+</Refsect1>
+</Refentry>
<!-- **************************************** -->
-<sect3 ="stmt_drop_trigger"><title>DROP TRIGGER</title>
-
-<div style="margin-left:40px; margin-right:0px;">
-<sect3><title>Synopsis:</title>
- DROP TRIGGER ( <options> );
-<sect3><title>Description:</title>
-<para>
- Remove the special handling for the specified trigger.
-</para>
-<table border="0" cellpadding="10">
-<tr>
- <td align="left" valign="top" nowrap><b>TABLE ID = <ival></b></td>
- <td align="left" valign="top"><para>
- The unique, numeric ID number of the table the trigger is defined for.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>TRIGGER NAME = <string></b></td>
- <td align="left" valign="top"><para>
- The name of the trigger as it appears in the pg_trigger
- system catalog.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>EVENT NODE = <ival></b></td>
- <td align="left" valign="top"><para>
- <b>(Optional)</b>
- 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.
- </para></td>
-</tr>
-</table>
-<sect3><title>Example:</title>
-<para>
- DROP TRIGGER (
- <br> TABLE ID = 2,
- <br> TRIGGER NAME = 'cache_invalidation'
- <br>);
-</para>
-</div>
+<refentry id ="stmtdroptrigger"><refmeta><refentrytitle>DROP TRIGGER</refentrytitle> </refmeta>
+<refnamediv><refname>DROP TRIGGER</refname>
-<!-- **************************************** -->
+<refpurpose> Reconfigure <productname/Slony-I/ set </refpurpose>
-<sect3 ="stmt_subscribe_set"><title>SUBSCRIBE SET</title>
+<refsynopsisdiv>
+<cmdsynopsis>
+<command>DROP TRIGGER (options);</command>
+</cmdsynopsis>
+</refsynopsisdiv>
+<refsect1>
+<title>Description</title>
-<div style="margin-left:40px; margin-right:0px;">
-<sect3><title>Synopsis:</title>
- SUBSCRIBE SET ( <options> );
-<sect3><title>Description:</title>
-<para>
- 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.
-</para>
-<para>
- The application tables contained in the set must already exist
- and should ideally be currently empty. The current version of
- <productname/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.
+<para> Remove the special handling for the specified trigger.
+
+<variablelist>
+ <varlistentry><term><literal> TABLE ID = ival </literal></term>
+ <listitem><para> The unique, numeric ID number of the table the trigger is defined for.
+
+ </varlistentry>
+ <varlistentry><term><literal> TRIGGER NAME = 'string' </literal></term>
+
+ <listitem><para> The name of the trigger as it appears in the
+ <envar/pg_trigger/ system catalog.
+
+ </varlistentry>
+ <varlistentry><term><literal> EVENT NODE = ival </literal></term>
+
+ <listitem><para> (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.
+
+ </varlistentry>
+</variablelist>
</para>
+</Refsect1>
+<Refsect1><Title>Example</Title>
+<Programlisting>
+DROP TRIGGER (
+ TABLE ID = 2,
+ TRIGGER NAME = 'cache_invalidation'
+);
+</Programlisting>
+</Refsect1>
+</Refentry>
+
+<!-- **************************************** -->
+<refentry id ="stmtsubscribeset"><refmeta><refentrytitle>SUBSCRIBE SET</refentrytitle> </refmeta>
+
+<refnamediv><refname>SUBSCRIBE SET</refname>
+
+<refpurpose> Start replication of <productname/Slony-I/ set </refpurpose>
+
+<refsynopsisdiv>
+<cmdsynopsis>
+<command>SUBSCRIBE SET (options);</command>
+</cmdsynopsis>
+</refsynopsisdiv>
+<refsect1>
+<title>Description</title>
+
+<para> Causes a node (subscriber) to start replicating a set of tables
+either from the origin or from another provider node, which must be an
+active, forwarding subscriber itself.
+
+<para> The application tables contained in the set must already exist
+and should ideally be empty. The current version of
+<productname/Slony-I/ will <emphasis/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.
+</para>
+
+<para> If the tables on the subscriber are <emphasis/not/ empty, then
+the <command/COPY SET/ process winds up doing more work than should be
+strictly necessary:
+<itemizedlist>
+<listitem><para> It deletes all <quote/old/ entries in the table
+<listitem><para> Those old entries clutter up the table until it is next <command/VACUUM/ed <emphasis/after/ the subscription process is complete
+<listitem><para> The indices for the table will contain entries for the old, deleted entries, which will slow the process of inserting new entries into the index.
+</itemizedlist>
-<para>
- Note: If you need to revise subscription information for a
+
+<note><para>
+ 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 <emphasis>
different </emphasis> provider node, or for a node to become a
- "forwarding" subscriber so it may later become the provider
- for a later subscriber.
+ <quote/forwarding/ subscriber so it may later become the
+ provider
+ for a later subscriber. </note>
-</para>
-<table border="0" cellpadding="10">
-<tr>
- <td align="left" valign="top" nowrap><b>ID = <ival></b></td>
- <td align="left" valign="top"><para>
- ID of the set to subscribe
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>PROVIDER = <ival></b></td>
- <td align="left" valign="top"><para>
- Node ID of the data provider where this set is subscribed from.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>RECEIVER = <ival></b></td>
- <td align="left" valign="top"><para>
- Node ID of the new subscriber.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>FORWARD = <boolean></b></td>
- <td align="left" valign="top"><para>
- Flag whether or not the new subscriber should store
+
+
+<variablelist>
+ <varlistentry><term><literal> ID = ival </literal></term>
+ <listitem><para> ID of the set to subscribe
+
+ </varlistentry>
+ <varlistentry><term><literal> PROVIDER = ival </literal></term>
+
+ <listitem><para> Node ID of the data provider from which this node draws data.
+
+ </varlistentry>
+ <varlistentry><term><literal> RECEIVER = ival </literal></term>
+
+ <listitem><para> Node ID of the new subscriber
+
+ </varlistentry>
+ <varlistentry><term><literal> FORWARD = boolean </literal></term>
+
+ <listitem><para> 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.
- </para></td>
-</tr>
-</table>
-<sect3><title>Example:</title>
-<para>
- SUBSCRIBE SET (
- <br> ID = 1,
- <br> PROVIDER = 1,
- <br> RECEIVER = 3,
- <br> FORWARD = YES
- <br>);
-</para>
-</div>
+ </varlistentry>
+</variablelist>
+</para>
+</Refsect1>
+<Refsect1><Title>Example</Title>
+<Programlisting>
+SUBSCRIBE SET (
+ ID = 1,
+ PROVIDER = 1,
+ RECEIVER = 3,
+ FORWARD = YES
+);
+</Programlisting>
+</Refsect1>
+</Refentry>
+
<!-- **************************************** -->
-<sect3 ="stmt_unsubscribe_set"><title>UNSUBSCRIBE SET</title>
+<refentry id ="stmtunsubscribeset"><refmeta><refentrytitle>UNSUBSCRIBE SET</refentrytitle> </refmeta>
+
+<refnamediv><refname>UNSUBSCRIBE SET</refname>
+
+<refpurpose> End replication of <productname/Slony-I/ set </refpurpose>
+
+<refsynopsisdiv>
+<cmdsynopsis>
+<command>UNSUBSCRIBE SET (options);</command>
+</cmdsynopsis>
+</refsynopsisdiv>
+<refsect1>
+<title>Description</title>
-<div style="margin-left:40px; margin-right:0px;">
-<sect3><title>Synopsis:</title>
- UNSUBSCRIBE SET ( <options> );
-<sect3><title>Description:</title>
<para>
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.
-</para>
-<para>
- <b>Warning!</b> Resubscribing an unsubscribed set requires a
- <emphasis>complete fresh copy</emphasis> of data from the provider to be
- transferred since the tables have been subject to possible
- independent modifications.
-</para>
-<table border="0" cellpadding="10">
-<tr>
- <td align="left" valign="top" nowrap><b>ID = <ival></b></td>
- <td align="left" valign="top"><para>
- ID of the set to unsubscribe.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>RECEIVER = <ival></b></td>
- <td align="left" valign="top"><para>
- Node ID of the subscriber.
- </para></td>
-</tr>
-</table>
-<sect3><title>Example:</title>
-<para>
+
+<warning><para> Resubscribing an unsubscribed set requires a
+<emphasis>complete fresh copy</emphasis> of data from the provider to
+be transferred since the tables have been subject to possible
+independent modifications. </para></warning>
+
+<variablelist>
+ <varlistentry><term><literal> ID = ival </literal></term>
+ <listitem><para> ID of the set to unsubscribe
+
+ </varlistentry>
+ <varlistentry><term><literal> RECEIVER = ival </literal></term>
+
+ <listitem><para> Node ID of the (former) subscriber
+
+ </varlistentry>
+</variablelist>
+</para>
+</Refsect1>
+<Refsect1><Title>Example</Title>
+<Programlisting>
UNSUBSCRIBE SET (
- <br> ID = 1,
- <br> RECEIVER = 3
- <br>);
-</para>
-</div>
+ ID = 1,
+ RECEIVER = 3
+);
+</Programlisting>
+</Refsect1>
+</Refentry>
<!-- **************************************** -->
-<sect3 ="stmt_lock_set"><title>LOCK SET</title>
+<refentry id ="stmtlockset"><refmeta><refentrytitle>LOCK SET</refentrytitle> </refmeta>
+
+<refnamediv><refname>LOCK SET</refname>
+
+<refpurpose> Configuration of <productname/Slony-I/ set </refpurpose>
+<refsynopsisdiv>
+<cmdsynopsis>
+<command>LOCK SET (options);</command>
+</cmdsynopsis>
+</refsynopsisdiv>
+<refsect1>
+<title>Description</title>
-<div style="margin-left:40px; margin-right:0px;">
-<sect3><title>Synopsis:</title>
- LOCK SET ( <options> );
-<sect3><title>Description:</title>
<para>
Guards a replication set against client application updates in
- preparation for a <a href="#stmt_move_set">MOVE SET</a>
+ preparation for a <link linkend="stmtmoveset">MOVE SET</link>
command.
</para>
<para>
This command must be the first in a possible statement group
- (<tt>try</tt>). The reason for this is that it needs to
+ (<command>try</command>). 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.
+
+
+<variablelist>
+ <varlistentry><term><literal> ID = ival </literal></term>
+ <listitem><para> ID of the set to lock
+
+ </varlistentry>
+ <varlistentry><term><literal> ORIGIN = ival </literal></term>
+
+ <listitem><para> Node ID of the current set origin
+
+ </varlistentry>
+</variablelist>
</para>
-<table border="0" cellpadding="10">
-<tr>
- <td align="left" valign="top" nowrap><b>ID = <ival></b></td>
- <td align="left" valign="top"><para>
- ID of the set to lock.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>ORIGIN = <ival></b></td>
- <td align="left" valign="top"><para>
- Node ID of the current set origin.
- </para></td>
-</tr>
-</table>
-<sect3><title>Example:</title>
-<para>
+</Refsect1>
+<Refsect1><Title>Example</Title>
+<Programlisting>
LOCK SET (
- <br> ID = 1,
- <br> ORIGIN = 1
- <br>);
-</para>
-</div>
-
+ ID = 1,
+ RECEIVER = 3
+);
+</Programlisting>
+</Refsect1>
+</Refentry>
<!-- **************************************** -->
-<sect3 ="stmt_unlock_set"><title>UNLOCK SET</title>
-
-<div style="margin-left:40px; margin-right:0px;">
-<sect3><title>Synopsis:</title>
- UNLOCK SET ( <options> );
-<sect3><title>Description:</title>
-<para>
- Unlock a previously locked set.
-</para>
-<table border="0" cellpadding="10">
-<tr>
- <td align="left" valign="top" nowrap><b>ID = <ival></b></td>
- <td align="left" valign="top"><para>
- ID of the set to unlock.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>ORIGIN = <ival></b></td>
- <td align="left" valign="top"><para>
- Node ID of the current set origin.
- </para></td>
-</tr>
-</table>
-<sect3><title>Example:</title>
+<refentry id ="stmtunlockset"><refmeta><refentrytitle>UNLOCK SET</refentrytitle> </refmeta>
+
+<refnamediv><refname>UNLOCK SET</refname>
+
+<refpurpose> Configuration of <productname/Slony-I/ set </refpurpose>
+<refsynopsisdiv>
+<cmdsynopsis>
+<command>UNLOCK SET (options);</command>
+</cmdsynopsis>
+</refsynopsisdiv>
+<refsect1>
+<title>Description</title>
+
<para>
- UNLOCK SET (
- <br> ID = 1,
- <br> ORIGIN = 1
- <br>);
+ Unlocks a previously locked set.
+
+
+<variablelist>
+ <varlistentry><term><literal> ID = ival </literal></term>
+ <listitem><para> ID of the set to unlock
+
+ </varlistentry>
+ <varlistentry><term><literal> ORIGIN = ival </literal></term>
+
+ <listitem><para> Node ID of the current set origin
+
+ </varlistentry>
+</variablelist>
</para>
-</div>
+</Refsect1>
+<Refsect1><Title>Example</Title>
+<Programlisting>
+UNLOCK SET (
+ ID = 1,
+ RECEIVER = 3
+);
+</Programlisting>
+</Refsect1>
+</Refentry>
<!-- **************************************** -->
-<sect3 ="stmt_move_set"><title>MOVE SET</title>
+<refentry id ="stmtmoveset"><refmeta><refentrytitle>MOVE SET</refentrytitle> </refmeta>
+
+<refnamediv><refname>MOVE SET</refname>
+
+<refpurpose> Reconfiguration of <productname/Slony-I/ set </refpurpose>
+<refsynopsisdiv>
+<cmdsynopsis>
+<command>MOVE SET (options);</command>
+</cmdsynopsis>
+</refsynopsisdiv>
+<refsect1>
+<title>Description</title>
-<div style="margin-left:40px; margin-right:0px;">
-<sect3><title>Synopsis:</title>
- MOVE SET ( <options> );
-<sect3><title>Description:</title>
<para>
- 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.
-</para>
+ 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. </para>
+
<para>
After this command, the set cannot be unlocked on the old
origin any more. The old origin will continue as a forwarding
@@ -1468,59 +1602,64 @@
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,
- <emphasis>i.e.</i> fully catching up), the new origin will take over
- and open all tables in the set for client application update
+ <emphasis>i.e.</emphasis> fully catching up), the new origin
+ will take over and open all tables in the set for client
+ application update
activity.
</para>
<para>
- This is not failover, as it requires a fully functional old
- origin node.
+ This is <emphasis/not/ failover, as it requires a functioning
+ old origin node (you needed to lock the set on the old
+ origin). You would probably prefer to <command/MOVE SET/
+ instead of <command/FAILOVER/, if at all possible, as
+ <command/FAILOVER/ winds up discarding the old origin node as
+ being corrupted.
+
+
+<variablelist>
+ <varlistentry><term><literal> ID = ival </literal></term>
+ <listitem><para> ID of the set to transfer
+
+ </varlistentry>
+ <varlistentry><term><literal> OLD ORIGIN = ival </literal></term>
+
+ <listitem><para> Node ID of the current set origin
+
+ </varlistentry>
+ <varlistentry><term><literal> NEW ORIGIN = ival </literal></term>
+
+ <listitem><para> Node ID of the new set origin
+
+ </varlistentry>
+</variablelist>
</para>
-<table border="0" cellpadding="10">
-<tr>
- <td align="left" valign="top" nowrap><b>ID = <ival></b></td>
- <td align="left" valign="top"><para>
- ID of the set to transfer.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>OLD ORIGIN = <ival></b></td>
- <td align="left" valign="top"><para>
- Node ID of the current set origin.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>NEW ORIGIN = <ival></b></td>
- <td align="left" valign="top"><para>
- Node ID of the new set origin.
- </para></td>
-</tr>
-</table>
-<sect3><title>Example:</title>
-<para>
+</Refsect1>
+<Refsect1><Title>Example</Title>
+<Programlisting>
MOVE SET (
- <br> ID = 1,
- <br> OLD ORIGIN = 1,
- <br> NEW ORIGIN = 3
- <br>);
-</para>
-</div>
-
+ ID = 1,
+ OLD ORIGIN = 1,
+ NEW ORIGIN = 3
+);
+</Programlisting>
+</Refsect1>
+</Refentry>
<!-- **************************************** -->
-<sect3 ="stmt_failover"><title>FAILOVER</title>
+<refentry id ="stmtfailover"><refmeta><refentrytitle>FAILOVER</refentrytitle> </refmeta>
+
+<refnamediv><refname>FAILOVER</refname>
+
+<refpurpose> Reconfiguration of <productname/Slony-I/ set </refpurpose>
+<refsynopsisdiv>
+<cmdsynopsis>
+<command>FAILOVER (options);</command>
+</cmdsynopsis>
+</refsynopsisdiv>
+<refsect1>
+<title>Description</title>
-<div style="margin-left:40px; margin-right:0px;">
-<sect3><title>Synopsis:</title>
- FAILOVER ( <options> );
-<sect3><title>Description:</title>
-<para>
- 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.
-</para>
<para>
The failover command causes the backup node to take over all
sets that currently originate on the failed node. <Application/Slonik/ will
@@ -1535,168 +1674,195 @@
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 <tt>DROP NODE</tt>.
+ configuration with <command><link linkend="stmtdropnode"> DROP NODE</link> </command>.
</para>
-<table border="0" cellpadding="10">
-<tr>
- <td align="left" valign="top" nowrap><b>ID = <ival></b></td>
- <td align="left" valign="top"><para>
- ID of the failed node.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>BACKUP NODE = <ival></b></td>
- <td align="left" valign="top"><para>
- ID of the node that will take over all sets.
- </para></td>
-</tr>
-</table>
-<sect3><title>Example:</title>
-<para>
+
+<warning><para> 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. It would often be highly preferable to use <command> <link linkend="stmtmoveset"> MOVE SET </link> </command> instead.
+</para></warning>
+
+<variablelist>
+ <varlistentry><term><literal> ID = ival </literal></term>
+ <listitem><para> ID of the failed node
+
+ </varlistentry>
+ <varlistentry><term><literal> BACKUP NODE = ival </literal></term>
+
+ <listitem><para> Node ID of the node that will take over all sets originating on the failed node
+
+ </varlistentry>
+</variablelist>
+
+</Refsect1>
+<Refsect1><Title>Example</Title>
+<Programlisting>
FAILOVER (
- <br> ID = 1,
- <br> BACKUP NODE = 1,
- <br>);
-</para>
-</div>
+ ID = 1,
+ BACKUP NODE = 2
+);
+</Programlisting>
+</Refsect1>
+</Refentry>
<!-- **************************************** -->
-<sect3 ="stmt_ddl_script"><title>EXECUTE SCRIPT</title>
+<refentry id ="stmtddlscript"><refmeta><refentrytitle>EXECUTE SCRIPT</refentrytitle> </refmeta>
-<div style="margin-left:40px; margin-right:0px;">
-<sect3><title>Synopsis:</title>
- EXECUTE SCRIPT ( <options> );
-<sect3><title>Description:</title>
-<para>
- 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.
-</para>
-<para>
- 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
+<refnamediv><refname>EXECUTE SCRIPT</refname>
+
+<refpurpose> Reconfiguration of <productname/Slony-I/ set </refpurpose>
+<refsynopsisdiv>
+<cmdsynopsis>
+<command>EXECUTE SCRIPT (options);</command>
+</cmdsynopsis>
+</refsynopsisdiv>
+<refsect1>
+<title>Description</title>
+
+<para> 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.</para>
+
+<para> The specified event origin must be the origin of the set. The
+script file must not contain any <command/START/ or <command/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.
-</para>
-<table border="0" cellpadding="10">
-<tr>
- <td align="left" valign="top" nowrap><b>SET ID = <ival></b></td>
- <td align="left" valign="top"><para>
- The unique, numeric ID number of the set affected by the script.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>FILENAME = <string></b></td>
- <td align="left" valign="top"><para>
- The name of the file containing the SQL script to execute.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>EVENT NODE = <ival></b></td>
- <td align="left" valign="top"><para>
- <b>(Optional)</b>
- The ID of the current origin of the set.
- The default value is 1.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>EXECUTE ONLY ON = <ival></b></td>
- <td align="left" valign="top"><para>
- <b>(Optional)</b>
- The ID of the only node to actually execute the script.
+<function/CURRENT_TIMESTAMP/) must be avoided, since the data changes
+done by the script are explicitly not replicated. </para>
+
+<variablelist>
+ <varlistentry><term><literal> SET ID = ival </literal></term>
+ <listitem><para> The unique numeric ID number of the set affected by the script
+
+ </varlistentry>
+ <varlistentry><term><literal> FILENAME = '/path/to/file' </literal></term>
+
+ <listitem><para> The name of the file containing the SQL script to
+ execute. This might be a relative path, relative to the location of
+ the <application/slonik/ instance you are running, or, preferably,
+ an absolute path on the system where <application/slonik/ is to run.
+
+ <para> The <emphasis/contents/ of the file are propagated as part of
+ the event, so the file does not need to be accessible on any of the
+ nodes.
+
+ </varlistentry>
+ <varlistentry><term><literal> EVENT NODE = ival </literal></term>
+ <listitem><para> (Optional) The ID of the current origin of the set. Default value is 1.
+
+ </varlistentry>
+ <varlistentry><term><literal> EXECUTE ONLY ON = ival </literal></term>
+ <listitem><para> (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.
- </para></td>
-</tr>
-</table>
-<sect3><title>Example:</title>
-<para>
+
+
+ </varlistentry>
+</variablelist>
+
+<para> See also the warnings in <link linkend="ddlchanges"> Database
+Schema Changes (DDL)</link>.
+
+</Refsect1>
+<Refsect1><Title>Example</Title>
+<Programlisting>
EXECUTE SCRIPT (
- <br> SET ID = 1,
- <br> FILENAME = 'changes_20040510.sql',
- <br> EVENT NODE = 1
- <br>);
-</para>
-</div>
+ SET ID = 1,
+ FILENAME = '/tmp/changes_2004-05-01.sql',
+ EVENT NODE = 1
+);
+</Programlisting>
+</Refsect1>
+</Refentry>
<!-- **************************************** -->
-<sect3 ="stmt_wait_event"><title>WAIT FOR EVENT</title>
+<refentry id ="stmtwaitevent"><refmeta><refentrytitle>WAIT FOR EVENT</refentrytitle> </refmeta>
-<div style="margin-left:40px; margin-right:0px;">
-<sect3><title>Synopsis:</title>
- WAIT FOR EVENT ( <options> );
-<sect3><title>Description:</title>
-<para>
- Waits for event confirmation.
-</para>
-<para>
- <Application/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 <tt>CREATE
- SET</tt>) are processed on another node before issuing more
- commands (for instance, <a
- href="#stmt_subscribe_set">SUBSCRIBE SET</a>). <tt>WAIT FOR
- EVENT</tt> may be used to cause the <application/slonik/ script to wait
- until the subscriber node is ready for the next action.
+<refnamediv><refname>WAIT FOR EVENT</refname>
+
+<refpurpose> Reconfiguration of <productname/Slony-I/ set </refpurpose>
+<refsynopsisdiv>
+<cmdsynopsis>
+<command>WAIT FOR EVENT (options);</command>
+</cmdsynopsis>
+</refsynopsisdiv>
+<refsect1>
+<title>Description</title>
+
+<para> Waits for event Confirmation.
+
+<para> <Application/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 <command>CREATE SET</command>)
+are processed on another node before issuing more commands (for
+instance, <link linkend="stmtsubscribeset"><command/SUBSCRIBE
+SET/</link>). <COMMAND>WAIT FOR EVENT</COMMAND> may be used to cause
+the <application/slonik/ script to wait until the subscriber node is
+ready for the next action.
</para>
-<para>
- <tt>WAIT FOR EVENT</tt> must be called outside of any try
- block in order to work, since new confirm messages don't
+
+<para> <command>WAIT FOR EVENT</command> must be called outside of any
+<command/try/ block in order to work, since new confirm messages don't
become visible within a transaction.
-</para>
-<table border="0" cellpadding="10">
-<tr>
- <td align="left" valign="top" nowrap><b>ORIGIN = <ival>|ALL</b></td>
- <td align="left" valign="top"><para>
- The origin of the event(s) to wait for.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>CONFIRMED = <ival>|ALL</b></td>
- <td align="left" valign="top"><para>
- The node ID of the receiver that must have confirmed the event(s).
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>WAIT ON = <ival></b></td>
- <td align="left" valign="top"><para>
- The ID of the node where to check the sl_confirm table.
- The default value is 1.
- </para></td>
-</tr>
-<tr>
- <td align="left" valign="top" nowrap><b>TIMEOUT = <ival></b></td>
- <td align="left" valign="top"><para>
- The number of seconds to wait. Default is 600 (10 minutes),
- 0 means wait forever.
- </para></td>
-</tr>
-</table>
-<sect3><title>Example:</title>
-<para>
- WAIT FOR EVENT (
- <br> ORIGIN = ALL,
- <br> CONFIRMED = ALL,
- <br> WAIT ON = 1
- <br>);
+<variablelist>
+ <varlistentry><term><literal> ORIGIN = ival | ALL </literal></term>
+ <listitem><para> The origin of the event(s) to wait for.
+
+ </varlistentry>
+ <varlistentry><term><literal> CONFIRMED = ival | ALL </literal></term>
-<sect1 id="slonikprocs"> <title/Slonik Stored Procedures/
+ <listitem><para> The node ID of the receiver that must confirm the event(s).
-<para> The commands used in <Application/Slonik/ invoke stored procedures in the
-namespace created for the replication instance. <Application/Slonik/ provides one
-convenient way to invoke these procedures; it is just as possible to
-invoke them directly to manage the <productname/Slony-I/ instances. </para>
+ </varlistentry>
+ <varlistentry><term><literal> WAIT ON = ival </literal></term>
+ <listitem><para> The ID of the node where the sl_confirm table is to be checked. The default value is 1.
-<para> See the <a href= "schemadoc.html"> Schema Documentation </a> for
-more details. </para>
+ </varlistentry>
+ <varlistentry><term><literal> TIMEOUT = ival </literal></term>
+
+ <listitem><para> The number of seconds to wait. Default is 600 (10
+ minutes). <command/TIMEOUT = 0/ causes the script to wait
+ indefinitely.
+
+ </varlistentry>
+</variablelist>
+
+</Refsect1>
+<Refsect1><Title>Example</Title>
+<Programlisting>
+WAIT FOR EVENT (
+ ORIGIN = ALL,
+ CONFIRMED = ALL,
+ WAIT ON = 1
+);
+</Programlisting>
+</Refsect1>
+</Refentry>
+</reference>
+
+<!-- Keep this comment at the end of the file
+Local variables:
+mode:sgml
+sgml-omittag:nil
+sgml-shorttag:t
+sgml-minimize-attributes:nil
+sgml-always-quote-attributes:t
+sgml-indent-step:1
+sgml-indent-data:t
+sgml-parent-document:nil
+sgml-default-dtd-file:"./reference.ced"
+sgml-exposed-tags:nil
+sgml-local-catalogs:("/usr/lib/sgml/catalog")
+sgml-local-ecat-files:nil
+End:
+-->
Index: cluster.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/cluster.sgml,v
retrieving revision 1.4
retrieving revision 1.5
diff -Ldoc/adminguide/cluster.sgml -Ldoc/adminguide/cluster.sgml -u -w -r1.4 -r1.5
--- doc/adminguide/cluster.sgml
+++ doc/adminguide/cluster.sgml
@@ -1,9 +1,10 @@
<sect1 id="cluster"> <title>Defining Slony-I Clusters</title>
-<para>A <productname/Slony-I/ cluster is the basic grouping of
-database instances in which replication takes place. It consists of a
-set of <productname/PostgreSQL/ database instances in which is defined
-a namespace specific to that cluster.
+<para>A <productname>Slony-I</productname> cluster is the basic
+grouping of database instances in which replication takes place. It
+consists of a set of <productname>PostgreSQL</productname> database
+instances in which is defined a namespace specific to that
+cluster.</para>
<para>Each database instance in which replication is to take place is
identified by a node number.
@@ -17,10 +18,10 @@
correspond to the shape of the environment, as opposed to (say) the
order in which nodes were initialized.
-<para>It may be that in version 1.1, nodes will also have a "name"
-attribute, so that they may be given more mnemonic names. In that
-case, the node numbers can be cryptic; it will be the node name that
-is used to organize the cluster.
+<para>It may be that in version 1.1, nodes will also have a
+<quote/name/ attribute, so that they may be given more mnemonic names.
+In that case, the node numbers might remain somewhat cryptic; it will
+be the node name that is used to organize the cluster.
</sect1>
<!-- Keep this comment at the end of the file
Index: filelist.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/filelist.sgml,v
retrieving revision 1.3
retrieving revision 1.4
diff -Ldoc/adminguide/filelist.sgml -Ldoc/adminguide/filelist.sgml -u -w -r1.3 -r1.4
--- doc/adminguide/filelist.sgml
+++ doc/adminguide/filelist.sgml
@@ -23,6 +23,7 @@
<!entity faq SYSTEM "faq.sgml">
<!entity reference SYSTEM "reference.sgml">
<!entity slonik SYSTEM "slonik.sgml">
+<!entity slonikref SYSTEM "slonik_ref.sgml">
<!entity slon SYSTEM "slon.sgml">
<!entity history SYSTEM "history.sgml">
Index: concepts.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/concepts.sgml,v
retrieving revision 1.4
retrieving revision 1.5
diff -Ldoc/adminguide/concepts.sgml -Ldoc/adminguide/concepts.sgml -u -w -r1.4 -r1.5
--- doc/adminguide/concepts.sgml
+++ doc/adminguide/concepts.sgml
@@ -1,7 +1,7 @@
-<sect1 id="concepts"> <title>Slony-I Concepts</title>
+<sect1 id="concepts"> <title><productname/Slony-I/ Concepts</title>
-<para>In order to set up a set of Slony-I replicas, it is necessary to
+<para>In order to set up a set of <productname/Slony-I/ replicas, it is necessary to
understand the following major abstractions that it uses:
<itemizedlist>
@@ -13,7 +13,7 @@
<sect2><title>Cluster</title>
-<para>In Slony-I terms, a Cluster is a named set of PostgreSQL
+<para>In <productname/Slony-I/ terms, a Cluster is a named set of PostgreSQL
database instances; replication takes place between those databases.
<para>The cluster name is specified in each and every Slonik script via the directive:
@@ -21,33 +21,33 @@
cluster name = 'something';
</programlisting>
-<para>If the Cluster name is <envar/something/, then Slony-I will
+<para>If the Cluster name is <envar/something/, then <productname/Slony-I/ will
create, in each database instance in the cluster, the namespace/schema
<envar/_something/.
<sect2><title> Node</title>
-<para>A Slony-I Node is a named PostgreSQL database that will be participating in replication.
+<para>A <productname/Slony-I/ Node is a named PostgreSQL database that will be participating in replication.
<para>It is defined, near the beginning of each Slonik script, using the directive:
<programlisting>
NODE 1 ADMIN CONNINFO = 'dbname=testdb host=server1 user=slony';
</programlisting>
-<para>The CONNINFO information indicates a string argument that will
-ultimately be passed to the <function>PQconnectdb()</function> libpq
-function.
+<para>The <link linkend="admconninfo"> <command/CONNINFO/</link>
+information indicates a string argument that will ultimately be passed
+to the <function>PQconnectdb()</function> libpq function.
-<para>Thus, a Slony-I cluster consists of:
+<para>Thus, a <productname/Slony-I/ cluster consists of:
<itemizedlist>
<listitem><para> A cluster name
- <listitem><para> A set of Slony-I nodes, each of which has a namespace based on that cluster name
+ <listitem><para> A set of <productname/Slony-I/ nodes, each of which has a namespace based on that cluster name
</itemizedlist>
<sect2><title> Replication Set</title>
<para>A replication set is defined as a set of tables and sequences
-that are to be replicated between nodes in a Slony-I cluster.
+that are to be replicated between nodes in a <productname/Slony-I/ cluster.
<para>You may have several sets, and the <quote/flow/ of replication does
not need to be identical between those sets.
@@ -65,7 +65,7 @@
<para>The origin node will never be considered a <quote/subscriber./
(Ignoring the case where the cluster is reshaped, and the origin is
-moved to another node.) But Slony-I supports the notion of cascaded
+moved to another node.) But <productname/Slony-I/ supports the notion of cascaded
subscriptions, that is, a node that is subscribed to the origin may
also behave as a <quote/provider/ to other nodes in the cluster.
Index: maintenance.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/maintenance.sgml,v
retrieving revision 1.4
retrieving revision 1.5
diff -Ldoc/adminguide/maintenance.sgml -Ldoc/adminguide/maintenance.sgml -u -w -r1.4 -r1.5
--- doc/adminguide/maintenance.sgml
+++ doc/adminguide/maintenance.sgml
@@ -17,12 +17,12 @@
<para> In some versions (1.1, for sure; possibly 1.0.5) there is the
option of not bothering to vacuum any of these tables if you are using
-something like <application/pg_autovacuum/ to handle vacuuming of
-these tables. Unfortunately, it has been quite possible for
-<application/pg_autovacuum/ to not vacuum quite frequently enough, so
-you probably want to use the internal vacuums. Vacuuming pg_listener
-"too often" isn't nearly as hazardous as not vacuuming it frequently
-enough.
+something like <application>pg_autovacuum</application> to handle
+vacuuming of these tables. Unfortunately, it has been quite possible
+for <application>pg_autovacuum</application> to not vacuum quite
+frequently enough, so you probably want to use the internal vacuums.
+Vacuuming pg_listener <quote>too often</quote> isn't nearly as
+hazardous as not vacuuming it frequently enough.</para>
<para>Unfortunately, if you have long-running transactions, vacuums
cannot clear out dead tuples that are newer than the eldest
@@ -46,9 +46,9 @@
<application/generate_syncs.sh/, which addresses the following kind of
situation.
-<para>Supposing you have some possibly-flakey server where the <application/slon/
-daemon that might not run all the time, you might return from a
-weekend away only to discover the following situation...
+<para>Supposing you have some possibly-flakey server where the
+<application/slon/ daemon that might not run all the time, you might
+return from a weekend away only to discover the following situation...
<para>On Friday night, something went <quote/bump/ and while the
database came back up, none of the <application/slon/ daemons
@@ -59,14 +59,14 @@
master since Friday, so that the next <quote/SYNC set/ comprises all
of the updates between Friday and Monday. Yuck.
-<para>If you run <application/generate_syncs.sh/ as a cron job every 20 minutes, it
-will force in a periodic SYNC on the origin, which means that
-between Friday and Monday, the numerous updates are split into more
-than 100 syncs, which can be applied incrementally, making the cleanup
-a lot less unpleasant.
+<para>If you run <application/generate_syncs.sh/ as a cron job every
+20 minutes, it will force in a periodic <command/SYNC/ on the origin, which
+means that between Friday and Monday, the numerous updates are split
+into more than 100 syncs, which can be applied incrementally, making
+the cleanup a lot less unpleasant.
-<para>Note that if SYNCs <emphasis>are</emphasis> running regularly,
-this script won't bother doing anything.
+<para>Note that if <command/SYNC/s <emphasis>are</emphasis> running
+regularly, this script won't bother doing anything.
<sect2><title> Log Files</title>
Index: subscribenodes.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/subscribenodes.sgml,v
retrieving revision 1.4
retrieving revision 1.5
diff -Ldoc/adminguide/subscribenodes.sgml -Ldoc/adminguide/subscribenodes.sgml -u -w -r1.4 -r1.5
--- doc/adminguide/subscribenodes.sgml
+++ doc/adminguide/subscribenodes.sgml
@@ -7,8 +7,9 @@
your head against a wall trying to figure out what is going on.
<para>Subscribing a node to a set is done by issuing the <link
-linkend="slonik"> slonik </link> command <command/subscribe set/. It
-may seem tempting to try to subscribe several nodes to a set within a
+linkend="slonik"> slonik </link> command <command> <link
+linkend="stmtsubscribeset"> subscribe set </link> </command>. It may
+seem tempting to try to subscribe several nodes to a set within a
single try block like this:
<programlisting>
@@ -21,27 +22,29 @@
echo 'Could not subscribe the sets!';
exit -1;
}
-</programlisting>
+</programlisting></para>
<para> But you are just asking for trouble if you try to subscribe
sets in that fashion. The proper procedure is to subscribe one node at
a time, and to check the logs and databases before you move onto
subscribing the next node to the set. It is also worth noting that the
-<quote/success/ within the above <link linkend="slonik">
-<application/slonik/ </link> try block does not imply that nodes 2, 3,
-and 4 have all been successfully subscribed. It merely indicates that
-the slonik commands were successfully received by the
-<application/slon/ running on the origin node.
+<quote>success</quote> within the above <link linkend="slonik">
+<application>slonik</application> </link> try block does not imply
+that nodes 2, 3, and 4 have all been successfully subscribed. It
+merely indicates that the slonik commands were successfully received
+by the <application>slon</application> running on the origin
+node.</para>
<para>A typical sort of problem that will arise is that a cascaded
subscriber is looking for a provider that is not ready yet. In that
-failure case, that subscriber node will <emphasis/never/ pick up the
-subscriber. It will get <quote/stuck/ waiting for a past event to
-take place. The other nodes will be convinced that it is successfully
-subscribed (because no error report ever made it back to them); a
-request to unsubscribe the node will be <quote/blocked/ because the
-node is stuck on the attempt to subscribe it.
+failure case, that subscriber node will <emphasis>never</emphasis>
+pick up the subscriber. It will get <quote>stuck</quote> waiting for
+a past event to take place. The other nodes will be convinced that it
+is successfully subscribed (because no error report ever made it back
+to them); a request to unsubscribe the node will be
+<quote>blocked</quote> because the node is stuck on the attempt to
+subscribe it.</para>
<para>When you subscribe a node to a set, you should see something
like this in your <application/slon/ logs for the provider node:
Index: faq.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/faq.sgml,v
retrieving revision 1.4
retrieving revision 1.5
diff -Ldoc/adminguide/faq.sgml -Ldoc/adminguide/faq.sgml -u -w -r1.4 -r1.5
--- doc/adminguide/faq.sgml
+++ doc/adminguide/faq.sgml
@@ -108,7 +108,9 @@
restart node 4;
</programlisting></para>
-<para> <command>restart node n</command> cleans up dead notifications so that you can restart the node.</para>
+<para> <command> <link linkend="stmtrestartnode"> RESTART NODE </link>
+</command> cleans up dead notifications so that you can restart the
+node.</para>
<para>As of version 1.0.5, the startup process of slon looks for this
condition, and automatically cleans it up.</para>
@@ -124,7 +126,9 @@
<filename><envar>$(HOME)</envar>/.pgpass.</filename></para>
<qandaentry>
-<question><para>Slonik fails - cannot load <productname>PostgreSQL</productname> library - <command>PGRES_FATAL_ERROR load '$libdir/xxid';</command></para>
+<question><para>Slonik fails - cannot load
+<productname>PostgreSQL</productname> library -
+<command>PGRES_FATAL_ERROR load '$libdir/xxid';</command></para>
<para> When I run the sample setup script I get an error message similar
to:
@@ -152,11 +156,12 @@
library directory for the <productname>PostgreSQL</productname>
database cluster that it's hitting.</para>
-<para>Long and short: This points to a need to <quote>audit</quote> what
-installations of <productname>PostgreSQL</productname> and <productname>Slony-I</productname>
-you have in place on the machine(s). Unfortunately, just about any
-mismatch will cause things not to link up quite right. See also <link linkend="slonyfaq02"> SlonyFAQ02 </link> concerning threading issues
-on Solaris ...</para>
+<para>Long and short: This points to a need to <quote>audit</quote>
+what installations of <productname>PostgreSQL</productname> and
+<productname>Slony-I</productname> you have in place on the
+machine(s). Unfortunately, just about any mismatch will cause things
+not to link up quite right. See also <link linkend="slonyfaq02">
+SlonyFAQ02 </link> concerning threading issues on Solaris ...</para>
<qandaentry>
<question><para>Table indexes with FQ namespace names
@@ -168,13 +173,13 @@
comment = 'Table some_table in namespace nspace with a candidate primary key');
</programlisting></para></question>
-<answer><para> If you have <command> key = 'nspace.key_on_whatever'</command>
-the request will <emphasis>FAIL</emphasis>.</para>
+<answer><para> If you have <command> key =
+'nspace.key_on_whatever'</command> the request will
+<emphasis>FAIL</emphasis>.</para>
<qandaentry>
-<question><para>
-I'm trying to get a slave subscribed, and get the following
-messages in the logs:
+<question><para> I'm trying to get a slave subscribed, and get the
+following messages in the logs:
<screen>
DEBUG1 copy_set 1
@@ -244,22 +249,36 @@
CONTEXT: PL/pgSQL function "setaddtable_int" line 71 at SQL statement
</screen></para></question>
-<answer><para>
-The table IDs used in SET ADD TABLE are required to be unique <emphasis>ACROSS
-ALL SETS</emphasis>. Thus, you can't restart numbering at 1 for a second set; if
-you are numbering them consecutively, a subsequent set has to start
-with IDs after where the previous set(s) left off.</para>
+<answer><para> The table IDs used in <command> <link
+linkend="stmtsetaddtable"> SET ADD TABLE </link> </command> are
+required to be unique <emphasis>ACROSS ALL SETS</emphasis>. Thus, you
+can't restart numbering at 1 for a second set; if you are numbering
+them consecutively, a subsequent set has to start with IDs after where
+the previous set(s) left off.</para>
+</answer> </qandaentry>
+
<qandaentry>
<question><para>I need to drop a table from a replication set</para></question>
<answer><para>
This can be accomplished several ways, not all equally desirable ;-).
<itemizedlist>
-<listitem><para> You could drop the whole replication set, and recreate it with just the tables that you need. Alas, that means recopying a whole lot of data, and kills the usability of the cluster on the rest of the set while that's happening.</para></listitem>
-
-<listitem><para> If you are running 1.0.5 or later, there is the command SET DROP TABLE, which will "do the trick."</para></listitem>
-<listitem><para> If you are still using 1.0.1 or 1.0.2, the _essential_ functionality of SET DROP TABLE involves the functionality in droptable_int(). You can fiddle this by hand by finding the table ID for the table you want to get rid of, which you can find in sl_table, and then run the following three queries, on each host:
+<listitem><para> You could drop the whole replication set, and
+recreate it with just the tables that you need. Alas, that means
+recopying a whole lot of data, and kills the usability of the cluster
+on the rest of the set while that's happening.</para></listitem>
+
+<listitem><para> If you are running 1.0.5 or later, there is the
+command SET DROP TABLE, which will "do the trick."</para></listitem>
+
+<listitem><para> If you are still using 1.0.1 or 1.0.2, the
+<emphasis>essential functionality of <command> <link
+linkend="stmtsetdroptable"> SET DROP TABLE</link></command> involves
+the functionality in <function>droptable_int()</function>. You can
+fiddle this by hand by finding the table ID for the table you want to
+get rid of, which you can find in sl_table, and then run the following
+three queries, on each host:</emphasis>
<programlisting>
select _slonyschema.alterTableRestore(40);
@@ -267,30 +286,35 @@
delete from _slonyschema.sl_table where tab_id = 40;
</programlisting></para>
-<para>The schema will obviously depend on how you defined the <productname>Slony-I</productname>
-cluster. The table ID, in this case, 40, will need to change to the
-ID of the table you want to have go away.
+<para>The schema will obviously depend on how you defined the
+<productname>Slony-I</productname> cluster. The table ID, in this
+case, 40, will need to change to the ID of the table you want to have
+go away.</para>
-You'll have to run these three queries on all of the nodes, preferably
+<para> You'll have to run these three queries on all of the nodes, preferably
firstly on the origin node, so that the dropping of this propagates
properly. Implementing this via a <link linkend="slonik"> slonik
-</link> statement with a new <productname>Slony-I</productname> event would do
-that. Submitting the three queries using <command>EXECUTE SCRIPT</command>
-could do that. Also possible would be to connect to each database and
-submit the queries by hand.</para></listitem>
-</itemizedlist></para>
+</link> statement with a new <productname>Slony-I</productname> event
+would do that. Submitting the three queries using <command> <link linkend="stmtddlscript"> EXECUTE SCRIPT </link> </command> could do
+that. Also possible would be to connect to each database and submit
+the queries by hand.</para></listitem> </itemizedlist></para>
+</answer>
+</qandaentry>
<qandaentry>
<question><para>I need to drop a sequence from a replication set</para></question>
-<answer><para></para><para>If you are running 1.0.5 or later, there is a
-<command>SET DROP SEQUENCE</command> command in Slonik to allow you to do this,
-parallelling <command>SET DROP TABLE.</command></para>
+<answer><para></para><para>If you are running 1.0.5 or later, there is
+a <command> <link linkend="stmtsetdropsequence"> SET DROP SEQUENCE
+</link></command> command in Slonik to allow you to do this,
+parallelling <command> <link linkend="stmtsetdroptable"> SET DROP
+TABLE</link></command>.</para>
<para>If you are running 1.0.2 or earlier, the process is a bit more manual.</para>
<para>Supposing I want to get rid of the two sequences listed below,
-<envar>whois_cachemgmt_seq</envar> and <envar>epp_whoi_cach_seq_</envar>, we start
-by needing the <envar>seq_id</envar> values.
+<envar>whois_cachemgmt_seq</envar> and
+<envar>epp_whoi_cach_seq_</envar>, we start by needing the
+<envar>seq_id</envar> values.
<screen>
oxrsorg=# select * from _oxrsorg.sl_sequence where seq_id in (93,59);
@@ -310,12 +334,16 @@
</programlisting></para>
<para>Those two queries could be submitted to all of the nodes via
-<function>ddlscript()</function> / <command>EXECUTE SCRIPT</command>, thus eliminating
-the sequence everywhere <quote>at once.</quote> Or they may be applied by
-hand to each of the nodes.</para>
-
-<para>Similarly to <command>SET DROP TABLE</command>, this should be in place for <productname>Slony-I</productname> version
-1.0.5 as <command>SET DROP SEQUENCE.</command></para>
+<function>ddlscript()</function> / <command> <link
+linkend="stmtddlscript"> EXECUTE SCRIPT </link> </command>, thus
+eliminating the sequence everywhere <quote>at once.</quote> Or they
+may be applied by hand to each of the nodes.</para>
+
+<para>Similarly to <command> <link linkend="stmtsetdroptable"> SET
+DROP TABLE </link> </command>, this is implemented
+<productname>Slony-I</productname> version 1.0.5 as <command> <link
+linkend="stmtsetdropsequence"> SET DROP
+SEQUENCE</link></command>.</para>
<qandaentry>
<question><para><productname>Slony-I</productname>: cannot add table to currently subscribed set 1</para>
@@ -328,9 +356,10 @@
<answer><para> You cannot add tables to sets that already have
subscribers.</para>
-<para>The workaround to this is to create <emphasis>ANOTHER</emphasis> set, add
-the new tables to that new set, subscribe the same nodes subscribing
-to "set 1" to the new set, and then merge the sets together.</para>
+<para>The workaround to this is to create <emphasis>ANOTHER</emphasis>
+set, add the new tables to that new set, subscribe the same nodes
+subscribing to "set 1" to the new set, and then merge the sets
+together.</para>
<qandaentry>
<question><para>Some nodes start consistently falling behind</para>
@@ -343,18 +372,23 @@
fetch 100 from LOG;
</screen></para></question>
-<answer><para> This is characteristic of pg_listener (which is the table containing
-<command>NOTIFY</command> data) having plenty of dead tuples in it. That makes <command>NOTIFY</command>
-events take a long time, and causes the affected node to gradually
-fall further and further behind.</para>
-
-<para>You quite likely need to do a <command>VACUUM FULL</command> on <envar>pg_listener</envar>, to vigorously clean it out, and need to vacuum <envar>pg_listener</envar> really frequently. Once every five minutes would likely be AOK.</para>
+<answer><para> This is characteristic of pg_listener (which is the
+table containing <command>NOTIFY</command> data) having plenty of dead
+tuples in it. That makes <command>NOTIFY</command> events take a long
+time, and causes the affected node to gradually fall further and
+further behind.</para>
+
+<para>You quite likely need to do a <command>VACUUM FULL</command> on
+<envar>pg_listener</envar>, to vigorously clean it out, and need to
+vacuum <envar>pg_listener</envar> really frequently. Once every five
+minutes would likely be AOK.</para>
<para> Slon daemons already vacuum a bunch of tables, and
-<filename>cleanup_thread.c</filename> contains a list of tables that are
-frequently vacuumed automatically. In <productname>Slony-I</productname> 1.0.2,
-<envar>pg_listener</envar> is not included. In 1.0.5 and later, it is
-regularly vacuumed, so this should cease to be a direct issue.</para>
+<filename>cleanup_thread.c</filename> contains a list of tables that
+are frequently vacuumed automatically. In
+<productname>Slony-I</productname> 1.0.2, <envar>pg_listener</envar>
+is not included. In 1.0.5 and later, it is regularly vacuumed, so
+this should cease to be a direct issue.</para>
<para>There is, however, still a scenario where this will still
"bite." Vacuums cannot delete tuples that were made "obsolete" at any
@@ -363,14 +397,20 @@
avoided, even on "slave" nodes.</para>
<qandaentry>
-<question><para>I started doing a backup using pg_dump, and suddenly Slony stops</para></question>
+<question><para>I started doing a backup using <application/pg_dump/,
+and suddenly Slony stops</para></question>
<answer><para>Ouch. What happens here is a conflict between:
<itemizedlist>
-<listitem><para> <application>pg_dump</application>, which has taken out an <command>AccessShareLock</command> on all of the tables in the database, including the <productname>Slony-I</productname> ones, and</para></listitem>
-
-<listitem><para> A <productname>Slony-I</productname> sync event, which wants to grab a <command>AccessExclusiveLock</command> on the table <envar>sl_event</envar>.</para></listitem>
+<listitem><para> <application>pg_dump</application>, which has taken
+out an <command>AccessShareLock</command> on all of the tables in the
+database, including the <productname>Slony-I</productname> ones,
+and</para></listitem>
+
+<listitem><para> A <productname>Slony-I</productname> sync event,
+which wants to grab a <command>AccessExclusiveLock</command> on the
+table <envar>sl_event</envar>.</para></listitem>
</itemizedlist></para>
<para>The initial query that will be blocked is thus:
@@ -379,12 +419,14 @@
select "_slonyschema".createEvent('_slonyschema, 'SYNC', NULL);
</screen></para>
-<para>(You can see this in <envar>pg_stat_activity</envar>, if you have query
-display turned on in <filename>postgresql.conf</filename>)</para>
+<para>(You can see this in <envar>pg_stat_activity</envar>, if you
+have query display turned on in
+<filename>postgresql.conf</filename>)</para>
<para>The actual query combination that is causing the lock is from
the function <function>Slony_I_ClusterStatus()</function>, found in
-<filename>slony1_funcs.c</filename>, and is localized in the code that does:
+<filename>slony1_funcs.c</filename>, and is localized in the code that
+does:
<programlisting>
LOCK TABLE %s.sl_event;
@@ -392,46 +434,54 @@
SELECT currval('%s.sl_event_seq');
</programlisting></para>
-<para>The <command>LOCK</command> statement will sit there and wait until <command>pg_dump</command> (or whatever else has pretty much any kind of access lock on <envar>sl_event</envar>) completes.</para>
-
-<para>Every subsequent query submitted that touches <envar>sl_event</envar> will block behind the <function>createEvent</function> call.</para>
+<para>The <command>LOCK</command> statement will sit there and wait
+until <command>pg_dump</command> (or whatever else has pretty much any
+kind of access lock on <envar>sl_event</envar>) completes.</para>
+
+<para>Every subsequent query submitted that touches
+<envar>sl_event</envar> will block behind the
+<function>createEvent</function> call.</para>
<para>There are a number of possible answers to this:
<itemizedlist>
-<listitem><para> Have pg_dump specify the schema dumped using
---schema=whatever, and don't try dumping the cluster's schema.</para></listitem>
-
-<listitem><para> It would be nice to add an "--exclude-schema" option
-to pg_dump to exclude the Slony cluster schema. Maybe in 8.0 or
-8.1...</para></listitem>
+<listitem><para> Have <application>pg_dump</application> specify the
+schema dumped using <option>--schema=whatever</option>, and don't try
+dumping the cluster's schema.</para></listitem>
+
+<listitem><para> It would be nice to add an <option/--exclude-schema/
+option to pg_dump to exclude the Slony cluster schema. Maybe in 8.0
+or 8.1...</para></listitem>
<listitem><para>Note that 1.0.5 uses a more precise lock that is less
exclusive that alleviates this problem.</para></listitem>
</itemizedlist></para>
<qandaentry>
-<question><para>The slons spent the weekend out of commission [for
-some reason], and it's taking a long time to get a sync through.</para></question>
+<question><para>The <application/slon/s spent the weekend out of
+commission [for some reason], and it's taking a long time to get a
+sync through.</para></question>
<answer><para> You might want to take a look at the sl_log_1/sl_log_2
tables, and do a summary to see if there are any really enormous
-<productname>Slony-I</productname> transactions in there. Up until at least 1.0.2,
-there needs to be a slon connected to the origin in order for
-<command>SYNC</command> events to be generated.</para>
-
-<para>If none are being generated, then all of the updates until the next
-one is generated will collect into one rather enormous <productname>Slony-I</productname>
-transaction.</para>
+<productname>Slony-I</productname> transactions in there. Up until at
+least 1.0.2, there needs to be a slon connected to the origin in order
+for <command>SYNC</command> events to be generated.</para>
+
+<para>If none are being generated, then all of the updates until the
+next one is generated will collect into one rather enormous
+<productname>Slony-I</productname> transaction.</para>
<para>Conclusion: Even if there is not going to be a subscriber
-around, you <emphasis>really</emphasis> want to have a slon running to service
-the origin node.</para>
-
-<para><productname>Slony-I</productname> 1.1 provides a stored procedure that
-allows <command>SYNC</command> counts to be updated on the origin based on a
-<application>cron</application> job even if there is no <link linkend="slon"> slon
-</link> daemon running.</para>
+around, you <emphasis>really</emphasis> want to have a
+<application>slon</application> running to service the origin
+node.</para>
+
+<para><productname>Slony-I</productname> 1.1 provides a stored
+procedure that allows <command>SYNC</command> counts to be updated on
+the origin based on a <application>cron</application> job even if
+there is no <link linkend="slon"> <application/slon/ </link> daemon
+running.</para>
<qandaentry>
<question><para>I pointed a subscribing node to a different provider
@@ -448,19 +498,23 @@
</itemizedlist></para>
<para>The subscription for node 3 was changed to have node 1 as
-provider, and we did <command>DROP SET</command>/<command>SUBSCRIBE SET</command> for
-node 2 to get it repopulating.</para>
+provider, and we did <command> <link linkend="stmtdropset"> DROP
+SET</link></command>/<command> <link linkend="stmtsubscribeset">
+SUBSCRIBE SET</link> </command> for node 2 to get it
+repopulating.</para>
<para>Unfortunately, replication suddenly stopped to node 3.</para>
-<para>The problem was that there was not a suitable set of <quote>listener paths</quote>
-in sl_listen to allow the events from node 1 to propagate to node 3.
-The events were going through node 2, and blocking behind the
-<command>SUBSCRIBE SET</command> event that node 2 was working on.</para>
-
-<para>The following slonik script dropped out the listen paths where node 3
-had to go through node 2, and added in direct listens between nodes 1
-and 3.
+<para>The problem was that there was not a suitable set of
+<quote>listener paths</quote> in sl_listen to allow the events from
+node 1 to propagate to node 3. The events were going through node 2,
+and blocking behind the <command> <link linkend="stmtsubscribeset">
+SUBSCRIBE SET </link> </command> event that node 2 was working
+on.</para>
+
+<para>The following slonik script dropped out the listen paths where
+node 3 had to go through node 2, and added in direct listens between
+nodes 1 and 3.
<programlisting>
cluster name = oxrslive;
@@ -476,15 +530,16 @@
}
</programlisting></para>
-<para>Immediately after this script was run, <command>SYNC</command> events started propagating
-again to node 3.
+<para>Immediately after this script was run, <command>SYNC</command>
+events started propagating again to node 3.
This points out two principles:
<itemizedlist>
<listitem><para> If you have multiple nodes, and cascaded subscribers,
-you need to be quite careful in populating the <command>STORE LISTEN</command>
-entries, and in modifying them if the structure of the replication
+you need to be quite careful in populating the <command> <link
+linkend="stmtstorelisten"> STORE LISTEN </link></command> entries, and
+in modifying them if the structure of the replication
<quote>tree</quote> changes.</para></listitem>
<listitem><para> Version 1.1 should provide better tools to help
@@ -507,12 +562,14 @@
</qandaentry>
<qandaentry id="faq17">
-<question><para>After dropping a node, sl_log_1 isn't getting purged out anymore.</para></question>
+<question><para>After dropping a node, sl_log_1 isn't getting purged
+out anymore.</para></question>
<answer><para> This is a common scenario in versions before 1.0.5, as
-the <quote>clean up</quote> that takes place when purging the node does not
-include purging out old entries from the <productname>Slony-I</productname> table,
-sl_confirm, for the recently departed node.</para>
+the <quote>clean up</quote> that takes place when purging the node
+does not include purging out old entries from the
+<productname>Slony-I</productname> table, sl_confirm, for the recently
+departed node.</para>
<para> The node is no longer around to update confirmations of what
syncs have been applied on it, and therefore the cleanup thread that
@@ -536,10 +593,10 @@
(6 rows)
</screen></para>
-<para>In version 1.0.5, the <command>drop node</command> function purges out
-entries in sl_confirm for the departing node. In earlier versions,
-this needs to be done manually. Supposing the node number is 3, then
-the query would be:
+<para>In version 1.0.5, the <command><link linkend="stmtdropnode">
+drop node </link> </command> function purges out entries in sl_confirm
+for the departing node. In earlier versions, this needs to be done
+manually. Supposing the node number is 3, then the query would be:
<screen>
delete from _namespace.sl_confirm where con_origin = 3 or con_received = 3;
@@ -552,11 +609,11 @@
</screen></para>
<para>General <quote>due diligance</quote> dictates starting with a
-<command>BEGIN</command>, looking at the contents of sl_confirm before,
-ensuring that only the expected records are purged, and then, only
-after that, confirming the change with a <command>COMMIT</command>. If you
-delete confirm entries for the wrong node, that could ruin your whole
-day.</para>
+<command>BEGIN</command>, looking at the contents of sl_confirm
+before, ensuring that only the expected records are purged, and then,
+only after that, confirming the change with a
+<command>COMMIT</command>. If you delete confirm entries for the
+wrong node, that could ruin your whole day.</para>
<para>You'll need to run this on each node that remains...</para>
@@ -565,7 +622,10 @@
<itemizedlist>
<listitem><para> At the time a node is dropped</para></listitem>
-<listitem><para> At the start of each "cleanupEvent" run, which is the event in which old data is purged from sl_log_1 and sl_seqlog</para></listitem>
+
+<listitem><para> At the start of each <function/cleanupEvent/ run,
+which is the event in which old data is purged from sl_log_1 and
+sl_seqlog</para></listitem>
</itemizedlist></para>
</answer>
</qandaentry>
@@ -574,7 +634,7 @@
<question><para>Replication Fails - Unique Constraint Violation</para>
<para>Replication has been running for a while, successfully, when a
-node encounters a "glitch," and replication logs are filled with
+node encounters a <quote/glitch,/ and replication logs are filled with
repetitions of the following:
<screen>
@@ -599,11 +659,13 @@
ERROR remoteWorkerThread_1: SYNC aborted
</screen></para>
-<para>The transaction rolls back, and <productname>Slony-I</productname> tries again, and again,
-and again. The problem is with one of the <emphasis>last</emphasis> SQL statements, the
-one with <command>log_cmdtype = 'I'</command>. That isn't quite obvious; what takes
-place is that <productname>Slony-I</productname> groups 10 update queries together to diminish
-the number of network round trips.</para></question>
+<para>The transaction rolls back, and
+<productname>Slony-I</productname> tries again, and again, and again.
+The problem is with one of the <emphasis>last</emphasis> SQL
+statements, the one with <command>log_cmdtype = 'I'</command>. That
+isn't quite obvious; what takes place is that
+<productname>Slony-I</productname> groups 10 update queries together
+to diminish the number of network round trips.</para></question>
<answer><para> A <emphasis>certain</emphasis> cause for this has not
yet been arrived at. The factors that <emphasis>appear</emphasis> to
@@ -611,10 +673,11 @@
<itemizedlist>
-<listitem><para> The "glitch" seems to coincide with some sort of
-outage; it has been observed both in cases where databases were
+<listitem><para> The <quote/glitch/ seems to coincide with some sort
+of outage; it has been observed both in cases where databases were
suffering from periodic "SIG 11" problems, where backends were falling
-over, as well as when temporary network failure seemed likely.</para></listitem>
+over, as well as when temporary network failure seemed
+likely.</para></listitem>
<listitem><para> The scenario seems to involve a delete transaction
having been missed by <productname>Slony-I</productname>.</para></listitem>
@@ -626,7 +689,8 @@
possible.</para>
<para>What is necessary, at this point, is to drop the replication set
-(or even the node), and restart replication from scratch on that node.</para>
+(or even the node), and restart replication from scratch on that
+node.</para>
<para>In <productname>Slony-I</productname> 1.0.5, the handling of
purges of sl_log_1 are rather more conservative, refusing to purge
@@ -640,12 +704,12 @@
<qandaentry>
-<question><para> If you have a slonik script something like this, it
-will hang on you and never complete, because you can't have
-<command>wait for event</command> inside a <command>try</command>
-block. A <command>try</command> block is executed as one transaction,
-and the event that you are waiting for can never arrive inside the
-scope of the transaction.
+<question><para> If you have a <link linkend="slonik"> slonik </link>
+script something like this, it will hang on you and never complete,
+because you can't have <command>wait for event</command> inside a
+<command>try</command> block. A <command>try</command> block is
+executed as one transaction, and the event that you are waiting for
+can never arrive inside the scope of the transaction.
<programlisting>
try {
@@ -665,7 +729,8 @@
}
</programlisting></para></question>
-<answer><para> You must not invoke <command>wait for event</command> inside a
+<answer><para> You must not invoke <command> <link
+linkend="stmtwaitevent"> wait for event</link> </command> inside a
<quote>try</quote> block.</para></answer>
</qandaentry>
@@ -680,21 +745,24 @@
foreign key constraint triggers are turned off on subscriber nodes.
</para>
</answer>
+
<answer> <para>(Jan Wieck comments:) The order of table ID's is only
-significant during a <command>LOCK SET</command> in preparation of
-switchover. If that order is different from the order in which an
-application is acquiring its locks, it can lead to deadlocks that
-abort either the application or <application>slon</application>.
+significant during a <command> <link linkend="stmtlockset"> LOCK
+SET</link> </command> in preparation of switchover. If that order is
+different from the order in which an application is acquiring its
+locks, it can lead to deadlocks that abort either the application or
+<application>slon</application>.
</para>
</answer>
+
<answer> <para> (David Parker) I ran into one other case where the
ordering of tables in the set was significant: in the presence of
inherited tables. If a child table appears before its parent in a set,
then the initial subscription will end up deleting that child table
after it has possibly already received data, because the
-<command>copy_set</command> logic does a <command>delete</command>, not a
-<command>delete only</command>, so the delete of the parent will delete the new
-rows in the child as well.
+<command>copy_set</command> logic does a <command>delete</command>,
+not a <command>delete only</command>, so the delete of the parent will
+delete the new rows in the child as well.
</para>
</answer></qandaentry>
Index: reshape.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/reshape.sgml,v
retrieving revision 1.4
retrieving revision 1.5
diff -Ldoc/adminguide/reshape.sgml -Ldoc/adminguide/reshape.sgml -u -w -r1.4 -r1.5
--- doc/adminguide/reshape.sgml
+++ doc/adminguide/reshape.sgml
@@ -14,30 +14,35 @@
<listitem><para> You may subsequently, or instead, wish to modify the
subscriptions of other nodes. You might want to modify a node to get
its data from a different provider, or to change it to turn forwarding
-on or off. This can be accomplished by issuing the slonik
-<command/SUBSCRIBE SET/ operation with the new subscription
-information for the node; <productname/Slony-I/ will change the
-configuration.
+on or off. This can be accomplished by issuing the slonik <command>
+<link linkend="stmtsubscribeset"> SUBSCRIBE SET</link> </command>
+operation with the new subscription information for the node;
+<productname>Slony-I</productname> will change the
+configuration.</para></listitem>
<listitem><para> If the directions of data flows have changed, it is
-doubtless appropriate to issue a set of <command/DROP LISTEN/
-operations to drop out obsolete paths between nodes and <command/SET
-LISTEN/ to add the new ones. At present, this is not changed
-automatically; at some point, <command/MOVE SET/ and
-<command/SUBSCRIBE SET/ might change the paths as a side-effect. See
-<link linkend="ListenPaths"> Slony Listen Paths </link> for more
-information about this. In version 1.1 and later, it is likely that
-the generation of sl_listen entries will be entirely automated, where
-they will be regenerated when changes are made to sl_path or
-sl_subscribe, thereby making it unnecessary to even think about
-<command/SET LISTEN/.
+doubtless appropriate to issue a set of <command><link
+linkend="stmtdroplisten"> DROP LISTEN</link></command> operations to
+drop out obsolete paths between nodes and <command><link
+linkend="stmtstorelisten">STORE LISTEN </link></command> to add the
+new ones. At present, this is not changed automatically; at some
+point, <command> <link linkend="stmtmoveset"> MOVE
+SET</link></command> and <command> <link linkend="stmtsubscribeset">
+SUBSCRIBE SET</link> </command> might change the paths as a
+side-effect. See <link linkend="listenpaths"> Slony Listen Paths
+</link> for more information about this. In version 1.1 and later, it
+is likely that the generation of sl_listen entries will be entirely
+automated, where they will be regenerated when changes are made to
+sl_path or sl_subscribe, thereby making it unnecessary to even think
+about <command> <link linkend="stmtstorelisten"> STORE LISTEN
+</link></command>.</para></listitem>
</itemizedlist>
<para> The <filename/altperl/ toolset includes a
<application/init_cluster.pl/ script that is quite up to the task of
-creating the new <command/SET LISTEN/ commands; it isn't, however,
-smart enough to know what listener paths should be dropped.
+creating the new <command>STORE LISTEN</command> commands; it isn't,
+however, smart enough to know what listener paths should be dropped.
</sect1>
<!-- Keep this comment at the end of the file
Index: addthings.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/addthings.sgml,v
retrieving revision 1.3
retrieving revision 1.4
diff -Ldoc/adminguide/addthings.sgml -Ldoc/adminguide/addthings.sgml -u -w -r1.3 -r1.4
--- doc/adminguide/addthings.sgml
+++ doc/adminguide/addthings.sgml
@@ -6,28 +6,31 @@
<para>This can be fairly easily remedied.
<para>You cannot directly use <link linkend="slonik"> slonik </link>
-commands <command/SET ADD TABLE/ or <command/SET ADD SEQUENCE/ in
-order to add tables and sequences to a replication set that is
-presently replicating; you must instead create a new replication set.
-Once it is identically subscribed (e.g. - the set of providers and
-subscribers is <emphasis/entirely identical/ to that for the set it is
-to merge with), the sets may be merged together using <command/MERGE
-SET/.
+commands <command><link linkend="stmtsetaddtable"> SET ADD
+TABLE</link></command> or <command><link linkend="stmtsetaddsequence">
+SET ADD SEQUENCE</link></command> in order to add tables and sequences
+to a replication set that is presently replicating; you must instead
+create a new replication set. Once it is identically subscribed
+(e.g. - the set of providers and subscribers is <emphasis>entirely
+identical</emphasis> to that for the set it is to merge with), the
+sets may be merged together using <command><link
+linkend="stmtmergeset"> MERGE SET</link></command>.</para>
<para>Up to and including 1.0.2, there was a potential problem where
-if <command/MERGE_SET/ is issued while other subscription-related
-events are pending, it is possible for things to get pretty confused
-on the nodes where other things were pending. This problem was
-resolved in 1.0.5.
+if <command><link linkend="stmtmergeset"> MERGE SET</linK></command>
+is issued while other subscription-related events are pending, it is
+possible for things to get pretty confused on the nodes where other
+things were pending. This problem was resolved in 1.0.5.</para>
<para>It is suggested that you be very deliberate when adding such
things. For instance, submitting multiple subscription requests for a
-particular set in one <link linkend="Slonik"> slonik </link> script
-often turns out quite badly. If it is <emphasis/truly/ necessary to
-automate this, you'll probably want to submit <command/WAIT FOR EVENT/
+particular set in one <link linkend="slonik"> slonik </link> script
+often turns out quite badly. If it is <emphasis>truly</emphasis>
+necessary to automate this, you'll probably want to submit <command>
+<link linkend="stmtwaitevent"> WAIT FOR EVENT</link></command>
requests in between subscription requests in order that the <link
linkend="slonik"> slonik </link> script wait for one subscription to
-complete processing before requesting the next one.
+complete processing before requesting the next one.</para>
<para>But in general, it is likely to be easier to cope with complex
node reconfigurations by making sure that one change has been
Index: startslons.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/startslons.sgml,v
retrieving revision 1.3
retrieving revision 1.4
diff -Ldoc/adminguide/startslons.sgml -Ldoc/adminguide/startslons.sgml -u -w -r1.3 -r1.4
--- doc/adminguide/startslons.sgml
+++ doc/adminguide/startslons.sgml
@@ -14,30 +14,32 @@
<itemizedlist>
-<listitem><Para> Each <application/slon/ needs to be able to
-communicate quickly with the database whose <quote/node controller/ it
-is. Therefore, if a <productname/Slony-I/ cluster runs across some
-form of Wide Area Network, each slon process should run on or nearby
-the databases each is controlling. If you break this rule, no
-particular disaster should ensue, but the added latency introduced to
-monitoring events on the slon's <quote/own node/ will cause it to
-replicate in a <emphasis/somewhat/ less timely manner.
-
-<listitem><Para> The very fastest results would be achieved by having
-each <application/slon/ run on the database server that it is
-servicing. If it runs somewhere within a fast local network,
-performance will not be noticeably degraded.
-
-<listitem><Para> It is an attractive idea to run many of the
-<application/slon/ processes for a cluster on one machine, as this
-makes it easy to monitor them both in terms of log files and process
-tables from one location. This also eliminates the need to login to
-several hosts in order to look at log files or to restart
-<application/slon/ instances.
+<listitem><para> Each <application>slon</application> needs to be able
+to communicate quickly with the database whose <quote>node
+controller</quote> it is. Therefore, if a
+<productname>Slony-I</productname> cluster runs across some form of
+Wide Area Network, each slon process should run on or nearby the
+databases each is controlling. If you break this rule, no particular
+disaster should ensue, but the added latency introduced to monitoring
+events on the slon's <quote>own node</quote> will cause it to
+replicate in a <emphasis>somewhat</emphasis> less timely
+manner.</para></listitem>
+
+<listitem><para> The very fastest results would be achieved by having
+each <application>slon</application> run on the database server that
+it is servicing. If it runs somewhere within a fast local network,
+performance will not be noticeably degraded.</para></listitem>
+
+<listitem><para> It is an attractive idea to run many of the
+<application>slon</application> processes for a cluster on one
+machine, as this makes it easy to monitor them both in terms of log
+files and process tables from one location. This also eliminates the
+need to login to several hosts in order to look at log files or to
+restart <application>slon</application> instances.</para></listitem>
</itemizedlist>
-<para>There are two <quote/watchdog/ scripts currently available:
+<para>There are two <quote>watchdog</quote> scripts currently available:
<itemizedlist>
@@ -47,15 +49,15 @@
</link></application>, restarting any time it falls over</para>
</listitem>
-<listitem><Para> <filename>tools/altperl/slon_watchdog2.pl</filename>
+<listitem><para> <filename>tools/altperl/slon_watchdog2.pl</filename>
- a somewhat more intelligent version that periodically polls the
-database, checking to see if a <command/SYNC/ has taken place
+database, checking to see if a <command>SYNC</command> has taken place
recently. We have had VPN connections that occasionally fall over
without signalling the application, so that the <application><link
linkend="slon"> slon </link></application> stops working, but doesn't
-actually die; this polling addresses that issue.
+actually die; this polling addresses that issue.</para></listitem>
-</itemizedlist>
+</itemizedlist></para>
<para>The <filename>slon_watchdog2.pl</filename> script is probably
<emphasis>usually</emphasis> the preferable thing to run. It was at
Index: ddlchanges.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/ddlchanges.sgml,v
retrieving revision 1.3
retrieving revision 1.4
diff -Ldoc/adminguide/ddlchanges.sgml -Ldoc/adminguide/ddlchanges.sgml -u -w -r1.3 -r1.4
--- doc/adminguide/ddlchanges.sgml
+++ doc/adminguide/ddlchanges.sgml
@@ -1,21 +1,25 @@
<sect1 id="ddlchanges"> <title/Database Schema Changes (DDL)/
-<para>When changes are made to the database schema, <emphasis/e.g./ -
-adding fields to a table, it is necessary for this to be handled
-rather carefully, otherwise different nodes may get rather deranged
-because they disagree on how particular tables are built.
-
-<para>If you pass the changes through <productname/Slony-I/ via the
-<command/EXECUTE SCRIPT/ (slonik) /
-<function/ddlscript(set,script,node)/ (stored function), this allows
-you to be certain that the changes take effect at the same point in
-the transaction streams on all of the nodes. That may not be too
-important if you can take something of an outage to do schema changes,
-but if you want to do upgrades that take place while transactions are
-still winding their way through your systems, this is necessary.
+<para>When changes are made to the database schema,
+<emphasis>e.g.</emphasis> - adding fields to a table, it is necessary
+for this to be handled rather carefully, otherwise different nodes may
+get rather deranged because they disagree on how particular tables are
+built.</para>
+
+<para>If you pass the changes through
+<productname>Slony-I</productname> via the <command><link
+linkend="stmtddlscript"> EXECUTE SCRIPT</link> </command> (slonik) /
+<function>ddlscript(set,script,node)</function> (stored function),
+this allows you to be certain that the changes take effect at the same
+point in the transaction streams on all of the nodes. That may not be
+too important if you can take something of an outage to do schema
+changes, but if you want to do upgrades that take place while
+transactions are still winding their way through your systems, this is
+necessary.</para>
<para>It's worth making a couple of comments on <quote/special things/
-about <command/EXECUTE SCRIPT/:
+about <command><link linkend="stmtddlscript"> EXECUTE SCRIPT</link>
+</command>:
<itemizedlist>
Index: reference.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/reference.sgml,v
retrieving revision 1.1
retrieving revision 1.2
diff -Ldoc/adminguide/reference.sgml -Ldoc/adminguide/reference.sgml -u -w -r1.1 -r1.2
--- doc/adminguide/reference.sgml
+++ doc/adminguide/reference.sgml
@@ -2,5 +2,5 @@
&slon;
&slonik;
+&slonikref;
-</reference>
\ No newline at end of file
Index: failover.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/failover.sgml,v
retrieving revision 1.4
retrieving revision 1.5
diff -Ldoc/adminguide/failover.sgml -Ldoc/adminguide/failover.sgml -u -w -r1.4 -r1.5
--- doc/adminguide/failover.sgml
+++ doc/adminguide/failover.sgml
@@ -31,7 +31,8 @@
<quote>subscriber</quote> as node2 (<emphasis>e.g.</emphasis> -
slave). A web application on a third server is accessing the database
on node1. Both databases are up and running and replication is more
-or less in sync.
+or less in sync. We do controlled switchover using <command> <link
+linkend="stmtmoveset"> MOVE SET </link> </command>.
<itemizedlist>
@@ -41,7 +42,8 @@
Users who use <application>pg_pool</application> for the applications database
connections merely have to shut down the pool.</para></listitem>
-<listitem><para> A small slonik script executes the following commands:
+<listitem><para> A small <link linkend="slonik"> Slonik </link> script
+executes the following commands:
<programlisting>
lock set (id = 1, origin = 1);
@@ -61,13 +63,15 @@
server is restarted and resumes normal operation.</para>
<para> Done in one shell script, that does the application shutdown,
-<application>slonik</application>, move config files and startup all together, this
-entire procedure is likely to take less than 10 seconds.</para></listitem>
+<application>slonik</application>, move config files and startup all
+together, this entire procedure is likely to take less than 10
+seconds.</para></listitem>
</itemizedlist></para>
<para> You may now simply shutdown the server hosting node1 and do
-whatever is required to maintain the server. When <application><link linkend="slon"> slon </link></application> node1 is restarted later,
+whatever is required to maintain the server. When <application><link
+linkend="slon"> slon </link></application> node1 is restarted later,
it will start replicating again, and soon catch up. At this point the
procedure to switch origins is executed again to restore the original
configuration.</para>
@@ -78,25 +82,29 @@
<sect2><title> Failover</title>
-<para> If some more serious problem occurs on the <quote>origin</quote>
-server, it may be necessary to failover to a backup server. This is a
-highly undesirable circumstance, as transactions <quote>committed</quote> on
-the origin, but not applied to the subscribers, will be lost. You may
-have reported these transactions as <quote>successful</quote> to outside
-users. As a result, failover should be considered a <emphasis>last
-resort</emphasis>. If the <quote>injured</quote> origin server can be brought up to
-the point where it can limp along long enough to do a controlled
-switchover, that is <emphasis>greatly</emphasis> preferable.</para>
+<para> If some more serious problem occurs on the
+<quote>origin</quote> server, it may be necessary to <command> <link
+linkend="stmtfailover"> FAILOVER </link> </command> to a backup
+server. This is a highly undesirable circumstance, as transactions
+<quote>committed</quote> on the origin, but not applied to the
+subscribers, will be lost. You may have reported these transactions
+as <quote>successful</quote> to outside users. As a result, failover
+should be considered a <emphasis>last resort</emphasis>. If the
+<quote>injured</quote> origin server can be brought up to the point
+where it can limp along long enough to do a controlled switchover,
+that is <emphasis>greatly</emphasis> preferable.</para>
<para> Slony does not provide any automatic detection for failed
systems. Abandoning committed transactions is a business decision
that cannot be made by a database. If someone wants to put the
commands below into a script executed automatically from the network
-monitoring system, well ... it's <emphasis>your</emphasis> data, and it's <emphasis>your</emphasis> failover policy.
+monitoring system, well ... it's <emphasis>your</emphasis> data, and
+it's <emphasis>your</emphasis> failover policy.
<itemizedlist>
-<listitem><para> The <link linkend="slonik"> <application>slonik</application> </link> command
+<listitem><para> The <link linkend="slonik">
+<application>slonik</application> </link> command
<programlisting>
failover (id = 1, backup node = 2);
@@ -104,25 +112,29 @@
<para> causes node2 to assume the ownership (origin) of all sets that
have node1 as their current origin. If there should happen to be
-additional nodes in the <productname>Slony-I</productname> cluster, all direct
-subscribers of node1 are instructed that this is happening.
-<application>Slonik</application> will also query all direct subscribers in order
-to determine out which node has the highest replication status
-(<emphasis>e.g.</emphasis> - the latest committed transaction) for each set, and
-the configuration will be changed in a way that node2 first applies
-those final before actually allowing write access to the tables.</para>
+additional nodes in the <productname>Slony-I</productname> cluster,
+all direct subscribers of node1 are instructed that this is happening.
+<application>Slonik</application> will also query all direct
+subscribers in order to determine out which node has the highest
+replication status (<emphasis>e.g.</emphasis> - the latest committed
+transaction) for each set, and the configuration will be changed in a
+way that node2 first applies those final before actually allowing
+write access to the tables.</para>
<para> In addition, all nodes that subscribed directly to node1 will
now use node2 as data provider for the set. This means that after the
failover command succeeded, no node in the entire replication setup
will receive anything from node1 any more.</para></listitem>
-<listitem><para> Reconfigure and restart the application (or <application>pgpool</application>)
-to cause it to reconnect to node2.</para></listitem>
+<listitem><para> Reconfigure and restart the application (or
+<application>pgpool</application>) to cause it to reconnect to
+node2.</para></listitem>
<listitem><para> After the failover is complete and node2 accepts
write operations against the tables, remove all remnants of node1's
-configuration information with the <link linkend="slonik"> <application>slonik</application> </link> command
+configuration information with the <link linkend="slonik">
+<application>slonik</application> </link> <command> <link
+linkend="stmtdropnode"> DROP NODE </link> </command> command:
<programlisting>
drop node (id = 1, event node = 2);
Index: dropthings.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/dropthings.sgml,v
retrieving revision 1.4
retrieving revision 1.5
diff -Ldoc/adminguide/dropthings.sgml -Ldoc/adminguide/dropthings.sgml -u -w -r1.4 -r1.5
--- doc/adminguide/dropthings.sgml
+++ doc/adminguide/dropthings.sgml
@@ -6,13 +6,15 @@
<sect2><title/ Dropping A Whole Node/
<para>If you wish to drop an entire node from replication, the <link
-linkend="slonik"> slonik </link> command <command/DROP NODE/ should do
-the trick.
+linkend="slonik"> slonik </link> command <command><link
+linkend="stmtdropnode"> DROP NODE</link></command> should do the
+trick.</para>
<para>This will lead to <productname/Slony-I/ dropping the triggers
(generally that deny the ability to update data), restoring the
-"native" triggers, dropping the schema used by <productname/Slony-I/,
-and the slon process for that node terminating itself.
+<quote/native/ triggers, dropping the schema used by
+<productname/Slony-I/, and the slon process for that node terminating
+itself.
<para>As a result, the database should be available for whatever use
your application makes of the database.
@@ -31,50 +33,58 @@
<sect2><title/ Dropping An Entire Set/
<para>If you wish to stop replicating a particular replication set,
-the <link linkend="slonik"> slonik </link> command <command/DROP SET/
-is what you need to use.
-
-<para>Much as with <command/DROP NODE/, this leads to
-<productname/Slony-I/ dropping the <productname/Slony-I/ triggers on
-the tables and restoring <quote/native/ triggers. One difference is
-that this takes place on <emphasis/all/ nodes in the cluster, rather
-than on just one node. Another difference is that this does not clear
-out the <productname/Slony-I/ cluster's namespace, as there might be
-other sets being serviced.
-
-<para>This operation is quite a bit more dangerous than <command/DROP
-NODE/, as there <emphasis/isn't/ the same sort of <quote/failsafe./ If
-you tell <command/DROP SET/ to drop the <emphasis/wrong/ set, there
+the <link linkend="slonik"> slonik </link> command <command> <link
+linkend="stmtdropset"> DROP SET</link> </command> is what you need to
+use.</para>
+
+<para>Much as with <command><link linkend="stmtdropnode"> DROP NODE
+</link></command>, this leads to <productname>Slony-I</productname>
+dropping the <productname>Slony-I</productname> triggers on the tables
+and restoring <quote>native</quote> triggers. One difference is that
+this takes place on <emphasis>all</emphasis> nodes in the cluster,
+rather than on just one node. Another difference is that this does
+not clear out the <productname>Slony-I</productname> cluster's
+namespace, as there might be other sets being serviced.</para>
+
+<para>This operation is quite a bit more dangerous than <command>
+<link linkend="stmtdropnode"> DROP NODE </link></command>, as there
+<emphasis>isn't</emphasis> the same sort of <quote>failsafe.</quote>
+If you tell <command> <link linkend="stmtdropset"> DROP
+SET</link></command> to drop the <emphasis>wrong</emphasis> set, there
isn't anything to prevent potentially career-limiting
-<quote/unfortunate results./ Handle with care...
+<quote>unfortunate results.</quote> Handle with care...</para>
<sect2><title/ Unsubscribing One Node From One Set/
-<para>The <command/UNSUBSCRIBE SET/ operation is a little less
-invasive than either <command/DROP SET/ or <command/DROP NODE/; it
-involves dropping <productname/Slony-I/ triggers and restoring
-"native" triggers on one node, for one replication set.
-
-<para>Much like with <command/DROP NODE/, this operation will fail if
-there is a node subscribing to the set on this node.
+<para>The <command> <link linkend="stmtunsubscribeset"> UNSUBSCRIBE
+SET </link> </command> operation is a little less invasive than either
+<command> <link linkend="stmtdropset"> DROP SET </link> </command> or
+<command> <link linkend="stmtdropnode"> DROP NODE </link></command>; it involves dropping
+<productname>Slony-I</productname> triggers and restoring
+<quote/native/ triggers on one node, for one replication set.</para>
+
+<para>Much like with <command> <link linkend="stmtdropnode"> DROP NODE
+</link></command>, this operation will fail if there is a node
+subscribing to the set on this node.
<warning>
-<para>For all of the above operations, <quote/turning replication back
-on/ will require that the node copy in a <emphasis/full/ fresh set of
-the data on a provider. The fact that the data was recently being
-replicated isn't good enough; <productname/Slony-I/ will expect to
-refresh the data from scratch.
-</warning>
-
-<sect2><title/ Dropping A Table From A Set/
-
-<para>In <productname/Slony-I/ 1.0.5 and above, there is a Slonik
-command <command/SET DROP TABLE/ that allows dropping a single table
-from replication without forcing the user to drop the entire
-replication set.
+<para>For all of the above operations, <quote>turning replication back
+on</quote> will require that the node copy in a
+<emphasis>full</emphasis> fresh set of the data on a provider. The
+fact that the data was recently being replicated isn't good enough;
+<productname>Slony-I</productname> will expect to refresh the data
+from scratch.</para> </warning></para>
+
+<sect2><title> Dropping A Table From A Set</title>
+
+<para>In <productname>Slony-I</productname> 1.0.5 and above, there is
+a Slonik command <command> <link linkend="stmtsetdroptable"> SET DROP
+TABLE </link> </command> that allows dropping a single table from
+replication without forcing the user to drop the entire replication
+set.</para>
-<para>If you are running an earlier version, there is a <quote/hack/
-to do this:
+<para>If you are running an earlier version, there is a <quote>hack</quote>
+to do this:</para>
<para>You can fiddle this by hand by finding the table ID for the
table you want to get rid of, which you can find in sl_table, and then
@@ -84,25 +94,30 @@
select _slonyschema.alterTableRestore(40);
select _slonyschema.tableDropKey(40);
delete from _slonyschema.sl_table where tab_id = 40;
-</programlisting>
+</programlisting></para>
<para>The schema will obviously depend on how you defined the
-<productname/Slony-I/ cluster. The table ID, in this case, 40, will
-need to change to the ID of the table you want to have go away.
+<productname>Slony-I</productname> cluster. The table ID, in this
+case, 40, will need to change to the ID of the table you want to have
+go away.</para>
<para>You'll have to run these three queries on all of the nodes,
preferably firstly on the origin node, so that the dropping of this
propagates properly. Implementing this via a <link linkend="slonik">
-slonik </link> statement with a new <productname/Slony-I/ event would
-do that. Submitting the three queries using <command/EXECUTE SCRIPT/
-could do that; see <link linkend="ddlchanges"> Database Schema Changes
-</link> for more details. Also possible would be to connect to each
-database and submit the queries by hand.
+slonik </link> statement with a new <productname>Slony-I</productname>
+event would do that. Submitting the three queries using
+<command><link linkend="stmtddlscript"> EXECUTE SCRIPT </link>
+</command> could do that; see <link linkend="ddlchanges"> Database
+Schema Changes </link> for more details. Also possible would be to
+connect to each database and submit the queries by
+hand.</para></sect2>
<sect2><title/ Dropping A Sequence From A Set/
-<para>Just as with <command/SET DROP TABLE/, version 1.0.5 introduces
-the operation <command/SET DROP SEQUENCE/.
+<para>Just as with <command> <link linkend="stmtsetdroptable"> SET
+DROP TABLE </link> </command>, version 1.0.5 introduces the operation
+<command> <link linkend="stmtsetdropsequence"> SET DROP
+SEQUENCE</link> </command>.</para>
<para>If you are running an earlier version, here are instructions as
to how to drop sequences:
@@ -117,9 +132,10 @@
</programlisting>
<para> Those two queries could be submitted to all of the nodes via
-<function>ddlscript()</function> / <command>EXECUTE SCRIPT</command>,
-thus eliminating the sequence everywhere <quote>at once.</quote> Or
-they may be applied by hand to each of the nodes.</para>
+<function>ddlscript()</function> / <command> <link
+linkend="stmtddlscript"> EXECUTE SCRIPT</link> </command>, thus
+eliminating the sequence everywhere <quote>at once.</quote> Or they
+may be applied by hand to each of the nodes.</para>
</sect1>
<!-- Keep this comment at the end of the file
Index: listenpaths.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/listenpaths.sgml,v
retrieving revision 1.5
retrieving revision 1.6
diff -Ldoc/adminguide/listenpaths.sgml -Ldoc/adminguide/listenpaths.sgml -u -w -r1.5 -r1.6
--- doc/adminguide/listenpaths.sgml
+++ doc/adminguide/listenpaths.sgml
@@ -1,4 +1,4 @@
-<sect1 id="listenpaths"> <title/ Slony Listen Paths/
+<sect1 id="listenpaths"> <title/ Slony-I Listen Paths/
<note> <para> If you are running version
<productname>Slony-I</productname> 1.1, it should be
@@ -11,9 +11,10 @@
usage of cascaded subscribers (<emphasis>e.g.</emphasis> - subscribers
that are subscribing through a subscriber node), you will have to be
fairly careful about the configuration of <quote>listen paths</quote>
-via the Slonik <command>STORE LISTEN</command> and <command>DROP
-LISTEN</command> statements that control the contents of the table
-sl_listen.</para>
+via the Slonik <command> <link
+linkend="stmtstorelisten"> STORE LISTEN </link> </command> and
+<link linkend="stmtdroplisten"> <command>DROP LISTEN</command> </link>
+statements that control the contents of the table sl_listen.</para>
<para>The <quote>listener</quote> entries in this table control where
each node expects to listen in order to get events propagated from
@@ -21,9 +22,9 @@
<quote>parent</quote> from whom they are getting updates, but in
reality, they need to be able to receive messages from
<emphasis>all</emphasis> nodes in order to be able to conclude that
-SYNCs have been received everywhere, and that, therefore, entries in
-sl_log_1 and sl_log_2 have been applied everywhere, and can therefore
-be purged. This extra communication is needful so
+<command/SYNC/s have been received everywhere, and that, therefore,
+entries in sl_log_1 and sl_log_2 have been applied everywhere, and can
+therefore be purged. This extra communication is needful so
<productname>Slony-I</productname> is able to shift origins to other
locations.</para>
- Previous message: [Slony1-commit] By cbbrowne: Added in docs on new Perl script to generate SET LISTEN
- Next message: [Slony1-commit] By darcyb: More build environment changes to better support cbrowne's
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Slony1-commit mailing list