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

Bertrand Drouvot <bertranddrouvot.pg@gmail.com>

From: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>

To: Alexander Lakhin <exclusion@gmail.com>

Cc: pgsql-hackers <pgsql-hackers@postgresql.org>

Date: 2026-06-06T11:07:11Z

Lists: 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

Commits

Fix second race with timeline selection during promotion
- d9b49e5b4fc2 16 (unreleased) landed
- ab5334d8bfa2 17 (unreleased) landed
- 4bff3aa51c19 18 (unreleased) landed
- a8ee70bd5e00 19 (unreleased) landed
Remove TAP test for timeline lookup race with logical decoding on standbys
- c011d5b65457 17 (unreleased) landed
Fix race with timeline selection in logical decoding during promotion
- 8cd687c44b62 16 (unreleased) landed
- 16b89ff04839 17 (unreleased) landed
- b4bd1385043c 18 (unreleased) landed
- eb4e7224a1c6 19 (unreleased) landed
Backport GetWALInsertionTimeLineIfSet()
- 2a04624daa32 16 (unreleased) landed
TAP test for logical decoding on standby
- fcd77d53217b 16.0 cited