Log Message:
-----------
Documentation modifications to address the recent change to MOVE SET that
refuses to proceed unless subscriptions have completed.

Modified Files:
--------------
    slony1-engine/doc/adminguide:
        addthings.sgml (r1.24 -> r1.25)
        loganalysis.sgml (r1.4 -> r1.5)
        slonik_ref.sgml (r1.63 -> r1.64)

-------------- next part --------------
Index: addthings.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/addthings.sgml,v
retrieving revision 1.24
retrieving revision 1.25
diff -Ldoc/adminguide/addthings.sgml -Ldoc/adminguide/addthings.sgml -u -w -r1.24 -r1.25
--- doc/adminguide/addthings.sgml
+++ doc/adminguide/addthings.sgml
@@ -26,7 +26,11 @@
 if <xref linkend="stmtmergeset"> is issued while other
 subscription-related events are pending, it is possible for things to
 get pretty confused on the nodes where other things were pending.
-This problem was resolved in 1.0.5.</para>
+This problem was resolved in 1.0.5.  Up until 1.2.1, there was still a
+problem where <xref linkend="stmtmergeset"> could be requested before
+all the subscriptions were complete, which would <quote>muss things
+up</quote> on nodes where subscription activity was still under
+way. </para>
 
 <para> Note that if you add nodes, you will need to add both <xref
 linkend="stmtstorepath"> statements to indicate how nodes communicate
@@ -109,9 +113,7 @@
 <listitem><para> Once the subscriptions have all been set up so that
 the new set has an identical set of subscriptions to the old set, you
 can merge the new set in alongside the old one via <xref
-linkend="stmtmergeset"> If you submit the request too soon, there is
-the risk that the subscription won't actually be complete on all
-nodes, and some subscribers may break down.  </para></listitem>
+linkend="stmtmergeset"> </para></listitem>
 </itemizedlist>
 </sect2>
 
Index: slonik_ref.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/slonik_ref.sgml,v
retrieving revision 1.63
retrieving revision 1.64
diff -Ldoc/adminguide/slonik_ref.sgml -Ldoc/adminguide/slonik_ref.sgml -u -w -r1.63 -r1.64
--- doc/adminguide/slonik_ref.sgml
+++ doc/adminguide/slonik_ref.sgml
@@ -1282,7 +1282,10 @@
 
    </refsect1>
    <refsect1> <title> Version Information </title> <para> This command
-   was introduced in &slony1; 1.0.5 </para>
+   was introduced in &slony1; 1.0.5.  In 1.2.1, a race condition was
+   rectified where the merge request would be submitted while
+   subscriptions were still in process on subscribers; it refuses to
+   merge before subscriptions are complete.  </para>
    </refsect1>
   </refentry>
 
@@ -1304,7 +1307,7 @@
    <refsect1>
     <title>Description</title>
     
-    <para> Add an existing user table to a replication set. The set
+    <para> Add an existing usep table to a replication set. The set
     cannot currently be subscribed by any other node - that
     functionality is supported by the <xref linkend="stmtmergeset">
     command.
Index: loganalysis.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/loganalysis.sgml,v
retrieving revision 1.4
retrieving revision 1.5
diff -Ldoc/adminguide/loganalysis.sgml -Ldoc/adminguide/loganalysis.sgml -u -w -r1.4 -r1.5
--- doc/adminguide/loganalysis.sgml
+++ doc/adminguide/loganalysis.sgml
@@ -541,6 +541,48 @@
 
 <para> Indicates the total time required to complete copy_set...  This indicates a successful subscription!</para>
 </listitem>
+
+<listitem><para><command>DEBUG1: remoteWorkerThread_%d: copy_set %d done in %.3f seconds</command></para> 
+
+<para> Indicates the total time required to complete copy_set...  This indicates a successful subscription!</para>
+</listitem>
+
+</itemizedlist>
+</sect3>
+<sect3 id="logmergeset"> <title> Log Entries Associated with MERGE SET</title>
+
+<para> These various exceptions cause <xref linkend="stmtmergeset"> to
+be rejected; something ought to be corrected before submitting the request again. </para>
+
+<itemizedlist>
+<listitem><para><command>ERROR: Slony-I: merged set ids cannot be identical</command></para> 
+
+<para> It is illogical to try to merge a set with itself. </para></listitem>
+
+<listitem><para><command>ERROR: Slony-I: set % not found </command></para> 
+
+<para> A missing set cannot be merged. </para></listitem>
+
+<listitem><para><command>ERROR: Slony-I: set % does not originate on local node</command></para> 
+
+<para> The <xref linkend="stmtmergeset"> request must be submitted to
+the origin node for the sets that are to be merged. </para></listitem>
+
+<listitem><para><command>ERROR: Slony-I: subscriber lists of set % and % are different</command></para> 
+
+<para> Sets can only be merged if they have identical subscriber
+lists.  </para></listitem>
+
+<listitem><para><command>ERROR: Slony-I: set % has subscriptions in progress - cannot merge</command></para> 
+
+<para> <xref linkend="stmtmergeset"> cannot proceed until all
+subscriptions have completed processing.  If this message arises, that
+indicates that the subscriber lists <emphasis>are</emphasis> the same,
+but that one or more of the nodes has not yet completed setting up its
+subscription.  It may be that waiting a short while will permit
+resubmitting the <xref linkend="stmtmergeset"> request.
+</para></listitem>
+
 </itemizedlist>
 </sect3>