From: | Xuneng Zhou <xunengzhou(at)gmail(dot)com> |
---|---|
To: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
Cc: | Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Tomas Vondra <tomas(at)vondra(dot)me>, Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Implement waiting for wal lsn replay: reloaded |
Date: | 2025-08-09 10:52:37 |
Message-ID: | CABPTF7U5n+w9-zLjy2pB7Z3veeVhbAre=jEqFW+5B4zvtMBfvg@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Alexander!
> > In the meantime, I have
> > a quick question: is WAIT FOR REPLY intended mainly for user-defined
> > functions, or can internal code invoke it as well?
>
> Currently, WaitForLSNReplay() is assumed to only be called from
> backend, as corresponding shmem is allocated only per-backend. But
> there is absolutely no problem to tweak the patch to allocate shmem
> for every Postgres process. This would enable to call
> WaitForLSNReplay() wherever it is needed. There is only no problem to
> extend this approach to support other kinds of LSNs not just replay
> LSN.
Thanks for extending the functionality of the Wait For Replay patch!
> This looks like a great new use-case for facilities developed in this
> patch! I'll remove the restriction to use WaitForLSNReplay() only in
> backend. I think you can write a patch with additional pairing heap
> for flush LSN and include that into thread about
> read_local_xlog_page_guts() optimization. Let me know if you need any
> assistance.
This could be a more elegant approach which would solve the polling
issue well. I'll prepare a follow-up patch for it.
Best,
Xuneng
From | Date | Subject | |
---|---|---|---|
Next Message | Xuneng Zhou | 2025-08-09 11:27:25 | Re: Implement waiting for wal lsn replay: reloaded |
Previous Message | Peter Eisentraut | 2025-08-09 09:59:19 | Re: Datum as struct |