Thread

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

Naga Appani <nagnrik@gmail.com> — 2025-12-25T00:09:14Z

Thanks for the suggestion and review, Michael and Ashutosh!

On Tue, Dec 16, 2025 at 11:17 PM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
>
> 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:
> > >
> > > 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

I’ve updated the patch as suggested.

The member storage size calculation has been refactored into a static
inline function, MultiXactMemberStorageSize(), in
src/include/access/multixact_internal.h.

Please find v13 attached.

Regards,
Naga