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 e47084b7-d17b-4017-a530-05ec7d8d8385@iki.fi
Whole thread
In response to [Patch] Fix pg_get_multixact_stats() over-reporting members on a hot standby  (Naga Appani <nagnrik@gmail.com>)
Responses Re: [Patch] Fix pg_get_multixact_stats() over-reporting members on a hot standby
List pgsql-hackers
On 21/09/2026 07:43, Naga Appani wrote:
> I did not add the start-of-recovery initialization from the control file
> Heikki mentioned [0]. With only the redo-path update there is still a short
> window before the first truncation record is replayed where oldestOffset
> reads 0. Handling that at startup needs the value without the
> find_multixact_start() lookup, which asserts finishedStartup, so I left it
> out for now.

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.

- Heikki




pgsql-hackers by date:

Previous
From: Bertrand Drouvot
Date:
Subject: Re: Redesign per-backend statistics
Next
From: wenhui qiu
Date:
Subject: Re: Assert failure in get_baserel_parampathinfo with lateral UNION ALL