Re: pgsql: Fix double-release of spinlock

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)iki(dot)fi>, pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: Re: pgsql: Fix double-release of spinlock
Date: 2024-07-29 16:45:19
Message-ID: 2803949.1722271519@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2024-07-29 12:33:13 -0400, Tom Lane wrote:
>> I dunno, is that the only extra check that the --disable-spinlocks
>> implementation is providing?

> I think it also provides the (valuable!) check that spinlocks were actually
> initialized. But that again seems like something we'd be better off adding
> more general infrastructure for - nobody runs --disable-spinlocks locally, we
> shouldn't need to run this on the buildfarm to find problems like this.

Hmm, but how? One of the things we gave up by nuking HPPA support
was that that platform's representation of an initialized, free
spinlock was not all-zeroes, so that it'd catch this type of problem.
I think all the remaining platforms do use zeroes, so it's hard to
see how anything short of valgrind would be likely to catch it.

regards, tom lane

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Andres Freund 2024-07-29 16:51:54 Detect double-release of spinlock
Previous Message Andres Freund 2024-07-29 16:40:26 Re: pgsql: Fix double-release of spinlock

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2024-07-29 16:51:54 Detect double-release of spinlock
Previous Message Andres Freund 2024-07-29 16:40:26 Re: pgsql: Fix double-release of spinlock