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)
