Hi Alexander, 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. -- Regards, Xuneng Zhou HighGo Software Co., Ltd.
