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

  1. Fix double-release of spinlock

  2. Move cancel key generation to after forking the backend