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


Fix unclosed tags

Modified Files:
--------------
    slony1-engine/doc/adminguide:
        bestpractices.sgml (r1.7 -> r1.8)

-------------- next part --------------
Index: bestpractices.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/bestpractices.sgml,v
retrieving revision 1.7
retrieving revision 1.8
diff -Ldoc/adminguide/bestpractices.sgml -Ldoc/adminguide/bestpractices.sgml -u -w -r1.7 -r1.8
--- doc/adminguide/bestpractices.sgml
+++ doc/adminguide/bestpractices.sgml
@@ -23,7 +23,8 @@
 
 <itemizedlist>
 
-<listitem><para> &slony1; is a complex multi-client, multi-server
+<listitem>
+<para> &slony1; is a complex multi-client, multi-server
 system, with the result that there are almost an innumerable set of
 places where problems can arise.  </para> 
 
@@ -36,10 +37,10 @@
 Details count; you need to be clear on what hosts are running what
 versions of what software.
 </para>
-
 </listitem>
 
-<listitem><para> Principle: Use an unambiguous, stable time zone such
+<listitem>
+<para> Principle: Use an unambiguous, stable time zone such
 as UTC or GMT. </para>
 
 <para> Users have run into problems when their system uses a time zone
@@ -55,9 +56,11 @@
 <command><envar>TZ</envar>=UTC</command> or
 <command><envar>TZ</envar>=GMT</command>. </para>  
 
-<para> See also <xref linkend="times">.</para></listitem>
+<para> See also <xref linkend="times">.</para>
+</listitem>
 
-<listitem><para> Principle: Long running transactions are Evil </para>
+<listitem>
+<para> Principle: Long running transactions are Evil </para>
 
 <para> The FAQ has an entry on <link linkend="pglistenerfull"> growth
 of <envar>pg_listener</envar> </link> which discusses this in a fair
@@ -67,7 +70,8 @@
 from taking effect, and the like.</para>
 </listitem>
 
-<listitem><para> <link linkend="Failover"> Failover </link> policies
+<listitem>
+<para> <link linkend="Failover"> Failover </link> policies
 should be planned for ahead of time.  </para>
 
 <para> This may simply involve thinking about what the priority lists
@@ -88,7 +92,8 @@
 enough to require <link linkend="failover"> failover </link>. </para>
 </listitem>
 
-<listitem><para> <command>VACUUM</command> policy needs to be
+<listitem>
+<para> <command>VACUUM</command> policy needs to be
 carefully defined.</para>
 
 <para> As mentioned above, <quote>long running transactions are
@@ -97,7 +102,8 @@
 transaction with all the known ill effects.</para>
 </listitem>
 
-<listitem><para> Running all of the <xref linkend="slon"> daemons on a
+<listitem>
+<para> Running all of the <xref linkend="slon"> daemons on a
 central server for each network has proven preferable. </para> 
 
 <para> Each <xref linkend="slon"> should run on a host on the same
@@ -124,11 +130,13 @@
 eliminating duplication of configuration efforts.</para>
 </listitem>
 
-<listitem><para>The <link linkend="ddlchanges"> Database Schema
+<listitem>
+<para>The <link linkend="ddlchanges"> Database Schema
 Changes </link> section outlines some practices that have been found
 useful for handling changes to database schemas. </para></listitem>
 
-<listitem><para> Handling of Primary Keys </para> 
+<listitem>
+<para> Handling of Primary Keys </para> 
 
 <para> Discussed in the section on <link linkend="definingsets">
 Replication Sets, </link> it is <emphasis>ideal</emphasis> if each
@@ -142,18 +150,22 @@
 introduced a new failure mode for your application.</para>
 </listitem>
 
-<listitem><para> <link linkend="definesets"> Grouping tables into sets
+<listitem>
+<para> <link linkend="definesets"> Grouping tables into sets
 </link> suggests strategies for determining how to group tables and
-sequences into replication sets. </para> </listitem>
+sequences into replication sets. </para>
+</listitem>
 
-<listitem><para> It should be obvious that actions that can delete a
+<listitem>
+<para> It should be obvious that actions that can delete a
 lot of data should be taken with great care; the section on <link
 linkend="dropthings"> Dropping things from &slony1; Replication</link>
 discusses the different sorts of <quote>deletion</quote> that &slony1;
-supports.  </para> </listitem>
+supports.  </para>
+</listitem>
 
-<listitem><para> <link linkend="Locking"> Locking issues </link>
-</para>
+<listitem>
+<para> <link linkend="Locking"> Locking issues </link></para>
 
 <para> Certain &slony1; operations, notably <link
 linkend="stmtsetaddtable"> <command>set add table</command> </link>,
@@ -165,9 +177,11 @@
 
 <para> Depending on the kind of activity on the databases, this may or
 may not have the effect of requiring a (hopefully brief) database
