MIME-Version: 1.0
References: 
 <CALdSSPi3Gh08NtcCn44uVeUAYGOT74sU6uei_06qUTa5rMK43g@mail.gmail.com>
 <CAExHW5s-StFwDpZBeiikvdnrBBr0s+2jJTZRv3Hh914T4C6Euw@mail.gmail.com>
 <CA+QeY+AmRSSJU8GKJ1uNVe2ps8GTONXpioYR7gEz91_prKR6sw@mail.gmail.com>
 <aKQac2ZrY4UWBORR@paquier.xyz>
 <CA+QeY+AwWV=g8z1eDE7OGHxKBer18gVER7nD+SnfhqLmiL7NOA@mail.gmail.com>
 <a5f1b794396a79d69ec70f5eaa7bdaf3@oss.nttdata.com>
 <d8a16af85820dddd9495442cc23111d0@oss.nttdata.com>
 <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>
 <29f9e7abc90c3a4fe4a44026141c0d6c@oss.nttdata.com>
 <CABPTF7WfTDdhZbHBgoqo=uGP_DZO-xO1bX5BfkwjgHK9jU+tOA@mail.gmail.com>
 <95850ce1-2d5e-4271-92ea-c2a02e36b303@vondra.me>
 <CA+QeY+Aja_=j1EuY87L06KaPO4EJqqkS4B+Vg9AsWnGM1d_VRA@mail.gmail.com>
In-Reply-To: 
 <CA+QeY+Aja_=j1EuY87L06KaPO4EJqqkS4B+Vg9AsWnGM1d_VRA@mail.gmail.com>
From: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Date: Mon, 10 Nov 2025 11:43:33 +0530
Message-ID: 
 <CAExHW5vDJ526OXv+Hk-=TxPoiL7RR+k+xSF2tyNqtaJHC5aoDQ@mail.gmail.com>
Subject: Re: [Proposal] Expose internal MultiXact member count function for
 efficient monitoring
To: Naga Appani <nagnrik@gmail.com>, Tomas Vondra <tomas@vondra.me>
Cc: Xuneng Zhou <xunengzhou@gmail.com>,
 torikoshia <torikoshia@oss.nttdata.com>,
	Michael Paquier <michael@paquier.xyz>,
 Kirill Reshke <reshkekirill@gmail.com>,
	pgsql-hackers@postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAExHW5vDJ526OXv%2BHk-%3DTxPoiL7RR%2Bk%2BxSF2tyNqtaJHC5aoDQ%40mail.gmail.com>
Precedence: bulk

On Wed, Nov 5, 2025 at 6:43=E2=80=AFAM Naga Appani <nagnrik@gmail.com> wrot=
e:
>
> Understanding
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Based on reading the relevant parts of multixact.c and observing the runt=
ime
> behavior, both approaches seem to run into limitations when trying to der=
ive a
> =E2=80=9Cremaining members=E2=80=9D value outside the backend. I may be m=
issing 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=E2=80=99s 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 incr=
easing
> between exhaustion cycles. This seems broadly consistent with your concer=
n that
> simple arithmetic on these counters does not match how the backend determ=
ines
> 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 =E2=80=9Cremaining members=E2=80=9D 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=E2=80=AFPM Tomas Vondra <tomas@vondra.me> wrot=
e:
>
> 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.

--=20
Best Wishes,
Ashutosh Bapat