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
