Log Message:
-----------
Whole bunch of Slony-I sections ought to be treated as a single
<ARTICLE> so that the table of contents is generated for the whole
lot of them rather than one for each section

Modified Files:
--------------
    slony1-engine/doc/adminguide:
        addthings.sgml (r1.7 -> r1.8)
        adminscripts.sgml (r1.12 -> r1.13)
        ddlchanges.sgml (r1.7 -> r1.8)
        dropthings.sgml (r1.7 -> r1.8)
        failover.sgml (r1.8 -> r1.9)
        firstdb.sgml (r1.7 -> r1.8)
        help.sgml (r1.8 -> r1.9)
        listenpaths.sgml (r1.9 -> r1.10)
        maintenance.sgml (r1.8 -> r1.9)
        monitoring.sgml (r1.9 -> r1.10)
        reshape.sgml (r1.8 -> r1.9)
        slon.sgml (r1.6 -> r1.7)
        slonik.sgml (r1.7 -> r1.8)
        slony.sgml (r1.9 -> r1.10)
        startslons.sgml (r1.6 -> r1.7)
        subscribenodes.sgml (r1.7 -> r1.8)

-------------- next part --------------
Index: slon.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/slon.sgml,v
retrieving revision 1.6
retrieving revision 1.7
diff -Ldoc/adminguide/slon.sgml -Ldoc/adminguide/slon.sgml -u -w -r1.6 -r1.7
--- doc/adminguide/slon.sgml
+++ doc/adminguide/slon.sgml
@@ -66,10 +66,12 @@
    <varlistentry>
     <term><option>-s</option><replaceable class="parameter">SYNC check interval</replaceable></term>
     <listitem>
+
      <para>
       Specifies the interval, in milliseconds, in which
-      <application>slon</application> should add a SYNC even if none has been
-      mandated by data creation.  Default is 10000 ms.
+      <application>slon</application> should check to see if a SYNC
+      should be introduced even if none has been mandated by data
+      creation.  Default is 10000 ms.
      </para>
      
      <para>
@@ -83,23 +85,37 @@
      </para>
 
      <para>
-      Note that SYNC events are also generated on subscriber nodes.
-      Since they are not actually generating any replicable data to
-      pass on, these events are of little value.  You might want to
-      increase this parameter (along with the SYNC interval timeout)
-      to something rather higher on a subscriber node.  There is no
-      need to generate a SYNC more than once in 10 minutes on such a
-      node.
+      If the node is not an origin, so no updates are coming in, it
+      will continue on to the <option>-t</option> timeout and generate
+      a SYNC anyways.
      </para>
+
     </listitem>
    </varlistentry>
    
    <varlistentry>
-    <term><option>-t</option><replaceable class="parameter">SYNC interval timeout</replaceable></term>
+    <term><option>-t</option><replaceable class="parameter">SYNC
+    interval timeout</replaceable></term>
     <listitem>
+
+     <para>
+      At the end of each such timeout period, a SYNC will be generated
+      on the <quote>local</quote> node even if there has been no
+      replicatable data updated that would have pushed out a SYNC.
+     </para>
      <para>
       Default is 60000 ms.
      </para>
+     <para>
+      Note that SYNC events are also generated on subscriber nodes.
+      Since they are not actually generating any data to replicate to
+      other nodes, such SYNC events are of little value.  You might
+      want to increase this parameter to something quite a bit higher
+      than the <option>-s</option SYNC check interval, so that
+      subscriber nodes won't generate and propagate as many SYNC
+      events.  The once per minute that is the default seems amply
+      often.
+     </para>
     </listitem>
    </varlistentry>
    
@@ -129,9 +145,13 @@
       The big advantage in increasing this parameter comes from
       cutting down on the number of transaction
       <command>COMMIT</command>s; moving from 1 to 2 should provide
-      substantial benefit, but the benefits will steadily fall off
-      once the transactions being processed get to be reasonably
-      large.
+      substantial benefit, but the benefits will progressively fall
+      off once the transactions being processed get to be reasonably
+      large.  There isn't likely to be a material difference in
+      performance between 80 and 90; at that point, whether
+      <quote>bigger is better</quote> will depend on whether the
+      bigger set of SYNCs makes the LOG cursor behave badly due to
+      consuming more memory and requiring more time to sortt.
      </para>
     </listitem>
    </varlistentry>
@@ -164,8 +184,8 @@
      moving to more, even if there turn out to be variations large
      enough to cause <productname>PostgreSQL</productname> backends to
      crash, <productname>Slony-I</productname> will back off down to
