Hi,
Commit f741300c90141ee274f19a13629ae03a9806b598 ("Have multixact be truncated
by checkpoint, not vacuum") changed who truncates multixact. README.tuplock
still says VACUUM is in charge of the truncation. I think it's an oversight in
updating the README unless I am missing something.
I attempted to fix it as attached. See if that makes sense.
Thanks,
Amit
diff --git a/src/backend/access/heap/README.tuplock b/src/backend/access/heap/README.tuplock
index 030f6ac..562dbf7 100644
--- a/src/backend/access/heap/README.tuplock
+++ b/src/backend/access/heap/README.tuplock
@@ -99,12 +99,13 @@ figure out whether the update committed or aborted. So we have a requirement
that pg_multixact needs to retain pages of its data until we're certain that
the MultiXacts in them are no longer of interest.
-VACUUM is in charge of removing old MultiXacts at the time of tuple freezing.
-This works in the same way that pg_clog segments are removed: we have a
-pg_class column that stores the earliest multixact that could possibly be
-stored in the table; the minimum of all such values is stored in a pg_database
-column. VACUUM computes the minimum across all pg_database values, and
-removes pg_multixact segments older than the minimum.
+The checkpointer is in charge of removing old MultiXacts at the end of a
+checkpoint. This works in the same way that pg_clog segments are removed: we
+have a pg_class column that stores the earliest multixact that could possibly
+be stored in the table; the minimum of all such values is stored in a
+pg_database column. VACUUM computes the minimum across all pg_database
+values, and sets shared memory state so that the next checkpoint removes
+pg_multixact segments older than the minimum.
Infomask Bits
-------------
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
