Re: t/035_standby_logical_decoding.pl might fail on attempt to read wrong timeline - Mailing list pgsql-hackers

From Bertrand Drouvot
Subject Re: t/035_standby_logical_decoding.pl might fail on attempt to read wrong timeline
Date
Msg-id aiP/X1FThlZRCFiN@bdtpg
Whole thread
In response to t/035_standby_logical_decoding.pl might fail on attempt to read wrong timeline  (Alexander Lakhin <exclusion@gmail.com>)
Responses Re: t/035_standby_logical_decoding.pl might fail on attempt to read wrong timeline
List pgsql-hackers
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.

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: "Zhijie Hou (Fujitsu)"
Date:
Subject: RE: Fix race in ReplicationSlotRelease for ephemeral slots
Next
From: Nitin Motiani
Date:
Subject: Re: [PATCH] Fix for bug #19474: LIKE fails to match literal backslashes with nondeterministic collations