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

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message wenhui qiu 2026-09-21 07:30:35 Re: Assert failure in get_baserel_parampathinfo with lateral UNION ALL
Previous Message Bertrand Drouvot 2026-09-21 07:15:44 Re: Redesign per-backend statistics