Re: [Proposal] Expose internal MultiXact member count function for efficient monitoring - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [Proposal] Expose internal MultiXact member count function for efficient monitoring
Date
Msg-id yhtrliiq662vmhqy2xnbg67ezrucmwtfuuus2zcjvmwgmracux@2cqaioxnntwz
Whole thread
In response to Re: [Proposal] Expose internal MultiXact member count function for efficient monitoring  (Michael Paquier <michael@paquier.xyz>)
Responses Re: [Proposal] Expose internal MultiXact member count function for efficient monitoring
List pgsql-hackers
Hi,

On 2025-12-30 16:44:03 +0900, Michael Paquier wrote:
> On Mon, Dec 29, 2025 at 08:57:11PM -0600, Naga Appani wrote:
> > The oldest_multixact correctly advances to reflect the cleanup.
> > 
> > Thanks for adding the pg_read_all_stats privilege check!
> > 
> > I think this is ready for RFC.
> 
> Thanks for looking.  I have done an extra round of brush-up, then
> applied the set.  The buildfarm looks OK with it.

I didn't know where else to ask:

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?

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Kiran Kaki
Date:
Subject: Re: pg_walinspect: fix LSN validation messages and empty range handling
Next
From: Melanie Plageman
Date:
Subject: Re: Reduce cleanup lock contention on standby replay