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

On Tue, Jun 9, 2026 at 7:01 PM Bertrand Drouvot
<bertranddrouvot(dot)pg(at)gmail(dot)com> wrote:
>
> Hi,
>
> On Tue, Jun 09, 2026 at 03:49:50PM +0800, Xuneng Zhou wrote:
> > On Mon, Jun 8, 2026 at 10:34 PM Xuneng Zhou <xunengzhou(at)gmail(dot)com> wrote:
> > >
> > > On Mon, Jun 8, 2026 at 10:22 PM Bertrand Drouvot
> > > <bertranddrouvot(dot)pg(at)gmail(dot)com> wrote:
> >
> > I've readed through the patch set. They look good overall.
>
> Thanks for the review!
>
> > Here're
> > some comments on them:
> >
> > 1) In the commit messages and comments for all four patches, the
> > reason why the target WAL segment cannot be found on the old timeline
> > is described as follows:
> >
> > "old timeline WAL segments have already been removed or
> > recycled by RemoveNonParentXlogFiles() in CleanupAfterArchiveRecovery()."
> >
> > Is mentioning the 'remove' case only a bit narrow?
> >
> > The timeline-selection comment says this explicitly:
> > "there's no guarantee the old segment will still exist. It may have been
> > deleted or renamed with a .partial suffix"
> >
> > How about phrasing it like:
> > old timeline WAL files may have been removed, recycled, or renamed to .partial.
> >
> > After running the reproducer provided by Hayato-san, the standby’s
> > pg_wal directory looked like this following the failure:
> > 000000010000000000000003.partial
> > 00000002.history
> > 000000020000000000000003
> > 000000020000000000000004
> >
> > So in this repro, the requested file:
> >
> > 000000010000000000000003
> >
> > was not unlinked as a regular "removed" file. It had been renamed to:
> >
> > 000000010000000000000003.partial
> >
> > but the log says this explicitly:
> > ERROR: requested WAL segment 000000010000000000000003 has already been removed
> >
> > It appears inconsistent to me...
>
> I'm not sure. The error message says "has already been removed" and the commit
> messages and comments says"removed or recycled": those are consistent with the
> error message. We're describing the symptom from the walsender's perspective,
> not the exact file operation that caused it.
> > 2) Injection points in tests 0002 and 0004
> >
> > It does not prove this:
> > walsender has reached logical_read_xlog_page() while startup is paused
> >
> > 3) Stricter synchronization point in both tests
> > Both tests use this condition "active_pid IS NOT NULL" for
> > synchronization at the walsender side. However, it only proves that
> > pg_recvlogical has connected walsender has acquired the logical slot,
> > not necessarily the walsender is paused after acquiring the slot and
> > before the promotion window is set. There are several potential states
> > for walsender in this condition:
> >
> > walsender is just after ReplicationSlotAcquire()
> > it has called XLogBeginRead()
> > it is already inside logical_read_xlog_page()
> > it already opened the WAL segment
> > it already failed or succeeded
> >
> > The test cannot distinguish those states reliably.
> >
> > So we may still need another injection point for synchronization at
> > the walsender side
>
> I agree that with v1 the test could have been fragile. It's fixed in v2 without
> having to add a second injection point. All we have to do is to ensure that
> the decoding occurred while the startup is paused on the new injection point.
>
> 0002 does that by starting the new walsender and doing the decoding while the
> startup is paused
> 0004 does that by ensuring the pre-connected session triggers the decoding while
> the startup is paused

That should work, and it’s cleverer. I was fixated on the idea that we
needed to start the walsender, pause it, suspend the startup process
to enter the promotion window, and then resume the walsender. The
essential thing is just to ensure that the startup remains paused
until decoding output is observed.

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