Doc: document autovacuum interruption.

It's important users be able to know (without looking at the source code)
that running DDL or DDL-like commands can interrupt autovacuum which can
lead to a lot of dead tuples and hence slower database operations.

Reported-by: James Coleman
Author: James Coleman
Reviewed-by: Amit Kapila
Backpatch-through: 9.4
Discussion:https://postgr.es/m/CAAaqYe-XYyNwML1=f=gnd0qWg46PnvD=BDrCZ5-L94B887XVxQ@mail.gmail.com

diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 69682334a8dff8d70dedcf58038bb6405ed15cfe..c32c642fca16ec8ca803b431dd6167188bcc5b4a 100644 (file)
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -824,6 +824,26 @@ analyze threshold = analyze base threshold + analyze scale factor * number of tu
     autovacuum_vacuum_cost_limit have been set are not considered
     in the balancing algorithm.
    
+
+   
+    Autovacuum workers generally don't block other commands.  If a process
+    attempts to acquire a lock that conficts with the
+    SHARE UPDATE EXCLUSIVE lock held by autovacuum, lock
+    acquisition will interrupt the autovacuum.  For conflicting lock modes,
+    see .  However, if the autovacuum
+    is running to prevent transaction ID wraparound (i.e., the autovacuum query
+    name in the pg_stat_activity view ends with
+    (to prevent wraparound)), the autovacuum is not
+    automatically interrupted.
+   
+
+   
+    
+     Regularly running commands that acquire locks conflicting with a
+     SHARE UPDATE EXCLUSIVE lock (e.g., ANALYZE) can
+     effectively prevent autovacuums from ever completing.
+    
+