Subject: Trying out <stdatomic.h>

From: Thomas Munro <[email-masked]>
Date: Tue, 11 Nov 2025 02:17:31 +1300

Hi,

Here is an experimental patch to try out standard C (and C++) atomics
to implement port/atomics.h, and also add more types and operations.
It's mostly just redirecting our names to the standard ones, except
for our barriers and slightly extended pg_atomic_flag, so there isn't
much left of the code.

Here also is a semi-independent patch to implement storage/spin.h with
pg_atomic_flag.  It keeps a small amount of the architecture-specific
magic, but moves it out to src/port/spin_delay.h.

I'm not saying they're correct, performant or portable yet, that'll
require studying codegen and performance on a bunch of weird and
wonderful systems, but they at least passes basic testing on the usual
suspects and CI systems, except for Windows which needs a newer
toolchain so I haven't tried yet.  It should hopefully just work™ on
VS 2022 (same version that provides <threads.h>, about which more
soon).

All that being the case, it's not far enough along to be a serious
proposal, but I imagine others will be looking into things like this
since we pulled the trigger on C11 and I figured I might as well share
a basic working patch set to avoid duplicated effort...   Hopefully it
works well enough to kick the tyres and try to find the difficult
problems, test it out on weird systems, etc etc.

---

From: Heikki Linnakangas <[email-masked]>
Date: Mon, 10 Nov 2025 15:57:03 +0200

>  9 files changed, 166 insertions(+), 1824 deletions(-)
>  ...
>  8 files changed, 176 insertions(+), 881 deletions(-)
>  ...
>  7 files changed, 1 insertion(+), 394 deletions(-)

Nice!

> [PATCH v1 1/4] Add some missing #include <limits.h>.

This seems like a good thing regardless of the other patches.

The "#include <limits.h>" lines in src/backend/lib/dshash.c and 
src/backend/storage/lmgr/condition_variable.c are slightly misplaced: 
system headers should be included between "postgres.h" and other 
postgres headers.

> magic, but moves it out to src/port/spin_delay.h.

Makes sense.

The patch removes 'src/template/solaris'. Is that on purpose? Is that an 
independent cleanup that could be committed immediately?

- Heikki

---

From: Tom Lane <[email-masked]>
Date: Mon, 10 Nov 2025 10:19:46 -0500

> independent cleanup that could be committed immediately?

Our four Solaris+illumos buildfarm animals would be sad.

			regards, tom lane

---

From: Thomas Munro <[email-masked]>
Date: Tue, 11 Nov 2025 09:25:33 +1300

> Our four Solaris+illumos buildfarm animals would be sad.

Looks like I overdid it while rebasing over the commit that removed
the dead Sun compiler... will put that bit back.

---

From: Thomas Munro <[email-masked]>
Date: Fri, 14 Nov 2025 00:35:48 +1300

> This seems like a good thing regardless of the other patches.

Pushed.

> The patch removes 'src/template/solaris'. Is that on purpose?

Fixed.

It passes with VS 2022 on CI.  I had to skip some assertions about
macros promising lock-free implementation, that it doesn't define in C
mode yet.  They are definitely lock-free though[1], and the macros are
defined for C++, and the same under the covers...  Perhaps
feature/conformance macros won't be defined until a few remaining
pieces (things we don't care about) are accessible from C?  (I see
that Visual Studio 2026 has also just shipped a couple of days ago,
not investigated.)

[1] https://devblogs.microsoft.com/cppblog/c11-atomics-in-visual-studio-2022-version-17-5-preview-2/

---

From: Peter Eisentraut <[email-masked]>
Date: Wed, 19 Nov 2025 12:23:25 +0100

> that Visual Studio 2026 has also just shipped a couple of days ago,

Note also that we still have buildfarm members with gcc <4.9, which is 
required for stdatomic.h/_Atomic there.

We could most likely resolve to get rid of them when the time comes, but 
let's not forget to plan that.

---

From: Aleksander Alekseev <[email-masked]>
Date: Wed, 19 Nov 2025 17:03:03 +0300

Hi Thomas,

> that Visual Studio 2026 has also just shipped a couple of days ago,

Thanks for working on this. I checked v2 on Linux x64 with and without
Valgrind and it passed all the tests. I haven't looked at the code
closely yet.

--
Best regards,
Aleksander Alekseev

---

From: Thomas Munro <[email-masked]>
Date: Thu, 20 Nov 2025 20:12:18 +1300

> required for stdatomic.h/_Atomic there.

Those are EOL'd RHEL/Centos 7 and SUSE 12 systems.  A decision to
require GCC 4.9+ might not be fatal to them though, as those distros
had optional newer tool chain packages too.  I'm not sure what
problems could follow from that, probably not much as far as C goes?
C++ ABI questions are always harder but such old systems couldn't
possibly use LLVM as we chop old releases based on distro EOL dates,
and LLVM adopts new language standards (being a compiler project after
all).  (It'll be interesting to see what happens when LLVM requires
C++23, and then RHEL's new rolling LLVM upgrade policy meets its 10
year old stable compiler policy...)

