Re: test: avoid redundant standby catchup in 049_wait_for_lsn

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.

------
Regards,
Alexander Korotkov
Supabase