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

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