MIME-Version: 1.0
References: 
 <CABPTF7Xs-64GQNjmbimZNhj2YSKbBny+evz6=cp3X2fkJS+vMQ@mail.gmail.com>
 <CABPTF7Ub=w7CRxi3sNv8oMGMh4hCqUTohuiTuP9Y1DpxRuFtRQ@mail.gmail.com>
 <CAPpHfduJKv9-R2HcpyX9RNgteLL0M1MPS1No1WLnTsegsbG4MQ@mail.gmail.com>
 <CABPTF7WWxgAAr5fT9TFciU+PzeRpC3Dp7SO60AV9XWx561TNKA@mail.gmail.com>
 <CABPTF7X0n=R50z2fBpj3EbYYz04Ab0-DHJa+JfoAEny62QmUdg@mail.gmail.com>
 <CABPTF7U+SUnJX_woQYGe==R9Oz+-V6X0VO2stBLPGfJmH_LEhw@mail.gmail.com>
 <CABPTF7UcuVD0L-X=jZFfeygjPaZWWkVRwtWOaJw2tcXbEN2xsA@mail.gmail.com>
 <CABPTF7Wdq6KbvC3EhLX3Pz=ODCCPEX7qVQ+E=cokkB91an2E-A@mail.gmail.com>
 <CAPpHfdv_BS7csGyg_=pPanRQM9Sf6_wBWNGdVzJRAv0U4eH9cg@mail.gmail.com>
 <CAPpHfds7oSCbZqob7ytT_Lso8fv-NW8LnedUTE4Krde+3rkJeA@mail.gmail.com>
 <CABPTF7WiDtWCR82geyaaaCRV9UiPR5YUHRNDysD_7Ltr1ymfug@mail.gmail.com>
 <CABPTF7Um7oRKBYmek_3gfbaMg5DLzHZmAX-GEacHASfD34xo5g@mail.gmail.com>
 <CABPTF7V-E_e3kQ2vtwUz6Jy7u-8_YeUT0SDoAbu7EKPgNp=ndA@mail.gmail.com>
 <CAPpHfdtNiSqQCu+YtTYcc+K4q9FwtZuAtQ5Qs+KoaZZM4QyYTA@mail.gmail.com>
 <63f6abc9-c0ae-465d-a4e6-667eca6ea008@gmail.com>
In-Reply-To: <63f6abc9-c0ae-465d-a4e6-667eca6ea008@gmail.com>
From: Xuneng Zhou <xunengzhou@gmail.com>
Date: Tue, 19 May 2026 20:30:10 -0700
Message-ID: 
 <CABPTF7V=q+OCSHLMV0v78UU=pz6b7rC81vJ5+XKnVkfAebyEwA@mail.gmail.com>
Subject: Re: Implement waiting for wal lsn replay: reloaded
To: Alexander Lakhin <exclusion@gmail.com>
Cc: Alexander Korotkov <aekorotkov@gmail.com>,
 Heikki Linnakangas <hlinnaka@iki.fi>,
	Peter Eisentraut <peter@eisentraut.org>, Andres Freund <andres@anarazel.de>,
	Thomas Munro <thomas.munro@gmail.com>,
 =?UTF-8?Q?=C3=81lvaro_Herrera?= <alvherre@kurilemu.de>,
	Chao Li <li.evan.chao@gmail.com>,
 pgsql-hackers <pgsql-hackers@lists.postgresql.org>,
	Michael Paquier <michael@paquier.xyz>, jian he <jian.universality@gmail.com>,
	Tomas Vondra <tomas@vondra.me>, Yura Sokolov <y.sokolov@postgrespro.ru>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CABPTF7V%3Dq%2BOCSHLMV0v78UU%3Dpz6b7rC81vJ5%2BXKnVkfAebyEwA%40mail.gmail.com>
Precedence: bulk

Hi,

On Tue, May 19, 2026 at 1:00=E2=80=AFPM Alexander Lakhin <exclusion@gmail.c=
om> wrote:
>
> Hello Alexander and Xuneng,
>
> 06.04.2026 22:49, Alexander Korotkov wrote:
>
> Thank you, I've pushed your version of patchset.  I made two minor
> corrections for patch #2: mention default mode value in the header
> comment, and fallback to polling on has_wal_read_bug sparc64+ext4 bug.
>
>
> I discovered a new test failure, that is apparently caused by new
> wait_for_catchup() implementation [1]:
> [06:20:23.110](1.069s) not ok 8 - check that the slot state changes to "e=
xtended"
> [06:20:23.110](0.001s) #   Failed test 'check that the slot state changes=
 to "extended"'
