Log Message:
-----------

Fix SGML errors

Modified Files:
--------------
    slony1-engine/doc/adminguide:
        addthings.sgml (r1.13 -> r1.14)
        adminscripts.sgml (r1.36 -> r1.37)
        bestpractices.sgml (r1.20 -> r1.21)
        faq.sgml (r1.57 -> r1.58)
        installation.sgml (r1.24 -> r1.25)
        listenpaths.sgml (r1.17 -> r1.18)
        maintenance.sgml (r1.19 -> r1.20)
        monitoring.sgml (r1.24 -> r1.25)
        slonik_ref.sgml (r1.49 -> r1.50)

-------------- next part --------------
Index: addthings.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/addthings.sgml,v
retrieving revision 1.13
retrieving revision 1.14
diff -Ldoc/adminguide/addthings.sgml -Ldoc/adminguide/addthings.sgml -u -w -r1.13 -r1.14
--- doc/adminguide/addthings.sgml
+++ doc/adminguide/addthings.sgml
@@ -91,20 +91,22 @@
 </para></listitem>
 <listitem><para> 
 Once the subscriptions have all been set up so that the new set has an identical set of subscriptions to the old set, you can merge the new set in alongside the old one via <xref linkend="stmtmergeset">
+</para></listitem>
+<listitem><para> How to add columns to a replicated table </para></listitem>
 </itemizedlist>
-</listitem>
-<listitem><para> How to add columns to a replicated table </para>
 
-<para> This also answers the question <quote>How do I rename columns
+<itemizedlist>
+<listitem><para> This also answers the question <quote>How do I rename columns
 on a replicated table?</quote>, and, more generally, other questions
 to the effect of <quote>How do I modify the definitions of replicated
-tables?</quote></para>
+tables?</quote></para></listitem>
 
-<para>If you change the <quote>shape</quote> of a replicated table, this needs to take place at exactly the same point in all of the <quote>transaction streams</quote> on all nodes that are subscribed to the set containing the table.</para>
+<listitem><para>If you change the <quote>shape</quote> of a replicated table, this needs to take place at exactly the same point in all of the <quote>transaction streams</quote> on all nodes that are subscribed to the set containing the table.</para></listitem>
 
-<para> Thus, the way to do this is to construct an SQL script consisting of the DDL changes, and then submit that script to all of the nodes via the Slonik command <xref linkend="stmtddlscript">.
+<listitem><para> Thus, the way to do this is to construct an SQL script consisting of the DDL changes, and then submit that script to all of the nodes via the Slonik command <xref linkend="stmtddlscript">.</para></listitem>
 
-<para> There are a number of <quote>sharp edges</quote> to note...
+<listitem><para> There are a number of <quote>sharp edges</quote> to note...</para></listitem>
+</itemizedlist>
 <itemizedlist>
     <listitem><para> You absolutely <emphasis>must not</emphasis> include transaction control commands, particularly <command>BEGIN</command> and <command>COMMIT</command>, inside these DDL scripts. &slony1; wraps DDL scripts with a <command>BEGIN</command>/<command>COMMIT</command> pair; adding extra transaction control will mean that parts of the DDL will commit outside the control of &slony1; </para></listitem>
 
@@ -112,7 +114,7 @@
 </itemizedlist>
 
 </para></listitem>
-<listitem><para> How to remove replication for a node
+<listitem><para> How to remove replication for a node</para>
 <para> You will want to remove the various &slony1; components connected to the database(s).</para>
 
 <para> We will just consider, for now, doing this to one node. If you have multiple nodes, you will have to repeat this as many times as necessary.</para>
@@ -175,7 +177,7 @@
 </itemizedlist>
 </listitem>
 
-<listitem><para> How do I reshape the subscriptions?
+<listitem><para> How do I reshape the subscriptions?</para>
 
 <para> For instance, I want subscriber node 3 to draw data from node
 1, when it is presently drawing data from node 2. </para>