The elephant in the room is Visual Studio.  We have drongo on 2019,
hammerkop on 2022, and CI on 2019 but ready to flip to 2022 whenever
we're ready.  There is no testing for 2026, being only a few days old
(I heard from Bilal that our CI passed when he tried it out FWIW).
2019 fell out of "mainstream" support 1.6 years ago[1], "extended"
support lasts 3.4 more years, and 2017's "extended" support also lasts
1.4 more years, which didn't stop commit 8fd9bb1d from chopping it to
gain some C11 support.  When could we chop 2019 too, to gain more C11
support?

What motivation do people have to use old compilers for new software?
If my google-search-fu is serving me, upgrades are either free
(community edition for individuals, also for organisations working on
open source) or included in various paid subscriptions.  Is there a
technical reason to be more conservative, for example, in terms of
library versions on the target system, something to do with UCRT or
_WIN32_WINNT versions that the EDB installer needs to target before
you can use this stuff?  I can't find anything saying so.  Perhaps
it'd be better to wait until /experimental:c11atomics isn't needed
though.  My impression so far is that that's about conformance with
details we don't care about, not the maturity of the codegen which is
used far and wide in C++, it's just that C conformance is a distant
second priority (1½ decades later), but...  (Not that this project is
finished anyway, more study and validation required.)

[1] https://learn.microsoft.com/en-us/lifecycle/products/visual-studio-2019

---

From: Thomas Munro <[email-masked]>
Date: Thu, 20 Nov 2025 20:16:34 +1300

> Valgrind and it passed all the tests. I haven't looked at the code

Thanks for testing!

The next thing on my TODO list for this is some kind of codegen diff
on a full matrix of targets.

---

From: "Greg Burd" <[email-masked]>
Date: Sun, 23 Nov 2025 10:02:29 -0500

> Our four Solaris+illumos buildfarm animals would be sad.

I have another Illumos animal in the works, but if the plan is to deprecate that platform I can set that aside.  As an old Sun engineer I hate to see it disappear, but it is basically EOL at this point.

-greg

---

From: Greg Burd <[email-masked]>
Date: Sun, 23 Nov 2025 10:22:47 -0500

On Mon, Nov 10, 2025, at 8:17 AM, Thomas Munro wrote:
> Attachments:
> * v1-0001-Add-some-missing-include-limits.h.patch
> * v1-0002-Redefine-port-atomics.h-on-top-of-stdatomic.h.patch
> * v1-0003-Use-atomics-API-to-implement-spinlocks.patch
> * v1-0004-Remove-configure-meson-checks-for-atomics.patch

Hello Thomas,

First off, thanks for working on this set of changes.  I like your changes in general, except for removing Solaris/Illumos (but I get it).  ;-P

As mentioned on a separate thread about fixing ARM64 support when building with MSVC on Win11 [1] I tried out this patch.  The reply on that thread had an issue with _mm_pause() in spin_delay(), it turns out we need to use __yield() [2].  I went ahead and fixed that, so ignore that patch on the other thread [1].  The new patch attached that layers on top of your work and supports that platform, there was one minor change that was required:

#ifdef _MSC_VER

	/*
	 * If using Visual C++ on Win64, inline assembly is unavailable.  Use a
	 * _mm_pause intrinsic instead of rep nop. For ARM64, use the __yield()
	 * intrinsic which emits the YIELD instruction as a hint to the processor.
	 */
#if defined(_M_ARM64)
	__yield();
#elif defined(_WIN64)
	_mm_pause();
#else
	/* See comment for gcc code. Same code, MASM syntax */
	__asm		rep nop;
#endif
#endif							/* _MSC_VER */

Visual Studio 2026 (Community)
cl (msvc 19.50.35718 "Microsoft (R) C/C++ Optimizing Compiler Version 19.50.35718 for ARM64")
link 14.50.35718.0

tests are passing, best.

-greg

[1] https://www.postgresql.org/message-id/3c576ad7-d2da-4137-b791-5821da7cc370%40app.fastmail.com
[2] https://learn.microsoft.com/en-us/cpp/intrinsics/arm64-intrinsics?view=msvc-180

---

From: Tom Lane <[email-masked]>
Date: Sun, 23 Nov 2025 12:02:17 -0500

> I have another Illumos animal in the works, but if the plan is to deprecate that platform I can set that aside.  As an old Sun engineer I hate to see it disappear, but it is basically EOL at this p…

I think we can keep it going as long as there are people interested
in it.  The gating factor at present is probably whether it can
provide an adequate C11 environment.  But so far I've observed no
issues with the existing BF members.

			regards, tom lane

