| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com> |
| Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Andres Freund <andres(at)anarazel(dot)de>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: convert SpinLock* macros to static inline functions |
| Date: | 2026-02-18 18:03:19 |
| Message-ID: | aZX-54TFRoFo-rwV@nathan |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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(at)gmail(dot)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.
--
nathan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2026-02-18 18:07:43 | Re: Use standard die() handler for SIGTERM in bgworkers |
| Previous Message | Robert Treat | 2026-02-18 18:00:00 | Re: [PROPOSAL] Doublewrite Buffer as an alternative torn page protection to Full Page Write |