Index: adminscripts.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/adminscripts.sgml,v
retrieving revision 1.36
retrieving revision 1.37
diff -Ldoc/adminguide/adminscripts.sgml -Ldoc/adminguide/adminscripts.sgml -u -w -r1.36 -r1.37
--- doc/adminguide/adminscripts.sgml
+++ doc/adminguide/adminscripts.sgml
@@ -358,7 +358,7 @@
 <filename>rc.d</filename> processes, or regularly, as a cron process,
 to ensure that &lslon; processes are running.</para>
 
-<para> It uses the following environment variables:
+<para> It uses the following environment variables:</para>
 
 <itemizedlist>
 
@@ -377,7 +377,7 @@
 
 <para> If you remove some of these files, or rename them so their
 names do not conform to the <command>find</command> command, they
-won't be found; that is an easy way to drop nodes out of this system.
+won't be found; that is an easy way to drop nodes out of this system.</para>
 </listitem>
 
 <listitem><para><envar>LOGHOME </envar> indicates the
@@ -386,7 +386,7 @@
 <para> This script does not assume the use of the Apache log rotator
 to manage logs; in that &postgres; version 8 does its own log
 rotation, it seems undesirable to retain a dependancy on specific log
-rotation <quote>technology.</quote> </listitem>
+rotation <quote>technology.</quote> </para></listitem>
 
 <listitem><para><envar>CLUSTERS</envar> is a list of &slony1; clusters
 under management. </para></listitem>
@@ -395,7 +395,7 @@
 
 <para> In effect, you could run this every five minutes, and it would
 launch any missing &lslon; processes. </para>
-
+</sect2>
 <sect2><title> slony-cluster-analysis </title>
 
 <para> If you are running a lot of replicated databases, where there
Index: slonik_ref.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/slonik_ref.sgml,v
retrieving revision 1.49
retrieving revision 1.50
diff -Ldoc/adminguide/slonik_ref.sgml -Ldoc/adminguide/slonik_ref.sgml -u -w -r1.49 -r1.50
--- doc/adminguide/slonik_ref.sgml
+++ doc/adminguide/slonik_ref.sgml
@@ -1051,7 +1051,7 @@
    <refsect1> <title> Locking Behaviour </title>
 
     <para> On the origin node, this will take out an exclusive lock on
-    the table being modified for as long as it takes to:
+    the table being modified for as long as it takes to:</para>
     <itemizedlist>
     <listitem><para> Alter the table, adding the column;</para></listitem>
     <listitem><para> Alter each row in the table, attaching the sequence value;</para></listitem>
Index: bestpractices.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/bestpractices.sgml,v
retrieving revision 1.20
retrieving revision 1.21
diff -Ldoc/adminguide/bestpractices.sgml -Ldoc/adminguide/bestpractices.sgml -u -w -r1.20 -r1.21
--- doc/adminguide/bestpractices.sgml
+++ doc/adminguide/bestpractices.sgml
@@ -36,7 +36,7 @@
 <para> Numerous users have reported problems resulting from mismatches
 between &slony1; versions, local libraries, and &postgres; libraries.
 Details count; you need to be clear on what hosts are running what
-versions of what software.  
+versions of what software. </para>
 
 <para> This is normally a matter of being meticulous about checking
 what versions of software are in place everywhere, and is the natural
@@ -279,7 +279,7 @@
 <listitem><para> <command>CREATE TABLE</command> </para>
 <para> Tables that are not being replicated do not require &slony1; <quote>permission</quote>. </para></listitem>
 
-<listitem><para> <command>CREATE OR REPLACE FUNCTION </command> 
+<listitem><para> <command>CREATE OR REPLACE FUNCTION </command> </para>
 
 <para> Typically, new versions of functions may be done without
 &slony1; being <quote>aware</quote> of them.  The obvious exception is
