Horton

Re: t/035_standby_logical_decoding.pl might fail on attempt to read wrong timeline

Xuneng Zhou <xunengzhou@gmail.com>

View thread View on postgr.es
From: Xuneng Zhou <xunengzhou@gmail.com>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: Alexander Lakhin <exclusion@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2026-06-06T12:56:10Z
Lists: pgsql-hackers 
Hi Bertrand,

On Sat, Jun 6, 2026 at 7:07 PM Bertrand Drouvot
<bertranddrouvot.pg@gmail.com> wrote:
>
> Hi Alexander,
>
> On Sat, Jun 06, 2026 at 12:00:00PM +0300, Alexander Lakhin wrote:
> > Hello hackers,
> >
> > That is, walsender requested WAL segment for timeline 1, while in a
> > successful run, it reads WAL for timeline 2.
> >
> > I've managed to reproduce this failure with:
>
> Thanks for the report and the repro!
>
> > As far as I can see, the timeline is chosen in logical_read_xlog_page()
> > depending on the recovery state:
> >         am_cascading_walsender = RecoveryInProgress();
> >
> >         if (am_cascading_walsender)
> >                 GetXLogReplayRecPtr(&currTLI);
> >         else
> >                 currTLI = GetWALInsertionTimeLine();
>
> Yeah, it looks like there is a race condition here. I think we should check if
> the insertion timeline has already been set (like the walsummarizer is doing).
>
> I'll work on a fix early next week.

This looks like the right direction to fix. We may want to apply
similar logic to read_local_xlog_page_guts as well. Although the
failure is reported in walsender, SQL logical decoding uses the local
WAL reader and has the same recovery/TLI pattern.

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

Commits

  1. Fix second race with timeline selection during promotion

  2. Remove TAP test for timeline lookup race with logical decoding on standbys

  3. Fix race with timeline selection in logical decoding during promotion

  4. Backport GetWALInsertionTimeLineIfSet()

  5. TAP test for logical decoding on standby