Log Message:
-----------
Quite a number of revisions to the "Best Practices" documentation.

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

-------------- next part --------------
Index: bestpractices.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/bestpractices.sgml,v
retrieving revision 1.23
retrieving revision 1.24
diff -Ldoc/adminguide/bestpractices.sgml -Ldoc/adminguide/bestpractices.sgml -u -w -r1.23 -r1.24
--- doc/adminguide/bestpractices.sgml
+++ doc/adminguide/bestpractices.sgml
@@ -29,19 +29,20 @@
 system, with the result that there are almost an innumerable set of
 places where problems can arise.  </para> 
 
-<para> As a natural result, maintaining a clean environment is really
-valuable, as any sort of environmental <quote>messiness</quote> can
-either cause unexpected problems or mask the real problem. </para>
+<para> As a natural result, maintaining a clean, consistent
+environment is really valuable, as any sort of environmental
+<quote>messiness</quote> can either cause unexpected problems or mask
+the real problem. </para>
 
 <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
+Details count: you need to be clear on what hosts are running what
 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
-result of having a distributed system comprised of a large number of
-components that need to match. </para>
+<para> This is normally a matter of being disciplined about how your
+software is deployed, and the challenges represent a natural
+consequence of being a distributed system comprised of a large number
+of components that need to match. </para>
 </listitem>
 
 <listitem><para> If a slonik script does not run as expected in a
@@ -74,7 +75,7 @@
 <para> The <quote>geographically unbiased</quote> choice seems to be
 <command><envar>TZ</envar>=UTC</command> or
 <command><envar>TZ</envar>=GMT</command>, and to make sure that
-systems are <quote>in sync</quote> by using NTP to syncchronize clocks
+systems are <quote>in sync</quote> by using NTP to synchronize clocks
 throughout the environment. </para>
 
 <para> See also <xref linkend="times">.</para>
@@ -118,11 +119,13 @@
 automate it.  But knowing what to do ahead of time cuts down on the
 number of mistakes made.</para>
 
-<para> At Afilias, some internal <citation>The 3AM Unhappy DBA's Guide
-to...</citation> guides have been created to provide checklists of
-what to do when certain <quote>unhappy</quote> events take place; this
-sort of material is highly specific to the applications running, so
-you would need to generate your own such documents.
+<para> At Afilias, a variety of internal <citation>The 3AM Unhappy
+DBA's Guide to...</citation> guides have been created to provide
+checklists of what to do when certain <quote>unhappy</quote> events
+take place.  This sort of material is highly specific to the
+environment and the set of applications running there, so you would
+need to generate your own such documents.  This is one of the vital
+components of any disaster recovery preparations.
 </para>
 </listitem>
 
@@ -197,7 +200,9 @@
 <para> In early versions of &slony1;, it was frequently the case that
 connections could get a bit <quote>deranged</quote> which restarting
 &lslon;s would clean up.  This has become much more rare, but it has
-occasionally proven useful to restart the &lslon;.</para> </listitem>
+occasionally proven useful to restart the &lslon;.  If there has been
+any <quote>network derangement</quote>, this can clear up the issue of
+defunct database connections.  </para> </listitem>
 
 <listitem>
 <para>The <link linkend="ddlchanges"> Database Schema Changes </link>
@@ -516,8 +521,8 @@
 substantial advantage of sort memory. </para>
 
 <para> In &slony1; version 1.1.5 and later versions, indices are
-dropped and recreated automatically, which mostly eliminates the need
-for this.</para>
+dropped and recreated automatically, which effectively invalidates
+this practice.</para>
 </listitem>
 
 <listitem><para> If there are large numbers of updates taking place as
@@ -552,7 +557,12 @@
 <quote>master</quote> node, an index on <function> sl_log_1(log_xid)
 </function>.  If it doesn't exist, as the &slony1; instance was set up
 before version 1.1.1, see <filename> slony1_base.sql </filename> for
-the exact form that the index setup should take. </para> </listitem>
+the exact form that the index setup should take. </para> 
+
+<para> In 1.2, there is a process that runs automatically to add
+partial indexes by origin node number, which should be the optimal
+form for such an index to take.  </para>
+</listitem>
 
 <listitem><para> On the subscriber's &lslon;, increase
 the number of <command>SYNC</command> events processed together, with