-     doing one sync at a time, if need be, so that if it is at all
-     possible for replication to progress, progress it will.</para>
+      start with one sync at a time, if need be, so that if it is at
+      all possible for replication to progress, it will.</para>
     </listitem>
    </varlistentry>      
 
@@ -176,11 +196,14 @@
       How often to <command>VACUUM</command> in cleanup cycles.
      </para>
      <para>
-      Set this to zero to disable slon-initiated vacuuming. If
-      you are using something like <application>pg_autovacuum</application>
-      to initiate vacuums, you may not need for slon to initiate vacuums itself.
-      If you are not, there are some tables Slony-I uses that collect a
-      <emphasis>lot</emphasis> of dead tuples that should be vacuumed frequently.
+      Set this to zero to disable
+      <application>slon</application>-initiated vacuuming. If you are
+      using something like <application>pg_autovacuum</application> to
+      initiate vacuums, you may not need for slon to initiate vacuums
+      itself.  If you are not, there are some tables
+      <productname>Slony-I</productname> uses that collect a
+      <emphasis>lot</emphasis> of dead tuples that should be vacuumed
+      frequently.
      </para>
     </listitem>
    </varlistentry>
@@ -190,7 +213,7 @@
     <term><option>-p</option><replaceable class="parameter">PID filename</replaceable></term>
     <listitem>
      <para>
-      PID filename.
+      Filename in which the PID (process ID) of the <application>slon</application> is stored.
      </para>
     </listitem>
    </varlistentry>
@@ -199,7 +222,7 @@
     <term><option>-f</option><replaceable class="parameter">config file</replaceable></term>
     <listitem>
      <para>
-      File containing <application>slon</application> configuration.
+      File from which to read <application>slon</application> configuration.
      </para>
     </listitem>
    </varlistentry>
Index: adminscripts.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/adminscripts.sgml,v
retrieving revision 1.12
retrieving revision 1.13
diff -Ldoc/adminguide/adminscripts.sgml -Ldoc/adminguide/adminscripts.sgml -u -w -r1.12 -r1.13
--- doc/adminguide/adminscripts.sgml
+++ doc/adminguide/adminscripts.sgml
@@ -1,5 +1,4 @@
 <!-- $Id$ -->
-<article>
 <sect1 id="altperl">
 <title>Slony-I Administration Scripts</title>
 
@@ -230,7 +229,6 @@
 </sect2>
 
 </sect1>
-</article>
 <!-- Keep this comment at the end of the file
 Local variables:
 mode:sgml
Index: help.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/help.sgml,v
retrieving revision 1.8
retrieving revision 1.9
diff -Ldoc/adminguide/help.sgml -Ldoc/adminguide/help.sgml -u -w -r1.8 -r1.9
--- doc/adminguide/help.sgml
+++ doc/adminguide/help.sgml
@@ -1,5 +1,4 @@
 <!-- $Id$ -->
-<article>
 <sect1 id="help">
 <title>More Slony-I Help</title>
 
@@ -48,7 +47,6 @@
 </itemizedlist>
 </sect2>
 </sect1>
-</article>
 <!-- Keep this comment at the end of the file
 Local variables:
 mode:sgml
Index: maintenance.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/maintenance.sgml,v
retrieving revision 1.8
retrieving revision 1.9
diff -Ldoc/adminguide/maintenance.sgml -Ldoc/adminguide/maintenance.sgml -u -w -r1.8 -r1.9
--- doc/adminguide/maintenance.sgml
+++ doc/adminguide/maintenance.sgml
@@ -1,5 +1,4 @@
 <!-- $Id$ -->
-<article>
 <sect1 id="maintenance"> <title>Slony-I Maintenance</title>
 
 <para><productname>Slony-I</productname> actually does most of its necessary
@@ -157,7 +156,6 @@
 </para>
 </sect2>
 </sect1>
-</article>
 <!-- Keep this comment at the end of the file
 Local variables:
 mode:sgml
Index: firstdb.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/firstdb.sgml,v
retrieving revision 1.7
retrieving revision 1.8
diff -Ldoc/adminguide/firstdb.sgml -Ldoc/adminguide/firstdb.sgml -u -w -r1.7 -r1.8
--- doc/adminguide/firstdb.sgml
+++ doc/adminguide/firstdb.sgml
@@ -1,5 +1,4 @@
 <!-- $Id$ -->
-<article>
 <sect1 id="firstdb"><title>Replicating Your First Database</title>
 
 <para>In this example, we will be replicating a brand new pgbench
@@ -312,7 +311,6 @@
 http://slony.info/</ulink></para>
 
 </sect1>
