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-12 04:03:43 |
Message-ID: | 334468.1712894623@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 23:15:38 -0400, Tom Lane wrote:
>> On the third hand, it's still true that we have no comparable
>> behavior for any other source of system lockups, and it's difficult
>> to make a case that stuck spinlocks really need more concern than
>> other kinds of bugs.
> Spinlocks are somewhat more finnicky though, compared to e.g. lwlocks that are
> released on error. Lwlocks also take e.g. care to hold interrupts so code
> doesn't just jump out of a section with lwlocks held.
Yeah. I don't think that unifying spinlocks with lwlocks is a great
idea, precisely because lwlocks have these other small overheads
in the name of bug detection/prevention. It seems to me that the
division between spinlocks and lwlocks and heavyweight locks is
basically a good idea that matches up well with the actual
requirements of some different parts of our code. The underlying
implementations can change (and have), but the idea of successively
increasing amounts of protection against caller error seems sound
to me.
If you grant that concept, then the idea that spinlocks need more
protection against stuck-ness than the higher-overhead levels do
seems mighty odd.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2024-04-12 04:16:33 | further improving roles_is_member_of() |
Previous Message | Andres Freund | 2024-04-12 03:47:37 | Re: Issue with the PRNG used by Postgres |