MIME-Version: 1.0
References: 
 <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> <aioMFYcZhLB6urla@paquier.xyz>
 <CABPTF7WSpNOYu84fjGH2t56BctRzVD7t8WqhgvML2DRh8Vtfog@mail.gmail.com>
 <aityn4rQkc7fv8qT@paquier.xyz>
In-Reply-To: <aityn4rQkc7fv8qT@paquier.xyz>
From: Xuneng Zhou <xunengzhou@gmail.com>
Date: Fri, 12 Jun 2026 14:28:23 +0800
Message-ID: 
 <CABPTF7V0CanEO71ZRoCAC3dva05kd2-hU0W6HDKqON=B78TFhA@mail.gmail.com>
Subject: Re: t/035_standby_logical_decoding.pl might fail on attempt to read
 wrong timeline
To: Michael Paquier <michael@paquier.xyz>
Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>,
	"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/CABPTF7V0CanEO71ZRoCAC3dva05kd2-hU0W6HDKqON%3DB78TFhA%40mail.gmail.com>
Precedence: bulk

On Fri, Jun 12, 2026 at 10:44=E2=80=AFAM Michael Paquier <michael@paquier.x=
yz> wrote:
>
> On Fri, Jun 12, 2026 at 08:57:05AM +0800, Xuneng Zhou wrote:
> > On Thu, Jun 11, 2026 at 9:15=E2=80=AFAM Michael Paquier <michael@paquie=
r.xyz> wrote:
> >> 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:
> >> - walinspect.
> >> - Slot advance.
> >> - Slot creation (?), but it feels even narrower.
> >
> > Yeah, it is used for two-phase commit as well. The usage of it is
> > broader than I observed before. Repack worker also make use of it.
>
> Repack workers cannot work on standbys, and for 2PC files we have the
> guarantee of a file on disk if the WAL is gone, so they should be
> basically irrelevant here.  That's why I did not mention them.  :)

Thanks for the clarification.

> Everything's now done.  I was pondering about v14 and v15 for a bit
> for the second patch regarding pg_walinspect (or slot operations), but
> I could not get excited about these branches.  pg_walinspect is less
> used, and slots have much more uses on standbys since v16~, so
> expanding that further down feels meh.

Making sense to me. This looks like a hard-to-hit issue on HEAD. The
likelihood of encountering it and the severity of damage caused by it
in those branches are expected to be even smaller.

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