Re: Little cleanup: Move ProcStructLock to the ProcGlobal struct

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
Cc: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Little cleanup: Move ProcStructLock to the ProcGlobal struct
Date: 2026-02-11 14:52:56
Message-ID: 4080968.1770821576@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> writes:
> On Wed, Feb 11, 2026 at 8:46 AM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
>> But I don’t see a replacement like SpinLockInit(&ProcGlobal->freeProcsLock);

> Good catch.

Undoubtedly, this escaped Heikki's notice because on all supported
platforms SpinLockInit() initializes the spinlock value to zero,
but shared memory starts out zeroes anyway.

We used to have better odds of catching such mistakes. My old HPPA
dinosaur would have caught it by dint of needing a nonzero initial
value, but that hardware is long gone. The test infrastructure
we used to have for emulating spinlocks with SysV semaphores would
have caught it too, I think, but that's also gone.

This is not a great situation. I wonder if we can put back some
mode that could be used by a few BF members to catch such oversights.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Viktor Holmberg 2026-02-11 14:54:55 Re: ON CONFLICT DO SELECT (take 3)
Previous Message Jim Jones 2026-02-11 14:18:39 Re: Add CREATE SCHEMA ... LIKE support