---

From: Álvaro Herrera <[email-masked]>
Date: Sun, 23 Nov 2025 19:17:32 +0100

> issues with the existing BF members.

Right -- we have

billbug		Solaris 11.4.81 CBE 04.2025	gcc 14.2.0
hake		OpenIndiana / Illumos		gcc 9.3.0
margay		Solaris 11.4.42 CBE		gcc 11.2.0
pollock		OmniOS / illumos		gcc 10.2.0

Hake actually says:
  gcc (OpenIndiana 13.3.0-oi-2) 13.3.0

and pollock:
  gcc (OmniOS 151054/14.2.0-il-1) 14.2.0

so it looks like the oldest is Margay's 11.2, which claims [1] to
support C11, though there are some bugs that were claimed fixed in later
releases of GCC 11.x related to alignment[2].  Perhaps relevant, but I
only searched the strings "align" and "c11" there, they may not apply to
our usage.  At least the owner of margay and billbug is active, so we
can probably get the compiler in these machines updated if needed.

[1] https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gcc/Standards.html#C-Language
[2] https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=11.3
    and further for 11.4, 11.5, 11.6.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/

---

From: Thomas Munro <[email-masked]>
Date: Mon, 24 Nov 2025 09:16:17 +1300

> issues with the existing BF members.

Yeah, Solaris has caused comparatively little trouble, if you exclude
the defunct compiler and a build farm animal running a frozen zombie
Solaris version.  It's pretty easy for Linux users to understand
because of its huge influence on standards and conventions back in the
90s.  The buildfarm animals are maintained by people with a real
interest in PostgreSQL on both OSes, and both OSes fix bugs we report
and track POSIX actively.  We've run on SunOS/BSD and descendents for
coming up 40 (POSTGRES) or 30 (PostgreSQL) years, and I'm hoping we'll
even get to complete that Berkeley to-do item about using threads on
SunOS one of these days...  I just goofed when rebasing the v1 patch
and git rm-ed the template file instead of git add-ing it in v1, but I
fixed that in v2.

---

From: Thomas Munro <[email-masked]>
Date: Mon, 24 Nov 2025 10:08:19 +1300

>         /* See comment for gcc code. Same code, MASM syntax */

That makes more intuitive sense... but I didn't know that people *do*
sometimes prefer instruction synchronisation barriers for spinlock
delays:

https://stackoverflow.com/questions/70810121/why-does-hintspin-loop-use-isb-on-aarch64

When reading your patch I was pretty confused by that, because it said
it was fixing a barrier problem and apparently doing so in an
unprincipled place.  I guess we really need to research the best delay
mechanism for our needs on this architecture, independently of the
compiler being used, and then write matching GCC and Visual Studio
versions of that?  I think there were some threads about spinlock
performance on Linux + Graviton with graphs and theories...

> tests are passing, best.

Great news!  Thanks.  It sounds like if I could supply the missing
credible evidence of codegen quality on... all the computers, then I
think we'd be down to just: when can we pull the trigger and require
Visual Studio 2022 and do we trust /experimental:c11atomics?

FTR I had earlier shared some version of this patch with Dave when he
was trying to get his Windows/ARM system going, but I think my earlier
version was probably too broken.  Sorry Dave.  At that stage I was
also trying to do it as an option but keeping the existing stuff
around.  Since then we adopted C11, so this is the all-in version.  I
also hadn't understood a key part of the C11 memory model that your
RISC-V animal taught me and that c5d34f4a fixed, and you can see in
this patch set too, and I'm not sure if Visual Studio is like GCC or
Clang in that respect.  It crossed my mind that this might even be
related to the problem you've noticed with barriers being missing, but
I haven't looked into that.  BTW I believe we could actually change
our code NOT to rely on that, ie to follow the C11 memory model better
and declare eg PgAioHandle::status as atomic_uint8 or whatever (other
non-atomic access would be considered dependent and do the right thing
IIUC), but I'm not sure if it's necessary and that research project
can wait.

---

From: Greg Burd <[email-masked]>
Date: Sun, 23 Nov 2025 16:17:25 -0500

On Nov 23 2025, at 4:08 pm, Thomas Munro <[email-masked]> wrote:

