Re: Issue with the PRNG used by Postgres

On Fri, Apr 12, 2024 at 3:33 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> Here's a patch implementing this approach. I confirmed that before we trigger
> the stuck spinlock logic very quickly and after we don't. However, if most
> sleeps are interrupted, it can delay the stuck spinlock detection a good
> bit. But that seems much better than triggering it too quickly.

+1 for doing something about this. I'm not sure if it goes far enough,
but it definitely seems much better than doing nothing. Given your
findings, I'm honestly kind of surprised that I haven't seen problems
of this type more frequently. And I think the general idea of not
counting the waits if they're interrupted makes sense. Sure, it's not
going to be 100% accurate, but it's got to be way better for the timer
to trigger too slowly than too quickly. Perhaps that's too glib of me,
given that I'm not sure we should even have a timer, but even if we
stipulate that the panic is useful in some cases, spurious panics are
still really bad.

--
Robert Haas
EDB: http://www.enterprisedb.com