Re: pgsql: Fix double-release of spinlock

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Heikki Linnakangas <heikki.linnakangas@iki.fi>, pgsql-committers@lists.postgresql.org
Date: 2024-07-29T17:37:52Z
Lists: pgsql-hackers
On Mon, Jul 29, 2024 at 12:40 PM Andres Freund <andres@anarazel.de> wrote:
> 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.

+1. It sucks to have to do special builds to catch a certain kind of
problem. I know I've been guilty of that (ahem, debug_parallel_query
f/k/a force_parallel_mode) but I'm not going to put it on my CV as one
of my great accomplishments. It's much better if we can find a way for
a standard 'make check-world' to tell us about as many things as
possible, so that we don't commit and then find out.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



Commits

  1. Fix double-release of spinlock

  2. Move cancel key generation to after forking the backend