Log Message:
-----------
Draw in all changes that have been made in 1.1-STABLE, of late...

Modified Files:
--------------
    slony1-engine/doc/adminguide:
        adminscripts.sgml (r1.28 -> r1.29)
        bestpractices.sgml (r1.12 -> r1.13)
        concepts.sgml (r1.16 -> r1.17)
        ddlchanges.sgml (r1.18 -> r1.19)
        defineset.sgml (r1.19 -> r1.20)
        failover.sgml (r1.18 -> r1.19)
        faq.sgml (r1.49 -> r1.50)
        filelist.sgml (r1.14 -> r1.15)
        firstdb.sgml (r1.16 -> r1.17)
        installation.sgml (r1.18 -> r1.19)
        intro.sgml (r1.19 -> r1.20)
        legal.sgml (r1.8 -> r1.9)
        locking.sgml (r1.4 -> r1.5)
        logshipping.sgml (r1.11 -> r1.12)
        man.sgml (r1.3 -> r1.4)
        monitoring.sgml (r1.20 -> r1.21)
        plainpaths.sgml (r1.9 -> r1.10)
        reshape.sgml (r1.15 -> r1.16)
        slon.sgml (r1.22 -> r1.23)
        slonik.sgml (r1.14 -> r1.15)
        slony.sgml (r1.25 -> r1.26)
        startslons.sgml (r1.13 -> r1.14)
        subscribenodes.sgml (r1.13 -> r1.14)
        testbed.sgml (r1.4 -> r1.5)
        usingslonik.sgml (r1.13 -> r1.14)
        versionupgrade.sgml (r1.6 -> r1.7)

-------------- next part --------------
Index: adminscripts.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/adminscripts.sgml,v
retrieving revision 1.28
retrieving revision 1.29
diff -Ldoc/adminguide/adminscripts.sgml -Ldoc/adminguide/adminscripts.sgml -u -w -r1.28 -r1.29
--- doc/adminguide/adminscripts.sgml
+++ doc/adminguide/adminscripts.sgml
@@ -235,16 +235,6 @@
 &slony1; functions.  This will typically be needed when you upgrade
 from one version of &slony1; to another.</para>
 </sect2>
-<sect2 id="regenlisten"><title>regenerate-listens</title>
-
-<para>This script connects to a &slony1; node, and queries various
-tables (sl_set, sl_node, sl_subscribe, sl_path) to compute what <xref
-    linkend="stmtstorelisten"> requests should be submitted to the
-cluster.</para>
-
-<para> See the documentation in <xref linkend="autolisten"> for more
-details on how this works.</para>
-</sect2>
 
 </sect1>
 <!-- Keep this comment at the end of the file
Index: subscribenodes.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/subscribenodes.sgml,v
retrieving revision 1.13
retrieving revision 1.14
diff -Ldoc/adminguide/subscribenodes.sgml -Ldoc/adminguide/subscribenodes.sgml -u -w -r1.13 -r1.14
--- doc/adminguide/subscribenodes.sgml
+++ doc/adminguide/subscribenodes.sgml
@@ -85,6 +85,8 @@
 contain any tables, that can lead to a problem that will stop
 replication from proceeding. </para>
 
+<para> Note that this bug is addressed as of &slony1; 1.1.5 </para>
+
 <para> If a particular subscriber is only being fed sequences by one
 of its providers, the query that collects <command>SYNC</command>
 event data will not be constructed correctly, and you will see error
Index: legal.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/legal.sgml,v
retrieving revision 1.8
retrieving revision 1.9
diff -Ldoc/adminguide/legal.sgml -Ldoc/adminguide/legal.sgml -u -w -r1.8 -r1.9
--- doc/adminguide/legal.sgml
+++ doc/adminguide/legal.sgml
@@ -1,7 +1,7 @@
 <!-- $Id$ -->
 
 <copyright>
- <year>2004-2005</year>
+ <year>2004-2006</year>
  <holder>The PostgreSQL Global Development Group</holder>
 </copyright>
 
@@ -9,7 +9,7 @@
  <title>Legal Notice</title>
 
  <para>
-  <productname>PostgreSQL</productname> is Copyright &copy; 2004-2005
+  <productname>PostgreSQL</productname> is Copyright &copy; 2004-2006
   by the PostgreSQL Global Development Group and is distributed under
   the terms of the license of the University of California below.
  </para>
Index: faq.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/faq.sgml,v
retrieving revision 1.49
retrieving revision 1.50
diff -Ldoc/adminguide/faq.sgml -Ldoc/adminguide/faq.sgml -u -w -r1.49 -r1.50
--- doc/adminguide/faq.sgml
+++ doc/adminguide/faq.sgml
@@ -1806,6 +1806,35 @@
 discussion on postgresql-hackers mailing list. </ulink>.  </para>
 </answer>
 </qandaentry>
