Re: Doc fix of aggressive vacuum threshold for multixact members storage - Mailing list pgsql-hackers

From John Naylor
Subject Re: Doc fix of aggressive vacuum threshold for multixact members storage
Date
Msg-id CANWCAZZqzOae4s94JUnkC8bJu6Em==8VUidiv9Mj+RzBCSNb+g@mail.gmail.com
Whole thread Raw
In response to Re: Doc fix of aggressive vacuum threshold for multixact members storage  (Alex Friedman <alexf01@gmail.com>)
List pgsql-hackers
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
toupdate 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

Attachment

pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: Add an option to skip loading missing publication to avoid logical replication failure
Next
From: Rahila Syed
Date:
Subject: Re: Enhancing Memory Context Statistics Reporting