| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| 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:18:46 |
| Message-ID: | 20240729161846.kgiafbe2dtgabxgb@awork3.anarazel.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers pgsql-hackers |
Hi,
On 2024-07-29 11:31:56 -0400, Tom Lane wrote:
> 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.
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?
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2024-07-29 16:33:13 | Re: pgsql: Fix double-release of spinlock |
| Previous Message | Tom Lane | 2024-07-29 16:17:34 | pgsql: Count individual SQL commands in pg_restore's --transaction-size |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2024-07-29 16:20:45 | Re: Assertion failure with summarize_wal enabled during pg_createsubscriber |
| Previous Message | Robert Haas | 2024-07-29 15:34:39 | Re: tls 1.3: sending multiple tickets |