Hi,
On 2024-04-11 20:47:37 -0700, Andres Freund wrote:
> > So there's that. But that's not an argument that we need to be in a
> > hurry to timeout; if the built-in reaction time is less than perhaps
> > 10 minutes you're still miles ahead of the manual solution.
>
> The current timeout is of a hard to determine total time, due to the
> increasing and wrapping around wait times, but it's normally longer than 60s,
> unless you're interrupted by a lot of signals. 1000 sleeps between 1000 and
> 1000000 us.
>
> I think we should make the timeout something predictable and probably somewhat
> longer.
FWIW, I just reproduced the scenario with signals. I added tracking of the
total time actually slept and lost to SpinDelayStatus, and added a function to
trigger a wait on a spinlock.
To wait less, I set max_standby_streaming_delay=0.1, but that's just for
easier testing in isolation. In reality that could have been reached before
the spinlock is even acquired.
On a standby, while a recovery conflict is happening:
PANIC: XX000: stuck spinlock detected at crashme, path/to/file:line, after 4.38s, lost 127.96s
So right now it's really not hard to trigger the stuck-spinlock logic
completely spuriously. This doesn't just happen with hot standby, there are
plenty other sources of lots of signals being sent.
Tracking the total amount of time spent sleeping doesn't require any
additional syscalls, due to the nanosleep()...
Greetings,
Andres Freund
