Thread

Re: [Proposal] Expose internal MultiXact member count function for efficient monitoring

Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> — 2025-12-17T05:16:51Z

On Wed, Dec 17, 2025 at 9:49 AM Michael Paquier <michael@paquier.xyz> wrote:
>
> On Sat, Dec 13, 2025 at 01:34:47PM -0600, Naga Appani wrote:
> > Documentation changes:
> > - Removed the NULL-return discussion from func-info.sgml, as the
> >   statistics are now always available.
> > - Updated maintenance.sgml to clarify that exceeding the historical
> >   2^32 member limit no longer causes wraparound, but instead triggers
> >   more aggressive vacuum activity for disk space management.
> >
> > I validated the behavior before and after cleanup.
> > The function correctly reports current usage (beyond the old limits) and
> > resets once multixacts are removed:
>
> +       /*
> +        * Calculate storage space for members. Members are stored in groups,
> +        * with each group containing MULTIXACT_MEMBERS_PER_MEMBERGROUP members
> +        * and taking MULTIXACT_MEMBERGROUP_SIZE bytes.
> +        */
> +       membersBytes = (int64) (members / MULTIXACT_MEMBERS_PER_MEMBERGROUP) *
> +                                  MULTIXACT_MEMBERGROUP_SIZE;
>
> This is the key point of the patch internal logic.  And there is one
> thing that I am wondering here.  The amount of space taken by a number
> of members depends on the other compiled constants from
> multixact_internal.h.  Hence, rather than calculate the amount of
> space taken by a set of members in some code hidden in the SQL
> function, could it be better to put that directly as a macro or an
> inline function in multixact_internal.h?

+1.

-- 
Best Wishes,
Ashutosh Bapat