| 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:33:13 |
| Message-ID: | 2802449.1722270793@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 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2024-07-29 16:34:49 | pgsql: Remove tab completion for CREATE UNLOGGED MATERIALIZED VIEW. |
| Previous Message | Andres Freund | 2024-07-29 16:18:46 | Re: pgsql: Fix double-release of spinlock |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2024-07-29 16:38:42 | Re: CREATE MATERIALIZED VIEW |
| Previous Message | Robert Haas | 2024-07-29 16:21:08 | Re: Incremental backup from a streaming replication standby fails |