mirrors
/
postgres
mirror of https://github.com/postgres/postgres
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

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
This commit is contained in:
Amit Kapila 2019-09-19 09:13:31 +05:30
parent 50261e1520
commit c106461da4
1 changed files with 20 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
doc/src/sgml/maintenance.sgml
View File

@ -808,6 +808,26 @@ analyze threshold = analyze base threshold + analyze scale factor * number of tu
<literal>autovacuum_vacuum_cost_limit</> storage parameters have been set
are not considered in the balancing algorithm.
</para>
<para>
Autovacuum workers generally don't block other commands. If a process
attempts to acquire a lock that conficts with the
<literal>SHARE UPDATE EXCLUSIVE</literal> lock held by autovacuum, lock
acquisition will interrupt the autovacuum. For conflicting lock modes,
see <xref linkend="table-lock-compatibility">. However, if the autovacuum
is running to prevent transaction ID wraparound (i.e., the autovacuum query
name in the <structname>pg_stat_activity</structname> view ends with
<literal>(to prevent wraparound)</literal>), the autovacuum is not
automatically interrupted.
</para>
<warning>
<para>
Regularly running commands that acquire locks conflicting with a
<literal>SHARE UPDATE EXCLUSIVE</literal> lock (e.g., ANALYZE) can
effectively prevent autovacuums from ever completing.
</para>
</warning>
</sect2>
</sect1>