Hi Andres,
On 8/6/21 1:27 PM, Drouvot, Bertrand wrote:
Hi,
On 8/2/21 6:01 PM, Andres Freund wrote:
While working on this I found a, somewhat substantial, issue:
If so, do you already have in mind a way to handle this? (I thought you
already had in mind a way to handle it so the question)
Yes. I think we need to add a condition variable to be able to wait for
WAL positions to change. Either multiple condition variables (one for
the flush position, one for the replay position), or one that just
changes more often. That way one can wait for apply without a race
condition.
Thanks for the feedback.
Wouldn't a condition variable on the replay position be enough? I don't get why the proposed one on the flush position is needed.
Please find enclosed a patch proposal to address those corner cases.
I think (but may be wrong) that the condition variable on the flush position would be needed only for the walsender(s) on non Standby node, that's why:
- I made use of a condition variable on the replay position only.
- The walsender waits on it in WalSndWaitForWal() only if recovery is in progress.
For simplicity to discuss those corner cases, this is a dedicated patch that can be applied on top of v23 patches shared previously.
Thanks
Bertrand
if not, what kind of additional
tests would you like to see?
A few catalog rows being removed (e.g. due to DELETE and then VACUUM
*without* full) and a standby without hot_standby_feedback catching
that.
Test added in v23 attached.
Thanks
Bertrand