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
-
Move ProcStructLock to the ProcGlobal struct
- 7984ce7a1d21 19 (unreleased) landed