Re: Issue with the PRNG used by Postgres

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Parag Paul <parag(dot)paul(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Issue with the PRNG used by Postgres
Date: 2024-04-11 20:11:40
Message-ID: 234683.1712866300@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2024-04-11 15:24:28 -0400, Robert Haas wrote:
>> Or, rip out the whole, whole mechanism and just don't PANIC.

> I continue believe that that'd be a quite bad idea.

I'm warming to it myself.

> My suspicion is that most of the false positives are caused by lots of signals
> interrupting the pg_usleep()s. Because we measure the number of delays, not
> the actual time since we've been waiting for the spinlock, signals
> interrupting pg_usleep() trigger can very significantly shorten the amount of
> time until we consider a spinlock stuck. We should fix that.

We wouldn't need to fix it, if we simply removed the NUM_DELAYS
limit. Whatever kicked us off the sleep doesn't matter, we might
as well go check the spinlock.

Also, you propose in your other message replacing spinlocks with
lwlocks. Whatever the other merits of that, I notice that we have
no timeout or "stuck lwlock" detection. So that would basically
remove the stuck-spinlock behavior in an indirect way, without
adding any safety measures that would justify thinking that it's
less likely we needed stuck-lock detection than before.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2024-04-11 20:17:13 Re: Should we add a compiler warning for large stack frames?
Previous Message Andres Freund 2024-04-11 20:03:47 Re: Issue with the PRNG used by Postgres