Log Message:
-----------
Make failover docs clearer that the problem with a failed node is on the
application side of things.

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

-------------- next part --------------
Index: failover.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/failover.sgml,v
retrieving revision 1.22
retrieving revision 1.23
diff -Ldoc/adminguide/failover.sgml -Ldoc/adminguide/failover.sgml -u -w -r1.22 -r1.23
--- doc/adminguide/failover.sgml
+++ doc/adminguide/failover.sgml
@@ -191,9 +191,22 @@
 return into service, thereby allowing there to be two nodes out there
 able to respond in a <quote>master</quote> role. </para>
 
-<para> When failover occurs, there needs to be a mechanism to forcibly
-knock the failed node off the network.  This could take place via
-having an SNMP interface that does some combination of the following:
+<note> <para> The problem here requiring that you <quote>shoot the
+failed node in the head</quote> is not fundamentally about replication
+or &slony1;; &slony1; handles this all reasonably gracefully, as once
+the node is marked as failed, the other nodes will <quote>shun</quote>
+it, effectively ignoring it.  The problem is instead with
+<emphasis>your application.</emphasis> Supposing the failed node can
+come back up sufficiently that it can respond to application requests,
+<emphasis>that</emphasis> is likely to be a problem, and one that
+hasn't anything to do with &slony1;.  The trouble is if there are two
+databases that can respond as if they are <quote>master</quote>
+systems. </para> </note>
+
+<para> When failover occurs, there therefore needs to be a mechanism
+to forcibly knock the failed node off the network in order to prevent
+applications from getting confused.  This could take place via having
+an SNMP interface that does some combination of the following:
 
 <itemizedlist>