Log Message:
-----------
Fix tagging errors

Modified Files:
--------------
    slony1-engine/doc/adminguide:
        addthings.sgml (r1.18 -> r1.19)
        adminscripts.sgml (r1.37 -> r1.38)
        ddlchanges.sgml (r1.25 -> r1.26)
        loganalysis.sgml (r1.1 -> r1.2)
        maintenance.sgml (r1.23 -> r1.24)
        slonyupgrade.sgml (r1.1 -> r1.2)

-------------- next part --------------
Index: slonyupgrade.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/slonyupgrade.sgml,v
retrieving revision 1.1
retrieving revision 1.2
diff -Ldoc/adminguide/slonyupgrade.sgml -Ldoc/adminguide/slonyupgrade.sgml -u -w -r1.1 -r1.2
--- doc/adminguide/slonyupgrade.sgml
+++ doc/adminguide/slonyupgrade.sgml
@@ -5,7 +5,7 @@
 
 <para> When upgrading &slony1;, the installation on all nodes in a
 cluster must be upgraded at once, using the &lslonik;
-command <xref linkend="stmtupgradefunctions">.</para>
+command <xref linkend="stmtupdatefunctions">.</para>
 
 <para> While this requires temporarily stopping replication, it does
 not forcibly require an outage for applications that submit
Index: addthings.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/addthings.sgml,v
retrieving revision 1.18
retrieving revision 1.19
diff -Ldoc/adminguide/addthings.sgml -Ldoc/adminguide/addthings.sgml -u -w -r1.18 -r1.19
--- doc/adminguide/addthings.sgml
+++ doc/adminguide/addthings.sgml
@@ -315,7 +315,7 @@
 </listitem>
 
 <listitem><para> <link linkend="slonyupgrade">How do I upgrade
-&slony1; to a newer version?<linkend> </para> </listitem>
+&slony1; to a newer version?</link> </para> </listitem>
 
 <listitem><para> What happens when I fail over?</para> 
 
Index: maintenance.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/maintenance.sgml,v
retrieving revision 1.23
retrieving revision 1.24
diff -Ldoc/adminguide/maintenance.sgml -Ldoc/adminguide/maintenance.sgml -u -w -r1.23 -r1.24
--- doc/adminguide/maintenance.sgml
+++ doc/adminguide/maintenance.sgml
@@ -50,7 +50,10 @@
 storing data in &sllog1; and &sllog2; so that it may seek
 to <command>TRUNCATE</command> the <quote>elder</quote> data.</para>
 
-<para> That means that on a regular basis, these tables are completely cleared out, so that you will not suffer from them having grown to some significant size, due to heavy load, after which they are incapable of shrinking back down </para> </listitem>
+<para> That means that on a regular basis, these tables are completely
+cleared out, so that you will not suffer from them having grown to
+some significant size, due to heavy load, after which they are
+incapable of shrinking back down </para> </listitem>
 
 </itemizedlist>
 </para>
Index: adminscripts.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/adminscripts.sgml,v
retrieving revision 1.37
retrieving revision 1.38
diff -Ldoc/adminguide/adminscripts.sgml -Ldoc/adminguide/adminscripts.sgml -u -w -r1.37 -r1.38
--- doc/adminguide/adminscripts.sgml
+++ doc/adminguide/adminscripts.sgml
@@ -119,6 +119,7 @@
 </itemizedlist>
 </sect2>
 <sect2><title>slonik_build_env</title>
+<indexterm><primary>slonik_build_env</primary></indexterm>
 
 <para>Queries a database, generating output hopefully suitable for
 <filename>slon_tools.conf</filename> consisting of:</para>
@@ -258,6 +259,8 @@
 
 <sect2 id="mkslonconf"><title>mkslonconf.sh</title>
 
+<indexterm><primary>script - mkslonconf.sh</primary></indexterm>
+
 <para> This is a shell script designed to rummage through a &slony1;
 cluster and generate a set of <filename>slon.conf</filename> files
 that &lslon; accesses via the <command> slon -f slon.conf </command>
@@ -352,6 +355,9 @@
 
 <sect2 id="launchclusters"><title> launch_clusters.sh </title>
 
+<indexterm><primary>script - launch_clusters.sh</primary></indexterm>
+
+
 <para> This is another shell script which uses the configuration as
 set up by <filename>mkslonconf.sh</filename> and is intended to either
 be run at system boot time, as an addition to the
@@ -398,6 +404,9 @@
 </sect2>
 <sect2><title> slony-cluster-analysis </title>
 
+<indexterm><primary>script - slony-cluster-analysis</primary></indexterm>
+
+
 <para> If you are running a lot of replicated databases, where there
 are numerous &slony1; clusters, it can get painful to track and
 document this.  The following tools may be of some assistance in this.</para>
Index: ddlchanges.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/ddlchanges.sgml,v
retrieving revision 1.25
retrieving revision 1.26
diff -Ldoc/adminguide/ddlchanges.sgml -Ldoc/adminguide/ddlchanges.sgml -u -w -r1.25 -r1.26
--- doc/adminguide/ddlchanges.sgml
+++ doc/adminguide/ddlchanges.sgml
@@ -218,7 +218,7 @@
 propagated at the same location in the transaction stream on all the
 nodes, then you but no tables need to be locked, then you need to use
 <command>EXECUTE SCRIPT</command>, locking challenges or
-no.</quote></para></listitem>
+no.</para></listitem>
 
 <listitem><para> You may want an extra index on some replicated
 node(s) in order to improve performance there.</para>
Index: loganalysis.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/loganalysis.sgml,v
retrieving revision 1.1
retrieving revision 1.2
diff -Ldoc/adminguide/loganalysis.sgml -Ldoc/adminguide/loganalysis.sgml -u -w -r1.1 -r1.2
--- doc/adminguide/loganalysis.sgml
+++ doc/adminguide/loganalysis.sgml
@@ -62,6 +62,8 @@
 
 <sect2> <title> How to read &slony1; logs </title>
 
+<indexterm><primary>reading and understanding &slony1; logs</primary></indexterm>
+
 <para> Note that as far as slon is concerned, there is no
 <quote>master</quote> or <quote>slave.</quote> They are just
 nodes. </para>
@@ -172,8 +174,7 @@
 the <command>DEBUG4</command> messages that are generally
 uninteresting.</para>
 
-<sect3 id="logshiplog"><title> Log Messages Associated with Log
-Shipping <title>
+<sect3 id="logshiplog"><title> Log Messages Associated with Log Shipping </title>
 
 <para> Most of these represent errors that come up if
 the <xref linkend="logshipping"> functionality breaks.  You may expect
@@ -785,7 +786,7 @@
 <para> Many of these errors will occur if you submit a &lslonik;
 script that describes a reconfiguration incompatible with your
 cluster's current configuration.  Those will lead to the
-feeling: <quote>Whew, I'm glad &lslonik; caught that for me!</quote> </quote>
+feeling: <quote>Whew, I'm glad &lslonik; caught that for me!</quote> </para>
 
 <para> Some of the others lead to a &lslon; telling itself to fall
 over; all <emphasis>should</emphasis> be well when you restart it, as