On 25/10/2023 21:59, Andres Freund wrote:
On 2023-10-25 12:17:03 +0300, Heikki Linnakangas wrote:
On 25/10/2023 02:09, Andres Freund wrote:
Because of the inherent delay between the checks of XLogCtl->WalWriterSleeping
and Latch->is_set, we also sometimes end up with multiple processes signalling
walwriter, which can be bad, because it increases the likelihood that some of
the signals may be received when we are already holding WALWriteLock, delaying
its release...
That can only happen when walwriter has just come out of "hibernation", ie.
when the system has been idle for a while. So probably not a big deal in
practice.
Maybe I am missing something here - why can this only happen when hibernating?
Even outside of that two backends can decide that that they need to wake up
walwriter?
Ah sure, multiple backends can decide to wake up walwriter at the same
time. I thought you meant that the window for that was somehow wider
when XLogCtl->WalWriterSleeping.
We could prevent that, by updating state when requesting walwriter to be woken
up. But with the changes we're discussing below, that should be rare.
One small easy thing we could do to reduce the redundant wakeups: only
wake up walwriter if asyncXactLSN points to different page than
prevAsyncXactLSN.
--
Heikki Linnakangas
Neon (https://neon.tech)
