Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly
Appearance settings

Commit f7e4d5c

Browse filesBrowse files
petergeogheganpetergeoghegan
committed
Doc: Clarify the role of aggressive VACUUMs.
Adjust the documentation's coverage of aggressive VACUUMs to make it clearer that aggressive vacuuming isn't always strictly necessary. It's possible for non-aggressive VACUUMs to advance relfrozenxid/relminmxid without fail, given the right workload conditions. While this has always been true, it matters more with recent and pending improvements to VACUUM. These improvements make non-aggressive vacuuming more likely to advance relfrozenxid/relminmxid in practice. While this is an unrelated improvement to the docs, formally speaking, it still doesn't seem worth backpatching. So don't backpatch.
1 parent 1b208eb commit f7e4d5c
Copy full SHA for f7e4d5c

File tree

1 file changed

+8
-6
lines changed
Filter options

1 file changed

+8
-6
lines changed

‎doc/src/sgml/maintenance.sgml

Copy file name to clipboardExpand all lines: doc/src/sgml/maintenance.sgml
+8-6Lines changed: 8 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -493,16 +493,17 @@
493493
will skip pages that don't have any dead row versions even if those pages
494494
might still have row versions with old XID values. Therefore, normal
495495
<command>VACUUM</command>s won't always freeze every old row version in the table.
496-
Periodically, <command>VACUUM</command> will perform an <firstterm>aggressive
497-
vacuum</firstterm>, skipping only those pages which contain neither dead rows nor
498-
any unfrozen XID or MXID values.
496+
When that happens, <command>VACUUM</command> will eventually need to perform an
497+
<firstterm>aggressive vacuum</firstterm>, which will freeze all eligible unfrozen
498+
XID and MXID values, including those from all-visible but not all-frozen pages.
499+
In practice most tables require periodic aggressive vacuuming.
499500
<xref linkend="guc-vacuum-freeze-table-age"/>
500501
controls when <command>VACUUM</command> does that: all-visible but not all-frozen
501502
pages are scanned if the number of transactions that have passed since the
502503
last such scan is greater than <varname>vacuum_freeze_table_age</varname> minus
503504
<varname>vacuum_freeze_min_age</varname>. Setting
504505
<varname>vacuum_freeze_table_age</varname> to 0 forces <command>VACUUM</command> to
505-
use this more aggressive strategy for all scans.
506+
always use its aggressive strategy.
506507
</para>
507508

508509
<para>
@@ -711,8 +712,9 @@ HINT: Stop the postmaster and vacuum that database in single-user mode.
711712
</para>
712713

713714
<para>
714-
Aggressive <command>VACUUM</command> scans, regardless of
715-
what causes them, enable advancing the value for that table.
715+
Aggressive <command>VACUUM</command>s, regardless of what causes
716+
them, are <emphasis>guaranteed</emphasis> to be able to advance
717+
the table's <structfield>relminmxid</structfield>.
716718
Eventually, as all tables in all databases are scanned and their
717719
oldest multixact values are advanced, on-disk storage for older
718720
multixacts can be removed.

0 commit comments

Comments
0 (0)
Morty Proxy This is a proxified and sanitized view of the page, visit original site.