Date: Sat, 6 Jun 2026 11:07:11 +0000
From: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: Alexander Lakhin <exclusion@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: t/035_standby_logical_decoding.pl might fail on attempt to read
 wrong timeline
Message-ID: <aiP/X1FThlZRCFiN@bdtpg>
References: <7daef094-abf3-4672-bc23-3df4763b16a3@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <7daef094-abf3-4672-bc23-3df4763b16a3@gmail.com>
Archived-At: <https://www.postgresql.org/message-id/aiP/X1FThlZRCFiN%40bdtpg>
Precedence: bulk

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