-</article>
 
 <!-- Keep this comment at the end of the file
 Local variables:
Index: subscribenodes.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/subscribenodes.sgml,v
retrieving revision 1.7
retrieving revision 1.8
diff -Ldoc/adminguide/subscribenodes.sgml -Ldoc/adminguide/subscribenodes.sgml -u -w -r1.7 -r1.8
--- doc/adminguide/subscribenodes.sgml
+++ doc/adminguide/subscribenodes.sgml
@@ -1,5 +1,4 @@
 <!-- $Id$ -->
-<article>
 <sect1 id="subscribenodes"> <title>Subscribing Nodes</title>
 
 <para>Before you subscribe a node to a set, be sure that you have
@@ -81,7 +80,6 @@
 new subscriber.
 </para>
 </sect1>
-</article>
 <!-- Keep this comment at the end of the file
 Local variables:
 mode:sgml
Index: reshape.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/reshape.sgml,v
retrieving revision 1.8
retrieving revision 1.9
diff -Ldoc/adminguide/reshape.sgml -Ldoc/adminguide/reshape.sgml -u -w -r1.8 -r1.9
--- doc/adminguide/reshape.sgml
+++ doc/adminguide/reshape.sgml
@@ -1,5 +1,4 @@
 <!-- $Id$ -->
-<article>
 <sect1 id="reshape"> <title>Reshaping a Cluster</title>
 
 <para>If you rearrange the nodes so that they serve different
@@ -48,7 +47,6 @@
 </para>
 
 </sect1>
-</article>
 <!-- Keep this comment at the end of the file
 Local variables:
 mode:sgml
Index: addthings.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/addthings.sgml,v
retrieving revision 1.7
retrieving revision 1.8
diff -Ldoc/adminguide/addthings.sgml -Ldoc/adminguide/addthings.sgml -u -w -r1.7 -r1.8
--- doc/adminguide/addthings.sgml
+++ doc/adminguide/addthings.sgml
@@ -1,5 +1,4 @@
 <!-- $Id$ -->
-<article>
 <sect1 id="addthings">
 <title>Adding Things to Replication</title>
 
@@ -49,7 +48,6 @@
 to fix one thing that has broken than to piece things together after
 the interaction of five things that have all broken.</para>
 </sect1>
-</article>
 <!-- Keep this comment at the end of the file
 Local variables:
 mode:sgml
Index: startslons.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/startslons.sgml,v
retrieving revision 1.6
retrieving revision 1.7
diff -Ldoc/adminguide/startslons.sgml -Ldoc/adminguide/startslons.sgml -u -w -r1.6 -r1.7
--- doc/adminguide/startslons.sgml
+++ doc/adminguide/startslons.sgml
@@ -1,5 +1,4 @@
 <!-- $Id$ -->
-<article>
 <sect1 id="slonstart"> <title>Slon daemons</title>
 
 <para>The programs that actually perform <productname>Slony-I</productname> replication are the
@@ -74,7 +73,6 @@
 <command>COPY SET</command> in progress.</para>
 
 </sect1>
-</article>
 <!-- Keep this comment at the end of the file
 Local variables:
 mode:sgml
Index: ddlchanges.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/ddlchanges.sgml,v
retrieving revision 1.7
retrieving revision 1.8
diff -Ldoc/adminguide/ddlchanges.sgml -Ldoc/adminguide/ddlchanges.sgml -u -w -r1.7 -r1.8
--- doc/adminguide/ddlchanges.sgml
+++ doc/adminguide/ddlchanges.sgml
@@ -1,5 +1,4 @@
 <!-- $Id$ -->
-<article>
 <sect1 id="ddlchanges">
 <title>Database Schema Changes (DDL)</title>
 
@@ -107,7 +106,6 @@
 </warning>
 </sect2>
 </sect1>
-</article>
 <!-- Keep this comment at the end of the file
 Local variables:
 mode:sgml
Index: failover.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/failover.sgml,v
retrieving revision 1.8
retrieving revision 1.9
diff -Ldoc/adminguide/failover.sgml -Ldoc/adminguide/failover.sgml -u -w -r1.8 -r1.9
--- doc/adminguide/failover.sgml
+++ doc/adminguide/failover.sgml
@@ -1,5 +1,4 @@
 <!-- $Id$ -->
-<article>
 <sect1 id="failover">
 <title>Doing switchover and failover with Slony-I</title>
 
@@ -19,8 +18,9 @@
 maintenance.  And interestingly, those users who found it valuable to
 use replication for backup and failover purposes are the very ones
 that have the lowest tolerance for terms like <quote>system
