Re: Little cleanup: Move ProcStructLock to the ProcGlobal struct
| От | Heikki Linnakangas |
|---|---|
| Тема | Re: Little cleanup: Move ProcStructLock to the ProcGlobal struct |
| Дата | |
| Msg-id | 0f61d89e-f635-4e99-bf01-9b8c2ff4f423@iki.fi обсуждение |
| Ответ на | Re: Little cleanup: Move ProcStructLock to the ProcGlobal struct (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Little cleanup: Move ProcStructLock to the ProcGlobal struct
|
| Список | 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
В списке pgsql-hackers по дате отправления: