Fix autovacuum docs related to widening multixid offsets to 64 bits The explanation of aggressive scans claimed that if the multixact members grows to 2 billion entries, we launch autovacuum even if it's nominally disabled. That's no longer true; anti-wraparound vacuum is only triggered if we're in danger of running out of multixids, we no longer launch it just to shrink the 'members' SLRU. There's no wraparound danger with 'members' anymore, so it's no worse than if a user table becomes very bloated.
We do still adjust the freeze threshold though, so that if autovacuum runs, whether on schedule or as an emergency autovacuum to avoid wraparound, it will freeze more aggressively if the members SLRU is large. I removed the mention of the 4 billion member threshold, even though that still exists, because the explanation felt misleading. The aggressiveness is scaled proportionally between 2 and 4 billion members. At 4 billion it's as aggressive as it gets, but there's no sudden cliff. In the passing, fix some comments. Remove obsolete mention of safe threshold for member storage triggering autovacuum. Secondly, the freezing cutoff is adjusted to avoid the *members* SLRU from growing too large. Reported-by: Noah Misch <[email protected]> Discussion: https://www.postgresql.org/message-id/[email protected] Backpatch-through: 19 Branch ------ REL_19_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/6aa2cefe11841a6bff4dab65860c1a12a3e57146 Modified Files -------------- doc/src/sgml/maintenance.sgml | 17 +++++++---------- src/backend/access/transam/multixact.c | 6 ++---- 2 files changed, 9 insertions(+), 14 deletions(-)
