Re: convert SpinLock* macros to static inline functions - Mailing list pgsql-hackers

From Fabrízio de Royes Mello
Subject Re: convert SpinLock* macros to static inline functions
Date
Msg-id CAFcNs+oZc9ZDocTsB1nCO=uN9TBbc90ne7buxe6i4cDtG4qXjQ@mail.gmail.com
Whole thread
In response to Re: convert SpinLock* macros to static inline functions  (Nathan Bossart <nathandbossart@gmail.com>)
List 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

pgsql-hackers by date:

Previous
From: Marcos Magueta
Date:
Subject: Re: WIP - xmlvalidate implementation from TODO list
Next
From: Robert Treat
Date:
Subject: Re: Optional skipping of unchanged relations during ANALYZE?