-outage. </para> </listitem>
+outage. </para>
+</listitem>
 
-<listitem id="slonyuser"><para> &slony1;-specific user names. </para>
+<listitem id="slonyuser">
+<para> &slony1;-specific user names. </para>
 
 <para> It has proven useful to define a <command>slony</command> user
 for use by &slony1;, as distinct from a generic
@@ -194,7 +208,8 @@
 </para>
 </listitem>
 
-<listitem><para> Path configuration </para> 
+<listitem>
+<para> Path configuration </para> 
 
 <para> The section on <link linkend="plainpaths"> Path Communications
 </link> discusses the issues surrounding what network connections need
@@ -211,16 +226,22 @@
 to be configured by hand.  Many seemingly inexplicable communications
 failures, where nodes failed to talk to one another even though they
 technically could, were a result of incorrect listen path
-configuration. </para> </listitem>
+configuration. </para>
+</listitem>
 
-<listitem><para> Configuring <xref linkend="slon"> </para> 
+<listitem>
+<para> Configuring <xref linkend="slon"> </para> 
 
 <para> As of version 1.1, <xref linkend="slon"> configuration may be
 drawn either from the command line or from configuration files.
-<quote>Best</quote> practices have yet to emerge from the two options:
+<quote>Best</quote> practices have yet to emerge from the two options:</para>
+</listitem>
+</itemizedlist>
 
 <itemizedlist>
-<listitem><para> Configuration via command line options</para> 
+
+<listitem>
+<para> Configuration via command line options</para> 
 
 <para> This approach has the merit that all the options that are
 active are visible in the process environment.  (And if there are a
@@ -233,7 +254,8 @@
 logs for a log shipping node. </para>
 </listitem>
 
-<listitem><para> Unlike when command line options are used, the active
+<listitem>
+<para> Unlike when command line options are used, the active
 options are <emphasis>not</emphasis> visible.  They can only be
 inferred from the name and/or contents of the <xref linkend="slon">
 configuration file, and will not reflect subsequent changes to the
@@ -241,11 +263,11 @@
 
 <para> By putting the options in a file, you won't forget including
 any of them, so this is safer for <link linkend="logshipping"> log
-shipping. </link> </para> </listitem>
+shipping. </link> </para>
+</listitem>
 
 </itemizedlist>
-</para>
-</listitem>
+<itemizedlist>
 
 <listitem><para> Things to do when subscribing nodes </para>
 
@@ -255,7 +277,8 @@
 desirable to lock all users other than the <command>slony</command>
 user out of the new subscriber because:
 </para>
-
+</listitem>
+</itemizedlist>
 <itemizedlist>
 
 <listitem><para> Applications will run into partially-copied,
@@ -275,8 +298,8 @@
 <quote>falls over</quote> during the <command>COPY_SET</command>
 event, you will be restarting the copy of the whole replication
 set.</para>
-</listitem>
 
+<itemizedlist>
 <listitem><para> Managing use of slonik </para> 
 
 <para> The notes on <link linkend="usingslonik"> Using Slonik </link>
@@ -284,15 +307,16 @@
 <xref linkend="slonik"> scripts.</para>
 </listitem>
 
-<listitem><para> Handling Very Large Replication Sets </para>
+<listitem><para> Handling Very Large Replication Sets </para></listitem>
 
-<para> Some users have set up replication on replication sets that are
+<listitem><para> Some users have set up replication on replication sets that are
 tens to hundreds of gigabytes in size, which puts some added
 <quote>strain</quote> on the system, in particular where it may take
 several days for the <command>COPY_SET</command> event to complete.
 Here are some principles that have been observed for dealing with
-these sorts of situtations.</para>
+these sorts of situtations.</para></listitem>
 
+</itemizedlist>
 <itemizedlist>
 
 <listitem><para> Drop all indices other than the primary key index
@@ -330,8 +354,9 @@
 </para> </listitem>
 
 <listitem><para> Several things can be done that will help, involving
-careful selection of <xref linkend="slon"> parameters:</para>
+careful selection of <xref linkend="slon"> parameters:</para></listitem>
 
+</itemizedlist>
 <itemizedlist>
 
 <listitem><para> On the subscriber's <xref linkend="slon">, increase
@@ -354,13 +379,13 @@
 of events by a factor of 60. </para> </listitem>
 </itemizedlist>
 
+<itemizedlist>
 <listitem><para> It is likely to be worthwhile to use <xref
 linkend="slon-config-vac-frequency"> to deactivate <xref
 linkend="slon">-initiated vacuuming in favor of running your own
 vacuum scripts, as there will be a buildup of unpurgeable data while
 the data is copied and the subscriber starts to catch up. </para>
 </listitem>
-</listitem>
 </itemizedlist>
 
 </sect1>