Feedback-ID: i0fe9450f:Fastmail
Date: Thu, 11 Jun 2026 10:15:01 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: Xuneng Zhou <xunengzhou@gmail.com>,
	"Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>,
	Alexander Lakhin <exclusion@gmail.com>,
	pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: t/035_standby_logical_decoding.pl might fail on attempt to read
 wrong timeline
Message-ID: <aioMFYcZhLB6urla@paquier.xyz>
References: <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>
 <CABPTF7XGDgnB97fBUQb+Tm=5NnAzS1iKTWcJTePpGinL1ZAxWQ@mail.gmail.com>
 <CABPTF7VovNWnH=dG_A=e6xkMYt11ubbj935Ymfky55cXcWcrrA@mail.gmail.com>
 <aifyiJG3uiJzCYTB@bdtpg>
 <CABPTF7XAb7ExE-7qSsKgSw3K0hfsNPzXuupQ1aJ8zXOgZ4tPNw@mail.gmail.com>
 <aimeoNYE93VLiQHt@bdtpg>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="NLQa8WhYOPx2iTsi"
Content-Disposition: inline
In-Reply-To: <aimeoNYE93VLiQHt@bdtpg>
Archived-At: 
 <https://www.postgresql.org/message-id/aioMFYcZhLB6urla%40paquier.xyz>
Precedence: bulk


--NLQa8WhYOPx2iTsi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 10, 2026 at 05:28:00PM +0000, Bertrand Drouvot wrote:
> On Wed, Jun 10, 2026 at 04:36:14PM +0800, Xuneng Zhou wrote:
>> The
>> essential thing is just to ensure that the startup remains paused
>> until decoding output is observed.
>=20
> Right, thanks for confirming. That's exactly what v2 is doing.

I have looked at this thread, and my first impression was that this
could be a data integrity issue while decoding changes due to the
transient errors one could see across the promotion requests.

But it's less severe than I thought initially: we have an availability
problem here, down to v16, with a correct recovery possible once the
promotion request has completed.  That could be indeed surprising for
users that have HA setups with standbys doing logical decoding..  The
SQL function path is less worrying to me, there are as far as I know
few users of it compared to the "native" path with sync workers.

read_local_xlog_page_guts() does not only impact SQL-callable logirep
functions, even it is the spot that should be hit most of the time
(again, the RecoveryInProgress() vs promotion window is super narrow).
At quick glance, things are:=20
- walinspect.
- Slot advance.
- Slot creation (?), but it feels even narrower.

With two items dealt with on this thread for these two callback paths
changed, moving on the part related to physical replication into its
own thread would be better.  This requires an entirely different
analysis and a different lookup.

The backpatch of PG16 is straight-forward and adding
GetWALInsertionTimeLineIfSet() down there does not look like an issue.
Not having any tests in v16 feels sad, but that's life.  It does not
prevent addressing the availability issue on this branch.

I'll go take it up from here.
--
Michael

--NLQa8WhYOPx2iTsi
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmoqDBQACgkQnvQgOdby
QH03EQ//U+2CHzSr9npXsYpoFsCSvWnsw5AAhBGbjvlAcdb5/Z+jPnckN7slItmQ
FhH5Bs73ILlchOy8hSqlgkvNIcMXq39AjoXIL+QkaxfaGjHSgq2mP/v0CgOFiD37
hqKv6OTPhSzheU2YSOcB2JyIv8PGkLFPMigc0IBEtcX6Y66DPgQ+6M//yIEJ57jE
1ijcJolnPzXY+zsrlrusjCG60aZCYL2MqnIJIx7dGCRRoTa8cRg1pvUaOedJOK5X
LhZt8QKKwWeF79+YZ5NbM3rybqWzN8EiLzU+kMHSrNItD1Dh++84X2F4SY1oXpNG
Ks3uPt2RxEkJeWrAS1Zddx8rKvcPWB964C6OmymZLxN4LN/7PpE6v/GosSMSMNa8
WigOKpfcegGM/ZtjKa65QKcXvFhnecF99YvLGDznfUqJl8yCxzgQgvwfTtpAw8xT
hMlxElKhEPP2SRGoyoeKQXfeRvTyT3eQNydpiQE3UZ0z/1MmfiGYGKZ2hHuxcIV+
eUfhD9p/7sJHJ+g5pfR5mXCKoc/Pe5GT9G7f9/4dhqWm51CP1BjdudOU/ic/CZ9U
r5/L4/vLUAmPw9bb/uj8U3y8pJp+6MUaAocWd0AujAafTRE3FQdP2kYVbslAo2dV
tvK2bNW5QnXZQ3Ilpmc1JNsMxLm9teR6FMaX56Z+r05RMBhe+8s=
=g0Mg
-----END PGP SIGNATURE-----

--NLQa8WhYOPx2iTsi--