v2-0001-Doc-fix-of-aggressive-vacuum-threshold-for-multix.patch

From 3deda711bb4219089b32204c567e735b3d7a152b Mon Sep 17 00:00:00 2001
From: Alex Friedman <alexf01@gmail.com>
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.
     </para>
 
     <para>
@@ -792,9 +793,9 @@ HINT:  Execute a database-wide VACUUM in that database.
     <para>
      As a safety device, an aggressive vacuum scan will
      occur for any table whose multixact-age is greater than <xref
-     linkend="guc-autovacuum-multixact-freeze-max-age"/>.  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.
     </para>
-- 
2.41.0