Re: [Patch] Fix pg_get_multixact_stats() over-reporting members on a hot standby - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: [Patch] Fix pg_get_multixact_stats() over-reporting members on a hot standby
Date
Msg-id 4050bb5e-e8d5-4cd1-a65c-3f710c807cb9@iki.fi
Whole thread
In response to Re: [Patch] Fix pg_get_multixact_stats() over-reporting members on a hot standby  (Michael Paquier <michael@paquier.xyz>)
Responses Re: [Patch] Fix pg_get_multixact_stats() over-reporting members on a hot standby
List pgsql-hackers
On 21/09/2026 10:30, Michael Paquier wrote:
> On Mon, Sep 21, 2026 at 10:19:47AM +0300, Heikki Linnakangas wrote:
>> Hmm, the window could be very long, there's no guarantee that you'll see a
>> MULTIXACT_TRUNCATE_ID record any time soon. And after restart, it'll revert
>> back to 0 again. If we can't get a reasonable value at startup, I wonder if
>> we should just always show NULL in the standby.
> 
> I'd like to think that we should just throw an ERROR in this case with
> a ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE, similarly to a lot of the
> WAL functions.  NULL is useful when for example using such a function
> with a JOIN on catalogs, when called for a lot of tuples, but that's
> not the case here.

That would disable pg_get_multixact_stats() in a standby altogether, but 
only the members-related fields (num_members, members_size) have this 
problem. So that would throw some babies out with the bathwater. It's a 
new function so we could still do it though, if that's what we want.

Another idea is to add the oldestOffset field to the control file. I 
actually find it a little weird that we don't have it there already. But 
I'm uncomfortable making that change so late in the release cycle, just 
for this function, in particular because it would require a catversion bump.

- Heikki




pgsql-hackers by date:

Previous
From: Dhruv Aron
Date:
Subject: Re: Restructured Shared Buffer Hash Table
Next
From: Nikolay Samokhvalov
Date:
Subject: Re: pg_*_advice: tsv load failure, etc.