Re: Doc fix of aggressive vacuum threshold for multixact members storage
John Naylor <johncnaylorls@gmail.com>
From: John Naylor <johncnaylorls@gmail.com>
To: Alex Friedman <alexf01@gmail.com>
Cc: Sami Imseih <samimseih@gmail.com>,
Bertrand Drouvot <bertranddrouvot.pg@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2025-03-04T06:58:09Z
Lists: pgsql-hackers
Attachments
- v5-0001-Doc-correct-aggressive-vacuum-threshold-for-multi.patch (text/x-patch) patch v5-0001
On Wed, Feb 26, 2025 at 11:50 PM Alex Friedman <alexf01@gmail.com> wrote: > > 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. LGTM. > > 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. I decided to leave this out, since I just remembered that the most likely change is actually to move to 64-bit offsets, as was proposed here and has some enthusiastic support: https://www.postgresql.org/message-id/CACG=ezaWg7_nt-8ey4aKv2w9LcuLthHknwCawmBgEeTnJrJTcw@mail.gmail.com I've attached v5 which is just v4 with only the doc changes and a draft commit message. I intend to commit this this week unless there are objections. -- John Naylor Amazon Web Services
Commits
-
Doc: correct aggressive vacuum threshold for multixact members storage
- be342766fb02 14.18 landed
- bc6a81ac3a83 15.13 landed
- 98aa99b6d682 16.9 landed
- 5c8dcf948334 17.5 landed
- fcabc3adf889 18.0 landed
-
docs: clarify new aggressive vacuum mode for multi-xacts
- c552e171d16e 15.0 cited
-
Increase threshold for multixact member emergency autovac to 50%.
- b4d4ce1d50bb 9.5.0 cited