Horton

Re: BUG #19490: Streaming standby on 16.14 stops applying WAL on MultiXactOffsetSLRU when primary is 16.8

Michael Paquier <michael@paquier.xyz>

View thread
From: Michael Paquier <michael@paquier.xyz>
To: Andrey Borodin <x4mmm@yandex-team.ru>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, Ayush Tiwari <ayushtiwari.slg01@gmail.com>, Radim Marek <radim@boringsql.com>, Marko Tiikkaja <marko@joh.to>, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2026-05-27T00:30:11Z
Lists: pgsql-hackers 
On Tue, May 26, 2026 at 11:29:58PM +0500, Andrey Borodin wrote:
> On 26 May 2026, at 17:28, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>> looks correct

Neither do I see an issue in doing the first steps of
RecordNewMultiXact() without holding the lock.  The consistency that
we get across all the stable branches after this patch makes the whole
logic neater.

> I observe:
> Without the change startup deadlocks.
> With the change standby catches up, the DEBUG1 message "next offsets page is not
> initialized, initializing it now" confirms the compat block fires correctly.

Cool, thanks for the patch and double-checking things, Andrey!  I did
not check the fix beyond a check-world (aka no cross-version replay
done here), but looking closely through the code I don't immediately
see why this would be wrong across the v14~v16 range.
--
Michael