Hi!

On Thu, Oct 1, 2026 at 8:43 AM Jobin Augustine
<[email protected]> wrote:
>> Thanks. I had a general idea via your description and I'd like to know more 
>> about the use case. Please share it if you are ok with that.
>
> I am more than happy to share. The Rust program is pushed to my git repo and 
> path : 
> https://github.com/jobinau/pgscripts/tree/main/patroni/connection/waitforlsn
> There is a "repro" subdirectory with a file with instructions : 
> REPRODUCE_WITH_WAITFORLSN.md please follow that for quick reproduction.
> Basically the program has a function `normalize_insert_lsn`which implements 
> the client side fix. But passing a parameter `--raw-insert-lsn` to the 
> program disables this client side manipulation.

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.

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?

------
Regards,
Alexander Korotkov
Supabase

Attachment: v1-0001-Don-t-make-WAIT-FOR-LSN-depend-on-WAL-written-aft.patch
Description: Binary data

Reply via email to