From f7e4d5c64fb3977e3a773e7213472be1b59dab2f Mon Sep 17 00:00:00 2001 From: Peter Geoghegan Date: Sat, 2 Apr 2022 12:29:35 -0700 Subject: [PATCH] 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. --- doc/src/sgml/maintenance.sgml | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 693c92d9cb..5f3b6720e4 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -493,16 +493,17 @@ will skip pages that don't have any dead row versions even if those pages might still have row versions with old XID values. Therefore, normal VACUUMs won't always freeze every old row version in the table. - Periodically, VACUUM will perform an aggressive - vacuum, skipping only those pages which contain neither dead rows nor - any unfrozen XID or MXID values. + When that happens, VACUUM will eventually need to perform an + aggressive vacuum, which will freeze all eligible unfrozen + XID and MXID values, including those from all-visible but not all-frozen pages. + In practice most tables require periodic aggressive vacuuming. controls when VACUUM does that: all-visible but not all-frozen pages are scanned if the number of transactions that have passed since the last such scan is greater than vacuum_freeze_table_age minus vacuum_freeze_min_age. Setting vacuum_freeze_table_age to 0 forces VACUUM to - use this more aggressive strategy for all scans. + always use its aggressive strategy. @@ -711,8 +712,9 @@ HINT: Stop the postmaster and vacuum that database in single-user mode. - Aggressive VACUUM scans, regardless of - what causes them, enable advancing the value for that table. + Aggressive VACUUMs, regardless of what causes + them, are guaranteed to be able to advance + the table's relminmxid. Eventually, as all tables in all databases are scanned and their oldest multixact values are advanced, on-disk storage for older multixacts can be removed.