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

On Wed, Jun 10, 2026 at 05:28:00PM +0000, Bertrand Drouvot wrote:
> On Wed, Jun 10, 2026 at 04:36:14PM +0800, Xuneng Zhou wrote:
>> The
>> essential thing is just to ensure that the startup remains paused
>> until decoding output is observed.
> 
> Right, thanks for confirming. That's exactly what v2 is doing.

I have looked at this thread, and my first impression was that this
could be a data integrity issue while decoding changes due to the
transient errors one could see across the promotion requests.

But it's less severe than I thought initially: we have an availability
problem here, down to v16, with a correct recovery possible once the
promotion request has completed.  That could be indeed surprising for
users that have HA setups with standbys doing logical decoding..  The
SQL function path is less worrying to me, there are as far as I know
few users of it compared to the "native" path with sync workers.

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.

With two items dealt with on this thread for these two callback paths
changed, moving on the part related to physical replication into its
own thread would be better.  This requires an entirely different
analysis and a different lookup.

The backpatch of PG16 is straight-forward and adding
GetWALInsertionTimeLineIfSet() down there does not look like an issue.
Not having any tests in v16 feels sad, but that's life.  It does not
prevent addressing the availability issue on this branch.

I'll go take it up from here.
--
Michael