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

On Mon, Sep 21, 2026 at 10:21 AM Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>
> 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
>
Thanks both for looking into this!

I lean toward ERROR over NULL, but not strongly.

AFAICS none of this is really actionable on a standby either way, since
freezing and vacuum are only actionable on the primary. An error seems
more honest than returning numbers that look real but don't drive any
decision. Could be missing a use case though, please let me know what you
think.

Thanks,
Naga