Re: pgsql: Fix double-release of spinlock
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Heikki Linnakangas <heikki.linnakangas@iki.fi>,
pgsql-committers@lists.postgresql.org
Date: 2024-07-29T16:33:13Z
Lists: pgsql-hackers
Andres Freund <andres@anarazel.de> writes: > On 2024-07-29 11:31:56 -0400, Tom Lane wrote: >> There was some recent discussion about getting rid of >> --disable-spinlocks on the grounds that nobody would use >> hardware that lacked native spinlocks. But now I wonder >> if there is a testing/debugging reason to keep it. > Seems it'd be a lot more straightforward to just add an assertion to the > x86-64 spinlock implementation verifying that the spinlock isn't already free? I dunno, is that the only extra check that the --disable-spinlocks implementation is providing? I'm kind of allergic to putting Asserts into spinlocked code segments, mostly on the grounds that it violates the straight-line-code precept. I suppose it's not really that bad for tests that you don't expect to fail, but still ... regards, tom lane
Commits
-
Fix double-release of spinlock
- 0393f542d72c 18.0 cited
-
Move cancel key generation to after forking the backend
- 9d9b9d46f3c5 18.0 cited