+
+<qandaentry>
+<question> <para> I am running &slony1; 1.1 and have a 4+ node setup
+where there are two subscription sets, 1 and 2, that do not share any
+nodes.  I am discovering that confirmations for set 1 never get to the
+nodes subscribing to set 2, and that confirmations for set 2 never get
+to nodes subscribing to set 1.  As a result, <xref
+linkend="table.sl-log-1"> grows and grows and is never purged.  This
+was reported as &slony1; <ulink
+url="http://gborg.postgresql.org/project/slony1/bugs/bugupdate.php?1485">
+bug 1485 </ulink>.
+</para>
+</question>
+
+<answer><para> Apparently the code for
+<function>RebuildListenEntries()</function> does not suffice for this
+case.</para>
+
+<para> <function> RebuildListenEntries()</function> will be replaced
+in &slony1; version 1.2 with an algorithm that covers this case. </para>
+
+<para> In the interim, you'll want to manually add some <xref
+linkend="table.sl-listen"> entries using <xref
+linkend="stmtstorelisten"> or <function>storeListen()</function>,
+based on the (apparently not as obsolete as we thought) principles
+described in <xref linkend="listenpaths">.
+
+</para></answer>
+</qandaentry>
 </qandaset>
 
 <!-- Keep this comment at the end of the file Local variables:
Index: monitoring.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/monitoring.sgml,v
retrieving revision 1.20
retrieving revision 1.21
diff -Ldoc/adminguide/monitoring.sgml -Ldoc/adminguide/monitoring.sgml -u -w -r1.20 -r1.21
--- doc/adminguide/monitoring.sgml
+++ doc/adminguide/monitoring.sgml
@@ -152,13 +152,13 @@
 </para>
 </sect2>
 
-<sect2> <title> Nagios Replication Checks </title>
+<sect2> <title> &nagios& Replication Checks </title>
 
 <para> The script in the <filename>tools</filename> directory called
-<command> pgsql_replication_check.pl </command> represents about best
-answers yet arrived at in several attempts to build replication tests
-to plug into the <ulink url="http://www.nagios.org/"> Nagios </ulink>
-system monitoring tool.</para>
+<command> pgsql_replication_check.pl </command> represents some of the
+best answers arrived at in attempts to build replication tests to plug
+into the <ulink url="http://www.nagios.org/"> &nagios; </ulink> system
+monitoring tool.</para>
 
 <para> A former script, <filename>
 test_slony_replication.pl</filename>, took a <quote>clever</quote>
@@ -174,9 +174,10 @@
 approach has been fragile to numerous error conditions.</para>
 </listitem>
 
-<listitem><para> Nagios has no ability to benefit from the
+<listitem><para> &nagios; has no ability to benefit from the
 <quote>cleverness</quote> of automatically exploring the set of nodes.
-</para> </listitem>
+You need to set up a &nagios; monitoring rule for each and every node
+being monitored.  </para> </listitem>
 </itemizedlist>
 
 <para> The new script, <command>pgsql_replication_check.pl</command>,
@@ -200,11 +201,45 @@
 </itemizedlist>
 
 <para> An instance of the script will need to be run for each node
-that is to be monitored; that is the way
-<application>Nagios</application> works. </para>
+that is to be monitored; that is the way &nagios; works. </para>
 
 </sect2>
 
+<sect2 id="slonymrtg"> <title> Monitoring &slony1; using MRTG </title>
+
+<para> One user reported on the &slony1; mailing list how to configure
+<ulink url="http://people.ee.ethz.ch/~oetiker/webtools/mrtg/">
+<application> mrtg - Multi Router Traffic Grapher </application>
+</ulink> to monitor &slony1; replication.</para>
+
+<para> ... Since I use <application>mrtg</application> to graph data
+from multiple servers I use snmp (<application>net-snmp</application>
+to be exact).  On database server, I added the following line to
+<application>snmpd</application> configuration:
+
+<programlisting>
+exec replicationLagTime  /cvs/scripts/snmpReplicationLagTime.sh 2
+</programlisting>
+
+where <filename> /cvs/scripts/snmpReplicationLagTime.sh</filename> looks like this:
+
+<programlisting>
+#!/bin/bash
+/home/pgdba/work/bin/psql -U pgdba -h 127.0.0.1 -p 5800 -d _DBNAME_ -qAt -c
+"select cast(extract(epoch from st_lag_time) as int8) FROM _irr.sl_status
+WHERE st_received = $1"
+</programlisting>
+
+<para> Then, in mrtg configuration,  add this target:</para>
+<programlisting>
+Target[db_replication_lagtime]:extOutput.3&amp;extOutput.3:public at db::30:::
+MaxBytes[db_replication_lagtime]: 400000000
+Title[db_replication_lagtime]: db: replication lag time
+PageTop[db_replication_lagtime]: &lt;H1&gt;db: replication lag time&lt;/H1&gt;
+Options[db_replication_lagtime]: gauge,nopercent,growright
+</programlisting>
+</sect2>
+
 <sect2 id="testslonystate"> <title> test_slony_state</title>
 
 <para> This script is in preliminary stages, and may be used to do
Index: slony.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/slony.sgml,v
retrieving revision 1.25
retrieving revision 1.26
diff -Ldoc/adminguide/slony.sgml -Ldoc/adminguide/slony.sgml -u -w -r1.25 -r1.26
--- doc/adminguide/slony.sgml
+++ doc/adminguide/slony.sgml
@@ -8,6 +8,7 @@
   <!entity reference  SYSTEM "reference.sgml">
   <!ENTITY slony1 "<PRODUCTNAME>Slony-I</PRODUCTNAME>">
   <!ENTITY postgres "<PRODUCTNAME>PostgreSQL</PRODUCTNAME>">
+  <!ENTITY nagios "<PRODUCTNAME>Nagios</PRODUCTNAME>">
   <!ENTITY windows "<trademark>Windows</trademark>">
   <!ENTITY logship "<link linkend=logshipping>log shipping</link>">
   <!ENTITY rlocking "<link linkend=locking> locking </link>">