Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sYTV2-00BdKr-PC for pgsql-committers@arkaria.postgresql.org; Mon, 29 Jul 2024 16:45:28 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sYTV1-0015FZ-8T for pgsql-committers@arkaria.postgresql.org; Mon, 29 Jul 2024 16:45:27 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sYTV1-0015FR-1I for pgsql-committers@lists.postgresql.org; Mon, 29 Jul 2024 16:45:27 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sYTUy-00243p-NJ for pgsql-committers@lists.postgresql.org; Mon, 29 Jul 2024 16:45:25 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 46TGjJZ02803950; Mon, 29 Jul 2024 12:45:19 -0400 From: Tom Lane To: Andres Freund cc: Heikki Linnakangas , pgsql-committers@lists.postgresql.org Subject: Re: pgsql: Fix double-release of spinlock In-reply-to: <20240729164026.yurg37tej34o76uk@awork3.anarazel.de> References: <2600757.1722267116@sss.pgh.pa.us> <20240729161846.kgiafbe2dtgabxgb@awork3.anarazel.de> <2802449.1722270793@sss.pgh.pa.us> <20240729164026.yurg37tej34o76uk@awork3.anarazel.de> Comments: In-reply-to Andres Freund message dated "Mon, 29 Jul 2024 09:40:26 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2803948.1722271519.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Jul 2024 12:45:19 -0400 Message-ID: <2803949.1722271519@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Andres Freund 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 actua= lly > initialized. But that again seems like something we'd be better off addi= ng > more general infrastructure for - nobody runs --disable-spinlocks locall= y, 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