-downtime.</quote> To help support these requirements, Slony-I has not
-only failover capabilities, but features for controlled origin
+downtime.</quote> To help support these requirements,
+<productname>Slony-I</productname> not only offers failover
+capabilities, but also the notion of controlled origin
 transfer.</para>
 
 <para> It is assumed in this document that the reader is familiar with
@@ -169,7 +169,7 @@
 to see if some of them need to be reapplied on the <quote>live</quote>
 cluster.  For instance, if someone was entering bank deposits
 affecting customer accounts at the time of failure, you wouldn't want
-to lose that information.</emphasis>
+to lose that information.</para>
 
 <para> If the database is very large, it may take many hours to
 recover node1 as a functioning <productname>Slony-I</productname>
@@ -179,7 +179,6 @@
 </sect2>
 
 </sect1>
-</article>
 <!-- Keep this comment at the end of the file
 Local variables:
 mode:sgml
Index: monitoring.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/monitoring.sgml,v
retrieving revision 1.9
retrieving revision 1.10
diff -Ldoc/adminguide/monitoring.sgml -Ldoc/adminguide/monitoring.sgml -u -w -r1.9 -r1.10
--- doc/adminguide/monitoring.sgml
+++ doc/adminguide/monitoring.sgml
@@ -1,5 +1,4 @@
 <!-- $Id$ -->
-<article>
 <sect1 id="monitoring">
 <title>Monitoring</title>
 
@@ -120,7 +119,6 @@
 </sect2>
 
 </sect1>
-</article>
 <!-- Keep this comment at the end of the file
 Local variables:
 mode:sgml
Index: slonik.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/slonik.sgml,v
retrieving revision 1.7
retrieving revision 1.8
diff -Ldoc/adminguide/slonik.sgml -Ldoc/adminguide/slonik.sgml -u -w -r1.7 -r1.8
--- doc/adminguide/slonik.sgml
+++ doc/adminguide/slonik.sgml
@@ -37,7 +37,7 @@
  <refsect1><title>Outline</title>
 
   <para>The <application>slonik</application> command line utility is
-  supposed to be used embedded into shell scripts and reads commands
+  supposed to be used embedded into shell scripts; it reads commands
   from files or stdin.</para>
 
   <para>It reads a set of Slonik statements, which are written in a
Index: listenpaths.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/listenpaths.sgml,v
retrieving revision 1.9
retrieving revision 1.10
diff -Ldoc/adminguide/listenpaths.sgml -Ldoc/adminguide/listenpaths.sgml -u -w -r1.9 -r1.10
--- doc/adminguide/listenpaths.sgml
+++ doc/adminguide/listenpaths.sgml
@@ -1,5 +1,4 @@
 <!-- $Id$ -->
-<article>
 <sect1 id="listenpaths"><title><productname>Slony-I</productname> listen paths</title>
 <note><para> If you are running version
 <productname>Slony-I</productname> 1.1 or later it should be
@@ -206,7 +205,6 @@
 </link> requests to generate the listener paths.</para></sect2>
 
 </sect1>
-</article>
 <!-- Keep this comment at the end of the file
 Local variables:
 mode:sgml
Index: dropthings.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/dropthings.sgml,v
retrieving revision 1.7
retrieving revision 1.8
diff -Ldoc/adminguide/dropthings.sgml -Ldoc/adminguide/dropthings.sgml -u -w -r1.7 -r1.8
--- doc/adminguide/dropthings.sgml
+++ doc/adminguide/dropthings.sgml
@@ -1,5 +1,4 @@
 <!-- $Id$ -->
-<article>
 <sect1 id="dropthings"> <title>Dropping things from Slony Replication</title>
 
 <para>There are several things you might want to do involving dropping
@@ -143,7 +142,6 @@
 may be applied by hand to each of the nodes.</para>
 </sect2>
 </sect1>
-</article>
 <!-- Keep this comment at the end of the file
 Local variables:
 mode:sgml
Index: slony.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/slony.sgml,v
retrieving revision 1.9
retrieving revision 1.10
diff -Ldoc/adminguide/slony.sgml -Ldoc/adminguide/slony.sgml -u -w -r1.9 -r1.10
--- doc/adminguide/slony.sgml
+++ doc/adminguide/slony.sgml
@@ -32,6 +32,7 @@
   <part id="slonyadmin">
     <title><productname>Slony-I</productname> Administration</title>
 
+  <article>
     &adminscripts;
     &startslons;
     &subscribenodes;
@@ -45,6 +46,7 @@
     &ddlchanges;
     &firstdb;
     &help;
+   </article>
   </part>
 
   <part id="faq">