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

From: Sami Imseih <samimseih(dot)pg(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Naga Appani <nagnrik(at)gmail(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Tomas Vondra <tomas(at)vondra(dot)me>, Xuneng Zhou <xunengzhou(at)gmail(dot)com>, torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>, Kirill Reshke <reshkekirill(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [Proposal] Expose internal MultiXact member count function for efficient monitoring
Date: 2026-09-21 23:22:35
Message-ID: CAN12+YKc278ayOBzF4Rbosrz=5QzRJ7t7bHff-FKiJbbvgwFzg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> > Why is pg_get_multixact_stats() called _stats? From what I can tell it doesn't
> > return anything stats like? What it returns is more like the *state* of the
> > subsystem?
>
> Hmm. Perhaps pg_get_multixact_state() then? We still have time to
> adjust that before the release. If somebody has a better idea of
> name, please feel free.

I guess pg_get_multixact_usage() sounds better to me and it matches the
code comment:

/*
* pg_get_multixact_stats
*
* Returns statistics about current multixact usage.
*/

--
Sami

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message shihao zhong 2026-09-21 23:27:01 Re: REPACK enhancements
Previous Message Michael Paquier 2026-09-21 23:01:25 Re: [Proposal] Expose internal MultiXact member count function for efficient monitoring