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 d95c218d39c6c4ca14bc4b1435bc504431bedafc..aee8ff2dfbe53b84a2d6047c6248f39458788361 100644 (file)
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -825,6 +825,26 @@ analyze threshold = analyze base threshold + analyze scale factor * number of tu
     autovacuum_vacuum_cost_limit storage parameters 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.
+    
+