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.

diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 693c92d9cba1bdb8f0c7be983bbe3eb7f6d563a5..5f3b6720e41a616d1906e9efd12821e0e8b21cc1 100644 (file)
--- 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.