public inbox for [email protected]
help / color / mirror / Atom feedFrom: Naga Appani <[email protected]>
To: Ashutosh Bapat <[email protected]>
Cc: Tomas Vondra <[email protected]>
Cc: Xuneng Zhou <[email protected]>
Cc: torikoshia <[email protected]>
Cc: Michael Paquier <[email protected]>
Cc: Kirill Reshke <[email protected]>
Cc: [email protected]
Subject: Re: [Proposal] Expose internal MultiXact member count function for efficient monitoring
Date: Sat, 6 Dec 2025 11:52:57 -0600
Message-ID: <CA+QeY+CF2q2M51k5t4rZZ2SNeEq8ORf3Dr8T1+jm72VsHRJfjw@mail.gmail.com> (raw)
In-Reply-To: <CAExHW5vDJ526OXv+Hk-=TxPoiL7RR+k+xSF2tyNqtaJHC5aoDQ@mail.gmail.com>
References: <CALdSSPi3Gh08NtcCn44uVeUAYGOT74sU6uei_06qUTa5rMK43g@mail.gmail.com>
<CAExHW5s-StFwDpZBeiikvdnrBBr0s+2jJTZRv3Hh914T4C6Euw@mail.gmail.com>
<CA+QeY+AmRSSJU8GKJ1uNVe2ps8GTONXpioYR7gEz91_prKR6sw@mail.gmail.com>
<[email protected]>
<CA+QeY+AwWV=g8z1eDE7OGHxKBer18gVER7nD+SnfhqLmiL7NOA@mail.gmail.com>
<[email protected]>
<[email protected]>
<CAExHW5sUU1+Vq9oG6x=u85W7Obr-dPfAc7rQtaN-LJw5uufuMA@mail.gmail.com>
<CA+QeY+DLsjj4RxY-Z2wRC-sYCeFxuPSd8zSkt4Nvs==YV6GP6w@mail.gmail.com>
<CAExHW5tDxjXKcP0XuUZXb_UbpAs_oQ29HyOtvL0xf7dCkk5ypw@mail.gmail.com>
<CA+QeY+A2B7mjWc8kkieNS_nxNyTeZpTzi4Ue+vtHzkmfFxO-8Q@mail.gmail.com>
<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>
Hi Ashutosh,
Thanks for the review!
I agree - comparing the exposed members_size against the documented
thresholds is sufficient for monitoring purposes.
This aligns with the approach taken in v11: exposing the current usage in
a way consistent with other PostgreSQL counters (e.g., XIDs, OIDs), without
introducing user-visible remaining-capacity calculations whose behavior is
inconsistent and difficult to interpret externally. In the same spirit, I
removed oldest_offset: as we discussed, it is internal and does not
provide an actionable signal to users.
If this addresses the concerns raised so far, I would appreciate
consideration in moving v11 forward for commit.
On Mon, Nov 10, 2025 at 12:13 AM Ashutosh Bapat
<[email protected]> wrote:
>
> On Wed, Nov 5, 2025 at 6:43 AM Naga Appani <[email protected]> wrote:
> >
> > Understanding
> > ============
> > Based on reading the relevant parts of multixact.c and observing the runtime
> > behavior, both approaches seem to run into limitations when trying to derive a
> > “remaining members” value outside the backend. I may be missing details, but the
> > behavior I observed suggests that a reliable computation might require
> > duplicating
> > several internal mechanisms, including:
> > - wrap-aware offset comparison
> > - SLRU page and segment alignment rules
> > - SetOffsetVacuumLimit’s segment recalculation
> >
> > Without accounting for those, the derived numbers behaved inconsistently across
> > tests, sometimes staying at 0 until a large jump, and in other cases increasing
> > between exhaustion cycles. This seems broadly consistent with your concern that
> > simple arithmetic on these counters does not match how the backend determines
> > wraparound risk.
> >
> > To be clear, this interpretation is based only on what I could infer from the
> > code and testing, and I may not be capturing the entire picture. But from what I
> > observed, a user-visible “remaining members” metric does not seem
> > straightforward
> > without exposing or replicating backend logic.
>
> Right now MultiXactOffsetWouldWrap() assesses if the given distance is
> higher than the permitted distance between start and boundary. I think
> we could instead change it to report the permitted distance based on
> start and boundary; use it to report remaining space (after
> multiplying it with bytes per member) and also use it to assess
> whether the required distance is within that boundary or whether we
> need a warning. But ...
> On Sat, Oct 18, 2025 at 4:48 PM Tomas Vondra <[email protected]> wrote:
> >
> > Thanks for working on this. I'm wondering if this is expected / could
> > help with monitoring for "space exhaustion" issues, which we currently
> > can't do easily, as it's not exposed anywhere.
> >
> > This is in multixact.c at line ~1177, where we do this:
> >
> > if (MultiXactState->oldestOffsetKnown &&
> > MultiXactOffsetWouldWrap(MultiXactState->offsetStopLimit,
> > nextOffset, nmembers))
> > {
> > ereport(ERROR, ...
> > }
> >
> > But I'm not sure the current patch exposes enough information to
> > calculate how much space remains - calculating that we requires
> > offsetStopLimit and nextOffset.
>
> The function exposes the number of existing members and the amount of
> space they consume (members_size). The documentation mentions space
> related thresholds 10GB and 20GB. Isn't comparing members_size to
> these thresholds enough to take appropriate action? If so, we could
> report the difference between these respective thresholds and
> members_size as a metric of space remaining before a given threshold
> is triggered.
Best regards,
Naga
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: <CA+QeY+CF2q2M51k5t4rZZ2SNeEq8ORf3Dr8T1+jm72VsHRJfjw@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