Update README.tuplock?
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
Attachments:
README.tuplock-multixact-trunc.patchtext/x-diff; name=README.tuplock-multixact-trunc.patchDownload
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
-------------
On 5/25/15 4:38 AM, Amit Langote wrote:
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.
Looks good and is AFAIK correct.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Jim Nasby wrote:
On 5/25/15 4:38 AM, Amit Langote wrote:
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.
Looks good and is AFAIK correct.
No, it's wrong .. Will push a fix, thanks.
--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Alvaro Herrera wrote:
Jim Nasby wrote:
On 5/25/15 4:38 AM, Amit Langote wrote:
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.
Looks good and is AFAIK correct.
No, it's wrong .. Will push a fix, thanks.
Pushed and back-patched. I noticed that I hadn't backpatched b01a4f6838
which also updated this file, so I did so now as a single commit.
--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2015-05-26 AM 03:12, Alvaro Herrera wrote:
Alvaro Herrera wrote:
Jim Nasby wrote:
On 5/25/15 4:38 AM, Amit Langote wrote:
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.
Looks good and is AFAIK correct.
No, it's wrong .. Will push a fix, thanks.
Pushed and back-patched. I noticed that I hadn't backpatched b01a4f6838
which also updated this file, so I did so now as a single commit.
Thanks!
Amit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers