Log Message:
-----------
Added discussion of the confusion that may occur if a node is
dropped via FAIL OVER due to a persistent network outage.

Added a link to Slony-II efforts.

Fixed a problem with a link to a URL that cannot be handled as
an XREF.

Modified Files:
--------------
    slony1-engine/doc/adminguide:
        failover.sgml (r1.14 -> r1.15)
        help.sgml (r1.15 -> r1.16)
        locking.sgml (r1.1 -> r1.2)

-------------- next part --------------
Index: help.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/help.sgml,v
retrieving revision 1.15
retrieving revision 1.16
diff -Ldoc/adminguide/help.sgml -Ldoc/adminguide/help.sgml -u -w -r1.15 -r1.16
--- doc/adminguide/help.sgml
+++ doc/adminguide/help.sgml
@@ -67,6 +67,9 @@
 <listitem><para><ulink url="http://freshmeat.net/projects/slonyi/">
 Freshmeat on &slony1; </ulink></para></listitem>
 
+<listitem> <para><ulink url="http://www.slony2.org/wiki/index.php"> 
+Slony-II Wiki</ulink> </para> </listitem> 
+
 </itemizedlist>
 </sect2>
 </sect1>
Index: locking.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/locking.sgml,v
retrieving revision 1.1
retrieving revision 1.2
diff -Ldoc/adminguide/locking.sgml -Ldoc/adminguide/locking.sgml -u -w -r1.1 -r1.2
--- doc/adminguide/locking.sgml
+++ doc/adminguide/locking.sgml
@@ -157,8 +157,8 @@
 <emphasis>necessary</emphasis> to submit a <xref
 linkend="stmtmoveset"> request, then it is presumably
 <emphasis>necessary</emphasis> to accept the brief application outage.
-As &slony1;/<xref linkend="pgpool"> linkages improve, that may become
-a better way to handle this.</para>
+As &slony1;/<link linkend="pgpool"> pgpool </link> linkages improve,
+that may become a better way to handle this.</para>
 
 </sect1>
 <!-- Keep this comment at the end of the file
Index: failover.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/failover.sgml,v
retrieving revision 1.14
retrieving revision 1.15
diff -Ldoc/adminguide/failover.sgml -Ldoc/adminguide/failover.sgml -u -w -r1.14 -r1.15
--- doc/adminguide/failover.sgml
+++ doc/adminguide/failover.sgml
@@ -176,6 +176,33 @@
 affecting customer accounts at the time of failure, you wouldn't want
 to lose that information.</para>
 
+<warning> <para> It has been observed that there can be some very
+confusing results if a node is <quote>failed</quote> due to a
+persistent network outage as opposed to failure of data storage.  In
+such a scenario, the <quote>failed</quote> node has a database in
+perfectly fine form; it is just that since it was cut off, it
+<quote>screams in silence.</quote> </para>
+
+<para> If the network connection is repaired, that node could
+reappear, and as far as <emphasis>its</emphasis> configuration is
+concerned, all is well, and it should communicate with the rest of its
+&slony1; cluster. </para>
+
+<para> In <emphasis>fact</emphasis>, the only confusion taking place
+is on that node.  The other nodes in the cluster are not confused at
+all; they know that this node is <quote>dead,</quote> and that they
+should ignore it.  But there is not a way to know this by looking at
+the <quote>failed</quote> node.
+</para> 
+
+<para> This points back to the design point that &slony1; is not a
+network monitoring tool.  You need to have clear methods of
+communicating to applications and users what database hosts are to be
+used.  If those methods are lacking, adding replication to the mix
+will worsen the potential for confusion, and failover will be the
+point at which there is the greatest potential for confusion. </para>
+</warning>
+
 <para> If the database is very large, it may take many hours to
 recover node1 as a functioning &slony1; node; that is another reason
 to consider failover as an undesirable <quote>final