>> As mentioned on a separate thread about fixing ARM64 support when
>> building with MSVC on Win11 [1] I tried out this patch.  The reply on
>> that thread had an issue with _mm_pause() in spin_delay(), it turns
>> out we need to use __yield() [2].  I went ahead and fixed that, so
>> ignore that patch on the other thread [1].  The new patch attached
>> that layers on top of your work and supports that platform, there was
>> one minor change that was required:
>>  
>>  
>> #ifdef _MSC_VER
>>  
>>         /*

Interesting, I think I was rushing to get past that compile issue rather
than optimizing.  This sounds like yet another place where we should
choose based on arch and it seems hint::spin_loop() does.

> Visual Studio 2022 and do we trust /experimental:c11atomics?

I'm in favor of the stdatomic approach.  I can't speak to codegen
quality on *all the platforms* or how *experimental* c11 atomics are
when using MSVC.

> Clang in that respect.

Thanks for that work on RISC-V, I appreciate that!  Much more digging to
be done to answer those questions for sure.

> It crossed my mind that this might even be

Interesting.  Yeah, let's do one thing and then move to the next, but I
do like the idea.

best.

-greg

---

From: Peter Eisentraut <[email-masked]>
Date: Mon, 23 Mar 2026 12:57:43 +0100

On 21.03.26 19:39, Greg Burd wrote:
> I think that $subject is interesting because it presents an opportunity to reduce the code we maintain and potentially improve performance.  This thread has languished a bit on the list, so I picked it up.  I've tried it out on my local systems (greenfly, unicorn, icarus, macOS, and a Fedora x86_64 laptop I use as my daily driver) using clang, gcc, and MSVC.  It seems to work, I still need to measure performance.
> 
> tested:
>    - Linux x86_64 (GCC 14.3.0)
>    - Linux RISC-V (GCC 13.3.0, Clang 20.1.2)
>    - FreeBSD x86_64 (Clang 19.1.7)
>    - Windows ARM64 (MSVC 2022)
> 
> I realize we're close to the end of the v19 cycle, but one last look couldn't hurt could it?  Attached is "v3" of his patch set.  Is anyone else interested in this? :)

We currently require MSVC 2019, so before this could be accepted, this 
requirement would need to be adjusted (including documentation, 
buildfarm updates, etc.).  Maybe a bit late for that.

---

From: "Greg Burd" <[email-masked]>
Date: Mon, 23 Mar 2026 08:50:02 -0400

On Mon, Mar 23, 2026, at 7:57 AM, Peter Eisentraut wrote:
> buildfarm updates, etc.).

Fair point, it does seem that's the minimum supported version (2022).

I'm not a Microsoft marketplace or tools expert, so I can't gauge how hard it is to require 2022 or if that'd impact too many users of PG today on that platform who choose to use MSVC over gcc or clang.

I have even less insight into what Azure uses for the host OS (Linux, FreeBSD or Windows) running Postgres for their services, but lets say it's Windows and they have a requirement for MSVC when compiling.  I'd bet they could switch to 2022 without too much trouble.  Are there others out there that deploy/depend/use PG on Windows and have a strong bias for MSVC (vs clang or gcc)?  I have no idea.

> Maybe a bit late for that.

It is late, and this isn't a small set of changes.  I'd be curious to know if, other than the buildfarm animals that are Wnidows with MSVC < 2022, the rest would work with this change or not.  I'd also like to get some objective data on performance.

Would it be wasted effort for me to get this patch into a form that could be committed, tested on the farm, then rolled back if needed (a single patch)?  Is that even a thing we'd consider trying out?

Maybe the effort is worth it and we consider this again at the start of v20 development?

best.

-greg

---

From: "Greg Burd" <[email-masked]>
Date: Mon, 23 Mar 2026 10:24:51 -0400

>>> buildfarm updates, etc.).

Hi Tom, thanks for chiming in. :)

> I don't really see why we'd need to do that?  I would expect any such
> patch to cope gracefully with the lack of <stdatomic.h>, so it could
> continue to support older MSVC by falling back to the older code
> paths.  For MSVC in particular, we'd not even need to maintain the
> older code paths for arches other than x86 and ARM.

Fair, and I agree.

> But even disregarding Windows, I'd look with great suspicion on a
> patch that proposes to rip out all that handwritten code in favor of
> requiring <stdatomic.h>.  That'd be putting a great deal of trust in
> code that's not under our control and frankly we have no reason to
> trust yet, especially not from the standpoint of performance rather
> than just minimum functionality.

Yes, I 100% agree.  That is a valid concern.

> Note that the thread title is
> "Trying out <stdatomic.h>", not "We're marrying <stdatomic.h>
> sight-unseen, and there will be no divorce".

This made me laugh, thank you. :)

> So I want to see a
> patch that treats <stdatomic.h> as an alternative implementation,
> not The Only Way.

Got it.

> As for timing, this is the sort of patch that we usually feel should
> go in near the start of a dev cycle, not near the end.  So I counsel
> making sure that it's in shape for commit early in v20, but not
> expecting that it will get in now, even temporarily.  There are too
> many irons in the fire at this phase of the cycle, and too little
> room to disambiguate "Greg broke it" from "somebody else broke it".

Yep, that's prudent and you're right to point out that the breaking the farm isn't really a good way to test at this stage.

best.

-greg