Re: pgsql: Fix double-release of spinlock
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Heikki Linnakangas <heikki.linnakangas@iki.fi>,
pgsql-committers@lists.postgresql.org
Date: 2024-07-29T16:45:19Z
Lists: pgsql-hackers
Andres Freund <andres@anarazel.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
Commits
-
Fix double-release of spinlock
- 0393f542d72c 18.0 cited
-
Move cancel key generation to after forking the backend
- 9d9b9d46f3c5 18.0 cited