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
