Re: convert SpinLock* macros to static inline functions
Fabrízio de Royes Mello <fabriziomello@gmail.com>
From: Fabrízio de Royes Mello <fabriziomello@gmail.com>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, Andres Freund <andres@anarazel.de>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2026-02-18T19:21:57Z
Lists: pgsql-hackers
On Wed, Feb 18, 2026 at 3:03 PM Nathan Bossart <nathandbossart@gmail.com> wrote: > > On Wed, Feb 18, 2026 at 02:52:46PM -0300, Fabrízio de Royes Mello wrote: > > On Wed, Feb 18, 2026 at 2:28 PM Nathan Bossart <nathandbossart@gmail.com > > > wrote: > >> However, as soon as I did this, I got a bunch of build failures because > >> various parts of the code still use volatile qualifiers quite liberally. > >> It looks like most of these (e.g., see code from commits 2487d872e0, > >> 966fb05b58, 4bc15a8bfb, and 4db3744f1f) predate making spinlocks compiler > >> barriers (commit 0709b7ee72) or were cargo-culted from code that predated > >> it. So, IIUC, it's probably safe to remove these volatile qualifiers now. > >> We could alternatively add volatile qualifiers to the new static inline > >> function parameters, but that seems like it might just encourage continued > >> unnecessary use. > > > > Just wondering if there's some code-path that uses it inside > > PG_TRY..PG_CATCH that can use longjump. > > I didn't notice any such code. For reference, we only need "volatile" in > PG_TRY..PG_CATCH code if a local variable is modified in the PG_TRY section > and used in the PG_CATCH section. > Sure sure sure... there's no such condition with your change (took another look into it). So your patches LGTM. -- Fabrízio de Royes Mello
Commits
-
Convert SpinLock* macros to static inline functions.
- bfc321b4723e 19 (unreleased) landed
-
Remove SpinLockFree() and S_LOCK_FREE().
- ba401828c194 19 (unreleased) landed
-
Change the spinlock primitives to function as compiler barriers.
- 0709b7ee72e4 9.5.0 cited