Re: test: avoid redundant standby catchup in 049_wait_for_lsn

On Sat, Nov 14, 2026 at 7:00 PM Alexander Korotkov <aekorotkov(at)gmail(dot)com> wrote:
>
> On Sat, Nov 14, 2026 at 7:53 AM Xuneng Zhou <xunengzhou(at)gmail(dot)com> wrote:
> > Thanks for looking into this!
> >
> > > Thanks to Xuneng for investigation, and thanks to Jobin for the
> > > additional report.
> > >
> > > I actually don't like idea of new pg_current_wal_insert_end_lsn()
> > > function for the following reasons:
> > > 1) We should fix this for PG 19. But it's RC already, we should avoid
> > > catversion bump if possible.
> > > 2) There is probability that users would still use
> > > pg_current_wal_insert_lsn() and hit to this problem.
> > > 3) Additional compexity.
> >
> > Makes sense to me. I did not consider the potential issue of early-adapters..
> >
> > > I suggest that WAIT FOR LSN can normalize the LSN to be waited on its
> > > side. There is no point one should wait for the LSN inside the page
> > > header. The attached patch implements that. Optinions?
> >
> > Normalizing the LSN in ExecWaitStmt() before invoking WaitForLSN()
> > seems good to me. It adds bits of extra cost which seems small and the
> > WAIT does not sit in a hot path.
> >
> > The new test looks like it will fail on 32-bit systems, since it
> > assumes 64-bit record and page header sizes. I'm wondering if we could
> > use pg_switch_wal() instead? After a WAL switch, the insert LSN is
> > just past the first segment page header, so size arithmetic is not
> > needed. This only covers the long-header case, not ordinary pages, but
> > that seems fine, since the mapping logic stays the same.
>
> Good point, thank you!
> Please, check v2 where pg_switch_wal() is used.
>

Thanks for updating the patch. In my testing, it exercised the bug
well. I made a minor adjustment to the patch to stop the standby at
the boundary before checking, so an unrelated background WAL would not
succeed the test accidently. If this seems unnecessary, please feel
free to ignore it. Otherwise, v2 looks good to me.

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