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>
 <CAExHW5vDJ526OXv+Hk-=TxPoiL7RR+k+xSF2tyNqtaJHC5aoDQ@mail.gmail.com>
In-Reply-To: 
 <CAExHW5vDJ526OXv+Hk-=TxPoiL7RR+k+xSF2tyNqtaJHC5aoDQ@mail.gmail.com>
From: Naga Appani <nagnrik@gmail.com>
Date: Sat, 6 Dec 2025 11:52:57 -0600
Message-ID: 
 <CA+QeY+CF2q2M51k5t4rZZ2SNeEq8ORf3Dr8T1+jm72VsHRJfjw@mail.gmail.com>
Subject: Re: [Proposal] Expose internal MultiXact member count function for
 efficient monitoring
To: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: Tomas Vondra <tomas@vondra.me>, 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/CA%2BQeY%2BCF2q2M51k5t4rZZ2SNeEq8ORf3Dr8T1%2Bjm72VsHRJfjw%40mail.gmail.com>
Precedence: bulk

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=E2=80=AFAM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
>
> On Wed, Nov 5, 2025 at 6:43=E2=80=AFAM Naga Appani <nagnrik@gmail.com> wr=
ote:
> >
> > 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 ru=
ntime
> > behavior, both approaches seem to run into limitations when trying to d=
erive a
> > =E2=80=9Cremaining members=E2=80=9D 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=E2=80=99s segment recalculation
> >
> > Without accounting for those, the derived numbers behaved inconsistentl=
y across
> > tests, sometimes staying at 0 until a large jump, and in other cases in=
creasing
> > between exhaustion cycles. This seems broadly consistent with your conc=
ern that
> > simple arithmetic on these counters does not match how the backend dete=
rmines
> > wraparound risk.
> >
> > To be clear, this interpretation is based only on what I could infer fr=
om the
> > code and testing, and I may not be capturing the entire picture. But fr=
om what I
> > observed, a user-visible =E2=80=9Cremaining members=E2=80=9D metric doe=
s 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> wr=
ote:
> >
> > 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