Re: [Proposal] Expose internal MultiXact member count function for efficient monitoring

Thank you, Ashutosh!

On Sun, Dec 7, 2025 at 10:40 PM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
> 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.

Following the upstream change from Heikki's patch [0], I've updated
the patch (v12) to align with the new behavior.

Code changes:
- GetMultiXactInfo() now returns void, so the conditional checks and NULL
  handling have been removed.
- MultiXactOffset is now 64-bit; updated the code to use Int64GetDatum()
  for member counts.
- Switched to using MULTIXACT_MEMBERGROUP_SIZE and
  MULTIXACT_MEMBERS_PER_MEMBERGROUP from multixact_internal.h instead of
  hardcoded calculations.

Documentation changes:
- Removed the NULL-return discussion from func-info.sgml, as the
  statistics are now always available.
- Updated maintenance.sgml to clarify that exceeding the historical
  2^32 member limit no longer causes wraparound, but instead triggers
  more aggressive vacuum activity for disk space management.

I validated the behavior before and after cleanup.
The function correctly reports current usage (beyond the old limits) and
resets once multixacts are removed:

postgres=# SELECT num_mxids, num_members, pg_size_pretty(members_size)
AS members_size, oldest_multixact FROM pg_get_multixact_stats();
-[ RECORD 1 ]------------------
num_mxids        | 267969541
num_members      | 9469693355
members_size     | 44 GB
oldest_multixact | 2

postgres=# SELECT pg_terminate_backend(27222);
pg_terminate_backend
----------------------
t

postgres=# SELECT num_mxids, num_members, pg_size_pretty(members_size)
AS members_size, oldest_multixact FROM pg_get_multixact_stats();
-[ RECORD 1 ]------------------
num_mxids        | 0
num_members      | 0
members_size     | 0 bytes
oldest_multixact | 267969543

The updated patch is attached.

Ref:
[0] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=bd8d9c9bdfa0c2168bb37edca6fa88168cacbbaa

Regards,
Naga