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

From Michael Paquier
Subject Re: [Patch] Fix pg_get_multixact_stats() over-reporting members on a hot standby
Date
Msg-id arDdM0MrPGgFhNpQ@paquier.xyz
Whole thread
In response to Re: [Patch] Fix pg_get_multixact_stats() over-reporting members on a hot standby  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: [Patch] Fix pg_get_multixact_stats() over-reporting members on a hot standby
List pgsql-hackers
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.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: wenhui qiu
Date:
Subject: Re: Assert failure in get_baserel_parampathinfo with lateral UNION ALL
Next
From: Chao Li
Date:
Subject: Re: psql: avoid over-reading unterminated prompt escapes