From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Cc: pgsql-committers@lists.postgresql.org
Subject: Re: pgsql: Fix double-release of spinlock
Date: Mon, 29 Jul 2024 12:33:13 -0400
Message-ID: <2802449.1722270793@sss.pgh.pa.us> (raw)
In-Reply-To: <20240729161846.kgiafbe2dtgabxgb@awork3.anarazel.de>
References: <E1sYSF2-001lEB-D1@gemulon.postgresql.org>
<2600757.1722267116@sss.pgh.pa.us>
<20240729161846.kgiafbe2dtgabxgb@awork3.anarazel.de>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-committers@postgresql.org
Cc: tgl@sss.pgh.pa.us, andres@anarazel.de, heikki.linnakangas@iki.fi, pgsql-committers@lists.postgresql.org
Subject: Re: pgsql: Fix double-release of spinlock
In-Reply-To: <2802449.1722270793@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox