Log Message:
-----------
Add in discussion of the "long running idle transaction" problem.

Modified Files:
--------------
    slony1-engine/doc/adminguide:
        faq.sgml (r1.8 -> r1.9)

-------------- next part --------------
Index: faq.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/faq.sgml,v
retrieving revision 1.8
retrieving revision 1.9
diff -Ldoc/adminguide/faq.sgml -Ldoc/adminguide/faq.sgml -u -w -r1.8 -r1.9
--- doc/adminguide/faq.sgml
+++ doc/adminguide/faq.sgml
@@ -369,18 +369,19 @@
 subscribing to "set 1" to the new set, and then merge the sets
 together.</para>
 </answer></qandaentry>
-<qandaentry>
+
+<qandaentry id="PGLISTENERFULL">
 <question><para>Some nodes start consistently falling behind</para>
 
-<para>I have been running <productname>Slony-I</productname> on a node for a while, and am seeing
-system performance suffering.</para>
+<para>I have been running <productname>Slony-I</productname> on a node
+for a while, and am seeing system performance suffering.</para>
 
 <para>I'm seeing long running queries of the form:
 <screen>
 	fetch 100 from LOG;
 </screen></para></question>
 
-<answer><para> This is characteristic of pg_listener (which is the
+<answer><para> This can be characteristic of pg_listener (which is the
 table containing <command>NOTIFY</command> data) having plenty of dead
 tuples in it.  That makes <command>NOTIFY</command> events take a long
 time, and causes the affected node to gradually fall further and
@@ -836,21 +837,104 @@
 affected node.</para></answer>
 </qandaentry>
 
+<qandaentry>
+
+<question><para>I just used <link linkend="stmtmoveset"> <command>MOVE
+SET</command> </link> to move the origin to a new node.
+Unfortunately, some subscribers are still pointing to the former
+origin node, so I can't take it out of service for maintenance without
+stopping them from getting updates.  What do I do?  </para></question>
+
+<answer><para> You need to use <link linkend="stmtsubscribeset">
+<command>SUBSCRIBE SET</command> </link> to alter the subscriptions
+for those nodes to have them subscribe to a provider that
+<emphasis>will</emphasis> be sticking around during the
+maintenance.</para>
+
+<warning> <para> What you <emphasis>don't</emphasis> do is to <link
+linkend="stmtunsubscribeset"> <command>UNSUBSCRIBE SET</command>
+</link>; that would require reloading all data for the nodes from
+scratch later.
+
+</para></warning>
+</answer>
+</qandaentry>
+
+<qandaentry> 
+
+<question><para> Replication has been slowing down, I'm seeing <command>
+FETCH 100 FROM LOG </command> queries running for a long time, <envar>
+sl_log_1 </envar> is growing, and performance is, well, generally
+getting steadily worse. </para>
+</question>
+
+<answer> <para> There are actually a number of possible causes for
+this sort of thing.  There is a question involving similar pathology
+where the problem is that <link linkend="pglistenerfull"> <envar>
+pg_listener </envar> grows because it is not vacuumed. </link>
+</para>
+
+<para> Another <quote> proximate cause </quote> for this growth is for
+there to be a connection connected to the node that sits <command>
+IDLE IN TRANSACTION </command> for a very long time. </para>
+
+<para> That open transaction will have multiple negative effects, all
+of which will adversely affect performance:
+
+<itemizedlist>
+
+<listitem><para> Vacuums on all tables, including <envar> pg_listener
+</envar>, will not clear out dead tuples from before the start of the
+idle transaction. </para> </listitem>
+
+<listitem><para> The cleanup thread will be unable to clean out
+entries in <envar> sl_log_1 </envar> and <envar> sl_seqlog </envar>,
+with the result that these tables will grow, ceaselessly, until the
+transaction is closed. </para> </listitem>
+</itemizedlist>
+</answer>
+
+<answer> <para> You can monitor for this condition inside the database
+only if the <productname> PostgreSQL </productname> <filename>
+postgresql.conf </filename> parameter
+<envar>stats_command_string</envar> is set to true.  If that is set,
+then you may submit the query <command> select * from pg_stat_activity
+where current_query like '%IDLE% in transaction'; </command> which
+will find relevant activity.
+</para> </answer>
+
+<answer> <para> You should also be able to search for <quote> idle in
+transaction </quote> in the process table to find processes that are
+thus holding on to an ancient transaction.  </para> </answer>
+
+<answer> <para> It is also possible (though rarer) for the problem to
+be a transaction that is, for some other reason, being held open for a
+very long time.  The <envar> query_start </envar> time in <envar>
+pg_stat_activity </envar> may show you some query that has been
+running way too long.  </para> </answer>
+
+<answer> <para> There are plans for
+<productname>PostgreSQL</productname> to have a timeout parameter,
+<envar> open_idle_transaction_timeout </envar>, which would cause old
+transactions to time out after some period of disuse.  Buggy
+connection pool logic is a common culprit for this sort of thing.
+There are plans for <productname> pgpool </productname> to provide a
+better alternative, eventually, where connections would be shared
+inside a connection pool implemented in C.  You may have some more or
+less buggy connection pool in your Java or PHP application; if a small
+set of <emphasis> real </emphasis> connections are held in
+<productname>pgpool</productname>, that will hide from the database
+the fact that the application imagins that numerous of them are left
+idle in transaction for hours at a time.  </para> </answer>
+
+</qandaentry> 
+
 </qandaset>
 
-<!-- Keep this comment at the end of the file
-Local variables:
-mode:sgml
-sgml-omittag:nil
-sgml-shorttag:t
-sgml-minimize-attributes:nil
-sgml-always-quote-attributes:t
-sgml-indent-step:1
-sgml-indent-data:t
-sgml-parent-document:slony.sgml
-sgml-default-dtd-file:"./reference.ced"
-sgml-exposed-tags:nil
+<!-- Keep this comment at the end of the file Local variables:
+mode:sgml sgml-omittag:nil sgml-shorttag:t
+sgml-minimize-attributes:nil sgml-always-quote-attributes:t
+sgml-indent-step:1 sgml-indent-data:t sgml-parent-document:slony.sgml
+sgml-default-dtd-file:"./reference.ced" sgml-exposed-tags:nil
 sgml-local-catalogs:("/usr/lib/sgml/catalog")
-sgml-local-ecat-files:nil
-End:
--->
+sgml-local-ecat-files:nil End: -->