Robert Haas <robertmh...@gmail.com> writes:
> On Wed, Apr 10, 2024 at 9:53 PM Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Maybe we should rip out the whole mechanism and hard-wire
>> spins_per_delay at 1000 or so.
> Or, rip out the whole, whole mechanism and just don't PANIC.
By that you mean "remove the NUM_DELAYS limit", right? We still ought
to sleep sometimes if we don't get a spinlock promptly, so that seems
fairly orthogonal to the other points raised in this thread.
Having said that, it's not an insane suggestion. Our coding rules
for spinlocks are tight enough that a truly stuck spinlock should
basically never happen, and certainly it basically never happens in
developer testing (IME anyway, maybe other people break things at
that level more often). Besides, if it does happen it wouldn't be
different in a user's eyes from other infinite or near-infinite loops.
I don't think we could risk putting in a CHECK_FOR_INTERRUPTS, so
getting out of it would require "kill -9" or so; but it's hardly
unheard-of for other problematic loops to not have such a check.
regards, tom lane