Index: installation.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/installation.sgml,v
retrieving revision 1.24
retrieving revision 1.25
diff -Ldoc/adminguide/installation.sgml -Ldoc/adminguide/installation.sgml -u -w -r1.24 -r1.25
--- doc/adminguide/installation.sgml
+++ doc/adminguide/installation.sgml
@@ -245,6 +245,8 @@
 <para> See the <filename>INSTALL</filename> file for a workaround for
 Fedora...</para>
 
+</sect2>
+
 <sect2>
 <title> Installing &slony1; from RPMs</title>
 
Index: maintenance.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/maintenance.sgml,v
retrieving revision 1.19
retrieving revision 1.20
diff -Ldoc/adminguide/maintenance.sgml -Ldoc/adminguide/maintenance.sgml -u -w -r1.19 -r1.20
--- doc/adminguide/maintenance.sgml
+++ doc/adminguide/maintenance.sgml
@@ -212,10 +212,10 @@
 to minimizing the cost of submitting replication test queries; on a
 busy cluster, supporting hundreds of users, the cost associated with
 running a few queries is likely to be pretty irrelevant, and the setup
-cost to configure the tables and data injectors is pretty high.<para>
+cost to configure the tables and data injectors is pretty high.</para>
 
 <para> Three other methods for analyzing the state of replication have
-stood out:
+stood out:</para>
 
 <itemizedlist>
 
@@ -254,7 +254,7 @@
 discussion. </para></listitem>
 
 </itemizedlist>
-
+</sect2>
 <sect2><title> Log Files</title>
 
 <indexterm><primary>log files</primary></indexterm>
Index: monitoring.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/monitoring.sgml,v
retrieving revision 1.24
retrieving revision 1.25
diff -Ldoc/adminguide/monitoring.sgml -Ldoc/adminguide/monitoring.sgml -u -w -r1.24 -r1.25
--- doc/adminguide/monitoring.sgml
+++ doc/adminguide/monitoring.sgml
@@ -229,13 +229,13 @@
 <para> ... Since I use <application>mrtg</application> to graph data
 from multiple servers I use snmp (<application>net-snmp</application>
 to be exact).  On database server, I added the following line to
-<application>snmpd</application> configuration:
+<application>snmpd</application> configuration:</para>
 
 <programlisting>
 exec replicationLagTime  /cvs/scripts/snmpReplicationLagTime.sh 2
+where <filename> /cvs/scripts/snmpReplicationLagTime.sh</filename> looks like this:
 </programlisting>
 
-where <filename> /cvs/scripts/snmpReplicationLagTime.sh</filename> looks like this:
 
 <programlisting>
 #!/bin/bash
Index: faq.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/faq.sgml,v
retrieving revision 1.57
retrieving revision 1.58
diff -Ldoc/adminguide/faq.sgml -Ldoc/adminguide/faq.sgml -u -w -r1.57 -r1.58
--- doc/adminguide/faq.sgml
+++ doc/adminguide/faq.sgml
@@ -221,10 +221,11 @@
 </programlisting>
 </answer>
 
-<answer><para> In version 8.1 and higher, you may also need the following:
+<answer><para> In version 8.1 and higher, you may also need the following:</para>
 <programlisting>
 update pg_authid set rolcatupdate = 't', rolsuper='t' where rolname = 'slony';
 </programlisting>
+</answer>
 </qandaentry>
 
 <qandaentry>
Index: listenpaths.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/listenpaths.sgml,v
retrieving revision 1.17
retrieving revision 1.18
diff -Ldoc/adminguide/listenpaths.sgml -Ldoc/adminguide/listenpaths.sgml -u -w -r1.17 -r1.18
--- doc/adminguide/listenpaths.sgml
+++ doc/adminguide/listenpaths.sgml
@@ -203,6 +203,7 @@
 <function>RebuildListenEntries()</function> will be called to revise
 the listener paths.</para>
 
+</sect2>
 </sect1>
 <!-- Keep this comment at the end of the file
 Local variables: