Hi John,
Thanks for reviewing.
It seems at a minimum this one-line patch is sufficient for the correction:
- storage occupied by multixacts members exceeds 2GB, aggressive vacuum
+ storage occupied by multixacts members exceeds about 10GB,
aggressive vacuum
Commit c552e171d16e removed the percentage as part of a judgment call
on clarity, and I'm not sure that was wrong.
We could add the proposed language on "can grow up to about 20GB" at
the end of this paragraph, which seems more natural -- first mention
the amount that triggers aggressive vacuum, then the maximum size.
Yes, I believe this can work.
I'm on the fence about putting a hint in the C file, but the
computation has changed in the past, see commit b4d4ce1d50bbdf , so
it's a reasonable idea.
That's a good find about the change. Taken together with Bertrand's comments,
I've added two reminders to multixact.c to update the docs, one for the
threshold and another for the multixact storage scheme. Please see if it makes
sense.
v4 patch attached.
Best regards,
Alex Friedman
From 0965413dbb0b85e4dd78f87a6ca3847dccdc78c7 Mon Sep 17 00:00:00 2001
From: Alex Friedman <alex...@gmail.com>
Date: Thu, 30 Jan 2025 17:19:07 +0200
Subject: [PATCH v4] Doc fix of aggressive vacuum threshold for multixact
members storage.
---
doc/src/sgml/maintenance.sgml | 5 +++--
src/backend/access/transam/multixact.c | 7 +++++--
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 0be90bdc7ef..89040942be2 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -793,10 +793,11 @@ 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 <xref
linkend="guc-autovacuum-multixact-freeze-max-age"/>. Also, if the
- storage occupied by multixacts members exceeds 2GB, aggressive vacuum
+ storage occupied by multixacts members exceeds about 10GB, 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.
+ scans will occur even if autovacuum is nominally disabled. The members
storage
+ area can grow up to about 20GB before reaching wraparound.
</para>
<para>
diff --git a/src/backend/access/transam/multixact.c
b/src/backend/access/transam/multixact.c
index 27ccdf9500f..66adb9995d0 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -134,7 +134,8 @@ MultiXactIdToOffsetSegment(MultiXactId multi)
* corresponding 4 Xids. Each such 5-word (20-byte) set we call a "group", and
* are stored as a whole in pages. Thus, with 8kB BLCKSZ, we keep 409 groups
* per page. This wastes 12 bytes per page, but that's OK -- simplicity (and
- * performance) trumps space efficiency here.
+ * performance) trumps space efficiency here. If this computation changes, make
+ * sure to update the documentation.
*
* Note that the "offset" macros work with byte offset, not array indexes, so
* arithmetic must be done using "char *" pointers.
@@ -212,7 +213,9 @@ MXOffsetToMemberOffset(MultiXactOffset offset)
member_in_group * sizeof(TransactionId);
}
-/* Multixact members wraparound thresholds. */
+/* Multixact members wraparound thresholds.
+ * When changing the thresholds, make sure to update the documentation.
+ */
#define MULTIXACT_MEMBER_SAFE_THRESHOLD (MaxMultiXactOffset / 2)
#define MULTIXACT_MEMBER_DANGER_THRESHOLD \
(MaxMultiXactOffset - MaxMultiXactOffset / 4)
--
2.41.0
