On Wed, Feb 26, 2025 at 11:50 PM Alex Friedman <alex...@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-8ey4akv2w9lculthhknwcawmbgeetnjrj...@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
From 3867ebb5edda3daec956ccd9c4fcd62ea625eeed Mon Sep 17 00:00:00 2001 From: John Naylor <john.nay...@postgresql.org> Date: Tue, 4 Mar 2025 13:55:27 +0700 Subject: [PATCH v5] Doc: correct aggressive vacuum threshold for multixact members storage The threshold is two billion members, which was interpreted as 2GB in the documentation. Fix to reflect that each member takes up five bytes, which translates to about 10GB. This is not exact, because of page boundaries. While at it, mention the maximum size 20GB. This has been wrong since commit c552e171d16e, so backpatch to version 14. Author: Alex Friedman <alex...@gmail.com> Reviewed-by: Sami Imseih <samims...@gmail.com> Reviewed-by: Bertrand Drouvot <bertranddrouvot...@gmail.com> Discussion: https://postgr.es/m/cacbfw60uok6fcc02ksyt3ofu9dnuq5royxdw2afisin_p1l...@mail.gmail.com Backpatch-through: 14 --- doc/src/sgml/maintenance.sgml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b5b9da7f8a9..600e4b3f2f3 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -811,10 +811,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> -- 2.48.1
