public inbox for [email protected]
help / color / mirror / Atom feedFrom: Ashutosh Bapat <[email protected]>
To: Naga Appani <[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: Mon, 8 Dec 2025 10:10:16 +0530
Message-ID: <CAExHW5shToKbeiw1eRGeiSyVeCYZUJyw2KUtBKYFn0J3dCGzbA@mail.gmail.com> (raw)
In-Reply-To: <CA+QeY+CF2q2M51k5t4rZZ2SNeEq8ORf3Dr8T1+jm72VsHRJfjw@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>
<CA+QeY+CF2q2M51k5t4rZZ2SNeEq8ORf3Dr8T1+jm72VsHRJfjw@mail.gmail.com>
On Sat, Dec 6, 2025 at 11:23 PM Naga Appani <[email protected]> wrote:
>
> 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.
The patch at [1] changes the function used to fetch mxid related
information. With that we will get rid of awkwardness around
non-availability of the statistics. It's better to wait for those
changes to get committed before moving this forward.
--
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: <CAExHW5shToKbeiw1eRGeiSyVeCYZUJyw2KUtBKYFn0J3dCGzbA@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