Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\))
Subject: Re: BUG #19490: Streaming standby on 16.14 stops applying WAL on
 MultiXactOffsetSLRU when primary is 16.8
From: Andrey Borodin <x4mmm@yandex-team.ru>
In-Reply-To: <d52502b3-48cf-4eb4-a966-a0a46a4637de@iki.fi>
Date: Tue, 26 May 2026 23:29:58 +0500
Cc: Michael Paquier <michael@paquier.xyz>,
 Ayush Tiwari <ayushtiwari.slg01@gmail.com>,
 Radim Marek <radim@boringsql.com>,
 Marko Tiikkaja <marko@joh.to>,
 PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <90F2A05B-FEEB-4695-87ED-32F53C6AC097@yandex-team.ru>
References: <19490-9c59c6a583513b99@postgresql.org>
 <46FE61C9-F273-45FD-BED7-0F8CDA6EB992@yandex-team.ru>
 <CAL9smLBMxKBCmsA9UGcmf93bT2_MsZ+POH-oHREuwKdmMU7jfQ@mail.gmail.com>
 <46DB3CAB-EA1C-41A5-9D6D-5F913A2AAF66@yandex-team.ru>
 <CAJgoLkJfFgL-V+pYB7=R81AbURTE6sMhzVHDQDhVGnfXRSJ9Wg@mail.gmail.com>
 <CAJgoLkKCu0wCwPQZSo5no=XATU-4LMK4QfKBwV928o2uKcxe=g@mail.gmail.com>
 <CAJTYsWU6tdEvVh4YKLxz7+amZ7+Wb7_s-FBjsMMeLNj1fKeSNg@mail.gmail.com>
 <ahVTk8HKRPcz4iZ-@paquier.xyz>
 <CAJTYsWWXvbBJe+WYJZcnoSTyVz9vk5ro3x2qAq_uvXvK2KwaMQ@mail.gmail.com>
 <AC1516B2-2E78-4C70-8A6E-2966F01A1058@yandex-team.ru>
 <ahVnc8-EjV6WlM5-@paquier.xyz>
 <9DF05C0C-D165-4821-80C2-FFAF47C07FF4@yandex-team.ru>
 <d52502b3-48cf-4eb4-a966-a0a46a4637de@iki.fi>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Archived-At: 
 <https://www.postgresql.org/message-id/90F2A05B-FEEB-4695-87ED-32F53C6AC097%40yandex-team.ru>
Precedence: bulk


> On 26 May 2026, at 17:28, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>=20
> looks correct

I tested that change as follows.

Setted up REL_16_0 as primary, REL_16_STABLE as standby.

Generate multixacts in a single session using savepoints:

BEGIN;
SELECT * FROM t WHERE i =3D 1 FOR NO KEY UPDATE;
-- repeat 2500 times:
SAVEPOINT a; SELECT * FROM t WHERE i =3D 1 FOR UPDATE; ROLLBACK TO a;
COMMIT;

Each iteration creates a new MultiXactId. 2500 iterations cross the SLRU =
page
boundary at multixact 2048 with some spare multis (we'll pickle the =
excess ones in
jars when all is fixed, toying with 2048 wasted dev cycles for no =
reason).

Test:
0. Run the workload on REL_16_0 primary (2500 multixacts, crossing page =
0->1)
1. Take pg_basebackup
2. Run the workload again (2500 more, crossing page 1->2)
3. Start the standby

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.

I packaged this test into a buildfarm module (TestReplayXversion) [0] =
that
builds REL_x_0 and runs this check on REL_x_STABLE build. It reproduces =
the deadlock
on 14, 15, and 16; 17 and 18 pass. Currently I'm struggling to inject =
regress WAL trace
into it, not working so far. On a bright side - I managed to get PR =
number 42 in buildfarm
client repo.


Best regards, Andrey Borodin.

[0] https://github.com/PGBuildFarm/client-code/pull/42