Re: Little cleanup: Move ProcStructLock to the ProcGlobal struct

Heikki Linnakangas <hlinnaka@iki.fi>

From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Tom Lane <tgl@sss.pgh.pa.us>, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: Chao Li <li.evan.chao@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2026-02-11T15:05:27Z
Lists: pgsql-hackers
On 11/02/2026 16:52, Tom Lane wrote:
> Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> writes:
>> On Wed, Feb 11, 2026 at 8:46 AM Chao Li <li.evan.chao@gmail.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.

Right.

> 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.

Do we still support any architectures where initializing the spinlock to 
all-zeros doesn't do the right thing? Could we accept that all-zeros is 
a valid initialization of a spinlock? This reminds me that Thomas was 
working on re-implementing spinlocks with atomics [1]. With that least, 
I presume we could.

[1] 
https://www.postgresql.org/message-id/CA%2BhUKGKFvu3zyvv3aaj5hHs9VtWcjFAmisOwOc7aOZNc5AF3NA%40mail.gmail.com

- Heikki




Commits

  1. Move ProcStructLock to the ProcGlobal struct