Log Message:
-----------
Add mention in docs that pg_autovacuum can "invisibly" cause ops like
MOVE SET, EXECUTE SCRIPT to be held up due to the locks it holds

Modified Files:
--------------
    slony1-engine/doc/adminguide:
        faq.sgml (r1.62 -> r1.63)
        locking.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.62
retrieving revision 1.63
diff -Ldoc/adminguide/faq.sgml -Ldoc/adminguide/faq.sgml -u -w -r1.62 -r1.63
--- doc/adminguide/faq.sgml
+++ doc/adminguide/faq.sgml
@@ -1169,6 +1169,25 @@
 will cause trouble, and should be avoided, even on subscriber
 nodes.</para> </answer></qandaentry>
 
+<qandaentry> <question> <para> I have submitted a <xref
+linkend="stmtmoveset"> / <xref linkend="stmtddlscript"> request, and
+it seems to be stuck on one of my nodes.  &slony1; logs aren't
+displaying any errors or warnings </para> </question>
+
+<answer> <para> Is it possible that you are running
+<application>pg_autovacuum</application>, and it has taken out locks
+on some tables in the replication set?  That would somewhat-invisibly
+block &slony1; from performing operations that require <link
+linkend="locking"> acquisition of exclusive locks. </link> </para>
+
+<para> You might check for these sorts of locks using the following
+query: <command> select l.*, c.relname from pg_locks l, pg_class c
+where c.oid = l.relation ; </command> A
+<envar>ShareUpdateExclusiveLock</envar> lock will block the &slony1;
+operations that need their own exclusive locks, which are likely
+queued up, marked as not being granted. </para>
+</answer> </qandaentry>
+
 </qandadiv>
 <qandadiv id="faqbugs"> <title> &slony1; FAQ: &slony1; Bugs in Elder Versions </title>
 <qandaentry>
Index: locking.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/locking.sgml,v
retrieving revision 1.8
retrieving revision 1.9
diff -Ldoc/adminguide/locking.sgml -Ldoc/adminguide/locking.sgml -u -w -r1.8 -r1.9
--- doc/adminguide/locking.sgml
+++ doc/adminguide/locking.sgml
@@ -80,6 +80,13 @@
 
 </listitem>
 
+<listitem><para> <application>pg_autovacuum</application> may not be
+part of &slony1;, but those that run it find that it wakes up roughly
+once per minute and may, at any time, start vacuuming a table, thereby
+taking out a <envar>ShareUpdateExclusiveLock</envar> lock.  This may
+block the other events for an unpredictable period of time.<para>
+</listitem>
+
 </itemizedlist>
 
 <para> Each of these actions requires, at some point, modifying each