> #   at /Users/ec2-user/bf/goldfish/HEAD/pgsql/src/test/recovery/t/019_rep=
lslot_limit.pl line 140.
> [06:20:23.111](0.000s) #          got: 'unreserved'
> #     expected: 'extended'
> [06:20:23.231](0.120s) not ok 9 - check that the slot state changes to "u=
nreserved"
> [06:20:23.231](0.000s) #   Failed test 'check that the slot state changes=
 to "unreserved"'
> #   at /Users/ec2-user/bf/goldfish/HEAD/pgsql/src/test/recovery/t/019_rep=
lslot_limit.pl line 152.
> [06:20:23.231](0.000s) #          got: 'lost|'
> #     expected: 'unreserved|t'
>
> I've managed to reproduce such failures with:
> diff --git a/src/backend/replication/walreceiver.c b/src/backend/replicat=
ion/walreceiver.c
> index 07eac07b9ce..493ce92674e 100644
> --- a/src/backend/replication/walreceiver.c
> +++ b/src/backend/replication/walreceiver.c
> @@ -1143,2 +1143,3 @@ XLogWalRcvSendReply(bool force, bool requestReply, =
bool checkApply)
>
> +pg_usleep(10000);
>      /* Get current timestamp. */
> diff --git a/src/backend/replication/walsender.c b/src/backend/replicatio=
n/walsender.c
> index 04aa770d981..19cda3a6b51 100644
> --- a/src/backend/replication/walsender.c
> +++ b/src/backend/replication/walsender.c
> @@ -2521,2 +2521,3 @@ ProcessStandbyReplyMessage(void)
>
> +pg_usleep(100000);
>      /* the caller already consumed the msgtype byte */
>
> Concretely, a loop:
> for i in {1..100}; do echo "ITERATION $i"; PROVE_TESTS=3D"t/019*" make -s=
 check -C src/test/recovery/ || break; done
> failed for me on iterations 2, 1, 7:
> ITERATION 7
> # +++ tap check in src/test/recovery +++
> t/019_replslot_limit.pl .. 8/?
> #   Failed test 'check that the slot state changes to "extended"'
> #   at t/019_replslot_limit.pl line 140.
> #          got: 'unreserved'
> #     expected: 'extended'
> t/019_replslot_limit.pl .. 26/? # Looks like you failed 1 test of 26.
> t/019_replslot_limit.pl .. Dubious, test returned 1 (wstat 256, 0x100)
> Failed 1/26 subtests
>
> With "WAIT FOR LSN" in wait_for_catchup() disabled, 100 iterations
> passed.
>
> Having extra logging added, I could see the key difference.
> Failed run:
> 2026-05-19 22:01:37.968 EEST client backend[3632148] 019_replslot_limit.p=
l LOG:  !!!GetWALAvailability| targetLSN: 0/016C0000, targetSeg: 22, oldest=
SlotSeg: 23, oldestSegMaxWalSize: 24, oldestSeg: 22
> 2026-05-19 22:01:37.968 EEST client backend[3632148] 019_replslot_limit.p=
l STATEMENT:  SELECT wal_status FROM pg_replication_slots WHERE slot_name =
=3D 'rep1'
> vs
> Successful run:
> 2026-05-19 22:04:18.102 EEST client backend[3633761] 019_replslot_limit.p=
l LOG:  !!!GetWALAvailability| targetLSN: 0/01700000, targetSeg: 23, oldest=
SlotSeg: 23, oldestSegMaxWalSize: 24, oldestSeg: 23
> 2026-05-19 22:04:18.102 EEST client backend[3633761] 019_replslot_limit.p=
l STATEMENT:  SELECT wal_status FROM pg_replication_slots WHERE slot_name =
=3D 'rep1'
>
> That is, with WAIT FOR LSN, primary in this test may advance
> slot->data.restart_lsn to the expected position after wait_for_catchup()
> returns.
>
> [1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=3Dgoldfish&dt=
=3D2026-05-13%2006%3A15%3A03

Thanks for reporting this issue.

I think this is related to the semantic change made earlier:
wait_for_catchup() now returns once the standby itself has reached the
target LSN, rather than waiting until the primary observes that
position via pg_stat_replication.

As a result, the primary may not yet have processed the standby
feedback needed to advance the slot's restart_lsn when
wait_for_catchup() returns.

Actually, I was aware of this semantic change and previously thought
it might be harmless. But this failure appears to disprove that. I'll
prepare a patch to fix this shortly.

--=20
Regards,
Xuneng Zhou
HighGo Software Co., Ltd.