public inbox for [email protected]
help / color / mirror / Atom feedFrom: Ashutosh Bapat <[email protected]>
To: Michael Paquier <[email protected]>
Cc: Naga Appani <[email protected]>
Cc: Tomas Vondra <[email protected]>
Cc: Xuneng Zhou <[email protected]>
Cc: torikoshia <[email protected]>
Cc: Kirill Reshke <[email protected]>
Cc: [email protected]
Subject: Re: [Proposal] Expose internal MultiXact member count function for efficient monitoring
Date: Wed, 17 Dec 2025 10:46:51 +0530
Message-ID: <CAExHW5t-di9g+S-7pdXxCA8z3AtCWYn_=Ou9fY0aMg7K0wA2KA@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CAExHW5sFtNduYEnyGhQOb=xiLrbkvwE0merhpZA5pNqcNzBbmw@mail.gmail.com>
<CA+QeY+C38cgqesZi1Tt92=D6rw_RzCV5yKhoDe5eFLtQ9RQB_Q@mail.gmail.com>
<[email protected]>
<CABPTF7WfTDdhZbHBgoqo=uGP_DZO-xO1bX5BfkwjgHK9jU+tOA@mail.gmail.com>
<[email protected]>
<CA+QeY+Aja_=j1EuY87L06KaPO4EJqqkS4B+Vg9AsWnGM1d_VRA@mail.gmail.com>
<CAExHW5vDJ526OXv+Hk-=TxPoiL7RR+k+xSF2tyNqtaJHC5aoDQ@mail.gmail.com>
<CA+QeY+CF2q2M51k5t4rZZ2SNeEq8ORf3Dr8T1+jm72VsHRJfjw@mail.gmail.com>
<CAExHW5shToKbeiw1eRGeiSyVeCYZUJyw2KUtBKYFn0J3dCGzbA@mail.gmail.com>
<CA+QeY+CqRjUj93_kV0YmMBqfkgo4WGEoiYOaP_wCMoJ8FOKpog@mail.gmail.com>
<[email protected]>
On Wed, Dec 17, 2025 at 9:49 AM Michael Paquier <[email protected]> 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
view thread (42+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: [Proposal] Expose internal MultiXact member count function for efficient monitoring
In-Reply-To: <CAExHW5t-di9g+S-7pdXxCA8z3AtCWYn_=Ou9fY0aMg7K0wA2KA@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox