From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)iki(dot)fi> |
Cc: | pgsql-committers(at)lists(dot)postgresql(dot)org, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: pgsql: Fix double-release of spinlock |
Date: | 2024-07-29 15:31:56 |
Message-ID: | 2600757.1722267116@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
Heikki Linnakangas <heikki(dot)linnakangas(at)iki(dot)fi> writes:
> Commit 9d9b9d46f3 added spinlocks to protect the fields in ProcSignal
> flags, but in EmitProcSignalBarrier(), the spinlock was released
> twice. With most spinlock implementations, releasing a lock that's not
> held is not easy to notice, because most of the time it does nothing,
> but if the spinlock was concurrently acquired by another process, it
> could lead to more serious issues. Fortunately, with the
> --disable-spinlocks emulation implementation, it caused more visible
> failures.
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-07-29 16:17:34 | pgsql: Count individual SQL commands in pg_restore's --transaction-size |
Previous Message | Heikki Linnakangas | 2024-07-29 15:28:43 | Re: pgsql: Move cancel key generation to after forking the backend |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2024-07-29 15:34:39 | Re: tls 1.3: sending multiple tickets |
Previous Message | Heikki Linnakangas | 2024-07-29 15:24:52 | pgsql: Fix double-release of spinlock |