Update of /home/cvsd/slony1/slony1-engine/doc/adminguide
In directory main.slony.info:/tmp/cvs-serv19986

Modified Files:
	loganalysis.sgml slonik_ref.sgml 
Log Message:
Changes made in 1.2 branch - new log message, WAIT ON EVENT revisions


Index: slonik_ref.sgml
===================================================================
RCS file: /home/cvsd/slony1/slony1-engine/doc/adminguide/slonik_ref.sgml,v
retrieving revision 1.73
retrieving revision 1.74
diff -C2 -d -r1.73 -r1.74
*** slonik_ref.sgml	9 Jul 2007 15:20:36 -0000	1.73
--- slonik_ref.sgml	22 Oct 2007 20:49:26 -0000	1.74
***************
*** 1278,1286 ****
       # Assuming that set 1 has direct subscribers 2 and 3
       SUBSCRIBE SET (ID = 999, PROVIDER = 1, RECEIVER = 2);
-      WAIT FOR EVENT (ORIGIN = 2, CONFIRMED = 1);
       SYNC (ID=1);
       SUBSCRIBE SET (ID = 999, PROVIDER = 1, RECEIVER = 3);
-      WAIT FOR EVENT (ORIGIN = 3, CONFIRMED = 1);
       SYNC (ID=1);
       MERGE SET ( ID = 1, ADD ID = 999, ORIGIN = 1 );
      </programlisting>
--- 1278,1286 ----
       # Assuming that set 1 has direct subscribers 2 and 3
       SUBSCRIBE SET (ID = 999, PROVIDER = 1, RECEIVER = 2);
       SYNC (ID=1);
+      WAIT FOR EVENT (ORIGIN = 1, CONFIRMED = 2, WAIT FOR=1);
       SUBSCRIBE SET (ID = 999, PROVIDER = 1, RECEIVER = 3);
       SYNC (ID=1);
+      WAIT FOR EVENT (ORIGIN = 1, CONFIRMED = 3, WAIT FOR=1);
       MERGE SET ( ID = 1, ADD ID = 999, ORIGIN = 1 );
      </programlisting>
***************
*** 2834,2842 ****
     linkend="stmtsubscribeset"> request will return the event
     confirmation almost immediately, even though there might be several
!    hours of work to do before the subscription is ready. </para>
  
!    <para> There is no reliable way, at present, to monitor from within
!    a <xref linkend="slonik"> script that <xref
!    linkend="stmtsubscribeset"> is complete.</para>
     </refsect1>
     
--- 2834,2858 ----
     linkend="stmtsubscribeset"> request will return the event
     confirmation almost immediately, even though there might be several
!    hours of work to do before the subscription is ready.  The trouble
!    with <xref linkend="stmtsubscribeset"> is that it is processed as
!    <emphasis>two</emphasis> events, one on the origin node, with a
!    second event, to enable the subscription, on the subscriber.
!    </para>
  
!    <para> In order to more reliably monitor from within a <xref
!    linkend="slonik"> script that <xref linkend="stmtsubscribeset"> is
!    complete, you may submit a <xref linkend="stmtsync"> event after
!    the subscription, and have the WAIT request wait on that
!    <command>SYNC</command> event, as follows. </para>
!     <programlisting>
!      # Assuming that set 1 has direct subscribers 2 and 3
!      SUBSCRIBE SET (ID = 999, PROVIDER = 1, RECEIVER = 2);
!      SYNC (ID=1);
!      WAIT FOR EVENT (ORIGIN = 1, CONFIRMED = 2, WAIT FOR=1);
!      SUBSCRIBE SET (ID = 999, PROVIDER = 1, RECEIVER = 3);
!      SYNC (ID=1);
!      WAIT FOR EVENT (ORIGIN = 1, CONFIRMED = 3, WAIT FOR=1);
!      MERGE SET ( ID = 1, ADD ID = 999, ORIGIN = 1 );
!     </programlisting>
     </refsect1>
     

Index: loganalysis.sgml
===================================================================
RCS file: /home/cvsd/slony1/slony1-engine/doc/adminguide/loganalysis.sgml,v
retrieving revision 1.10
retrieving revision 1.11
diff -C2 -d -r1.10 -r1.11
*** loganalysis.sgml	27 Jun 2007 17:56:11 -0000	1.10
--- loganalysis.sgml	22 Oct 2007 20:49:26 -0000	1.11
***************
*** 229,232 ****
--- 229,242 ----
  
  <para> Probably means that we just filled up a filesystem... </para></listitem>
+ 
+ <listitem><para> <command>ERROR  remoteWorkerThread_%d: "update "_slony_regress1".sl_archive_counter     set ac_num = ac_num + 1,         ac_timestamp = CURRENT_TIMESTAMP; select ac_num, ac_timestamp from "_slony_regress1".sl_archive_counter; " PGRES_FATAL_ERROR ERROR:  could not serialize access due to concurrent update</command> </para>
+ 
+ <para> This may occasionally occur when using logshipping; this will
+ typically happen if there are 3 or more nodes, and there is an attempt
+ to concurrently process events sourced from different nodes.  This
+ does not represent any serious problem; &slony1; will retry the event
+ which failed without the need for administrative intervention. </para>
+ </listitem>
+ 
  </itemizedlist>
  </sect3>