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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: Naga Appani <nagnrik(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Noah Misch <noah(at)leadboat(dot)com>
Subject: Re: [Patch] Fix pg_get_multixact_stats() over-reporting members on a hot standby
Date: 2026-09-21 07:30:59
Message-ID: arDdM0MrPGgFhNpQ@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chao Li 2026-09-21 07:35:03 Re: psql: avoid over-reading unterminated prompt escapes
Previous Message wenhui qiu 2026-09-21 07:30:35 Re: Assert failure in get_baserel_parampathinfo with lateral UNION ALL