On Sat, Nov 14, 2026 at 7:53 AM Xuneng Zhou <[email protected]> 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
v2-0001-Don-t-make-WAIT-FOR-LSN-depend-on-WAL-written-aft.patch
Description: Binary data
