MIME-Version: 1.0
References: <7daef094-abf3-4672-bc23-3df4763b16a3@gmail.com>
 <aiP/X1FThlZRCFiN@bdtpg>
 <OS9PR01MB1214908BA67A7811BD6281208F51C2@OS9PR01MB12149.jpnprd01.prod.outlook.com>
 <CABPTF7WmLKOJcSPod7zT2hynUFQcUs0VoQyR-p=XFsafvmGm7g@mail.gmail.com>
 <CABPTF7U_B9pdC563fFONQLX_FXCZtxZgM+jN9snzMVg9b9MRfg@mail.gmail.com>
 <aibQB2f9h3nYeg/2@bdtpg>
In-Reply-To: <aibQB2f9h3nYeg/2@bdtpg>
From: Xuneng Zhou <xunengzhou@gmail.com>
Date: Mon, 8 Jun 2026 22:34:27 +0800
Message-ID: 
 <CABPTF7XGDgnB97fBUQb+Tm=5NnAzS1iKTWcJTePpGinL1ZAxWQ@mail.gmail.com>
Subject: Re: t/035_standby_logical_decoding.pl might fail on attempt to read
 wrong timeline
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>,
 Alexander Lakhin <exclusion@gmail.com>,
	pgsql-hackers <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CABPTF7XGDgnB97fBUQb%2BTm%3D5NnAzS1iKTWcJTePpGinL1ZAxWQ%40mail.gmail.com>
Precedence: bulk

On Mon, Jun 8, 2026 at 10:22=E2=80=AFPM Bertrand Drouvot
<bertranddrouvot.pg@gmail.com> wrote:
>
> Hi,
>
> On Mon, Jun 08, 2026 at 09:00:17PM +0800, Xuneng Zhou wrote:
> > I tweaked the reproducer based on the theory outlined above. The main
> > changes from the original reproducer are:
> >
> > 1) blocks at logical-walsender-after-slot-acquire in walsender.c,
> > before the decoding context is created and before the reader starts
> > from restart_lsn, matching the delay set by Alexander
>
> > 2) Forces the first read to occur during promotion. It inserts rows
> > 1..4, waits for replay, starts promotion with pg_promote(false), holds
> > startup at startup-logical-decoding-status-change-end-of-recovery,
> > then wakes the walsender.
>
> Yeah, so this existing startup-logical-decoding-status-change-end-of-reco=
very
> injection point already exists in the code tree and is also called after
> CleanupAfterArchiveRecovery() and before RECOVERY_STATE_DONE change in
> StartupXLOG().
>
> So this is the same window as the new injection point that was added in t=
he new
> tests in v1-0002 shared up-thread [1].
>
> That said, I think I prefer the v1-0002 shared up-thread [1] approach for=
 the
> tests as:
>
> - the injection point name clearly describes the tested condition
> - no new injection point is added in walsender.c (it pauses startup mid-p=
romotion
> and lets the walsender connect)
> - the test relies on one injection point (not two)
>
> [1]: https://postgr.es/m/aiaBtENl7tTf2MM8%40bdtpg
>

Thanks for the clarification. I haven't reviewed the patch set other
than applying the patch 1 yet, but I plan to do so tomorrow.

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