From 3deda711bb4219089b32204c567e735b3d7a152b Mon Sep 17 00:00:00 2001 From: Alex Friedman Date: Thu, 30 Jan 2025 17:19:07 +0200 Subject: [PATCH v2] Doc fix of aggressive vacuum threshold for multixact members storage. --- doc/src/sgml/maintenance.sgml | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 0be90bdc7ef..f4f560bccc1 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -761,7 +761,8 @@ HINT: Execute a database-wide VACUUM in that database. careful aging management, storage cleanup, and wraparound handling. There is a separate storage area which holds the list of members in each multixact, which also uses a 32-bit counter and which must also - be managed. + be managed. This members storage area can grow up to about 20GB before + reaching wraparound. @@ -792,9 +793,9 @@ HINT: Execute a database-wide VACUUM in that database. As a safety device, an aggressive vacuum scan will occur for any table whose multixact-age is greater than . Also, if the - storage occupied by multixacts members exceeds 2GB, aggressive vacuum - scans will occur more often for all tables, starting with those that + linkend="guc-autovacuum-multixact-freeze-max-age"/>. Also, if the storage occupied + by multixacts members exceeds about 10GB (50% of the maximum the members area can grow), + aggressive vacuum scans will occur more often for all tables, starting with those that have the oldest multixact-age. Both of these kinds of aggressive scans will occur even if autovacuum is nominally disabled. -- 2.41.0