public inbox for [email protected]
help / color / mirror / Atom feedFrom: Ashutosh Bapat <[email protected]>
To: Naga Appani <[email protected]>
To: 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: Mon, 10 Nov 2025 11:43:33 +0530
Message-ID: <CAExHW5vDJ526OXv+Hk-=TxPoiL7RR+k+xSF2tyNqtaJHC5aoDQ@mail.gmail.com> (raw)
In-Reply-To: <CA+QeY+Aja_=j1EuY87L06KaPO4EJqqkS4B+Vg9AsWnGM1d_VRA@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>
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 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: <CAExHW5vDJ526OXv+Hk-=TxPoiL7RR+k+xSF2tyNqtaJHC5aoDQ@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