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
