Обсуждение: Trying out

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.

On 10/11/2025 15:17, Thomas Munro wrote:
> 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.

>  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.

> 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.

Makes sense.

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

- Heikki

Heikki Linnakangas <hlinnaka@iki.fi> writes:
> The patch removes 'src/template/solaris'. Is that on purpose? Is that an 
> independent cleanup that could be committed immediately?

Our four Solaris+illumos buildfarm animals would be sad.

            regards, tom lane

On Tue, Nov 11, 2025 at 4:19 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Heikki Linnakangas <hlinnaka@iki.fi> writes:
> > The patch removes 'src/template/solaris'. Is that on purpose? Is that an
> > independent cleanup that could be committed immediately?
>
> 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.

On Tue, Nov 11, 2025 at 2:57 AM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> > [PATCH v1 1/4] Add some missing #include <limits.h>.
>
> 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/

On 13.11.25 12:35, Thomas Munro wrote:
> 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.)

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.

Hi Thomas,

> 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.)

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

On Thu, Nov 20, 2025 at 12:23 AM Peter Eisentraut <peter@eisentraut.org> wrote:
> On 13.11.25 12:35, Thomas Munro wrote:
> > 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.)
>
> Note also that we still have buildfarm members with gcc <4.9, which is
> 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

On Thu, Nov 20, 2025 at 3:03 AM Aleksander Alekseev
<aleksander@tigerdata.com> wrote:
> 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.

Thanks for testing!

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

On Mon, Nov 10, 2025, at 10:19 AM, Tom Lane wrote:
> Heikki Linnakangas <hlinnaka@iki.fi> writes:
>> The patch removes 'src/template/solaris'. Is that on purpose? Is that an 
>> independent cleanup that could be committed immediately?
>
> Our four Solaris+illumos buildfarm animals would be sad.
>
>             regards, tom lane

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

-greg

On Mon, Nov 10, 2025, at 8:17 AM, Thomas Munro wrote:
> 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.
>
> 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
topof 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

"Greg Burd" <greg@burd.me> writes:
> I have another Illumos animal in the works, but if the plan is to deprecate that platform I can set that aside.  As
anold Sun engineer I hate to see it disappear, but it is basically EOL at this point. 

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

On 2025-Nov-23, Tom Lane wrote:

> "Greg Burd" <greg@burd.me> writes:
> > I have another Illumos animal in the works, but if the plan is to deprecate that platform I can set that aside.  As
anold Sun engineer I hate to see it disappear, but it is basically EOL at this point.
 
> 
> 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.

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/

On Mon, Nov 24, 2025 at 6:02 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Greg Burd" <greg@burd.me> writes:
> > I have another Illumos animal in the works, but if the plan is to deprecate that platform I can set that aside.  As
anold Sun engineer I hate to see it disappear, but it is basically EOL at this point. 
>
> 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.

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.

On Mon, Nov 24, 2025 at 4:23 AM Greg Burd <greg@burd.me> 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
topof 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 */

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.

On Nov 23 2025, at 4:08 pm, Thomas Munro <thomas.munro@gmail.com> wrote:

> On Mon, Nov 24, 2025 at 4:23 AM Greg Burd <greg@burd.me> 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
>>
>>         /*
>>          * 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 */
>
> 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...

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.

>> 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?

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.

> 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.

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
> 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.

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

best.

-greg

Hey Thomas, hackers,

I think that $subject is interesting because it presents an opportunity to reduce the code we maintain and potentially
improveperformance.  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
patchset.  Is anyone else interested in this? :)
 

best.

-greg

> best.
>
> -greg

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
potentiallyimprove performance.  This thread has languished a bit on the list, so I picked it up.  I've tried it out on
mylocal 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
patchset.  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.

On Mon, Mar 23, 2026, at 7:57 AM, Peter Eisentraut wrote:
> 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
potentiallyimprove performance.  This thread has languished a bit on the list, so I picked it up.  I've tried it out on
mylocal 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
hispatch 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.).

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
toomany 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
2022without too much trouble.  Are there others out there that deploy/depend/use PG on Windows and have a strong bias
forMSVC (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
areWnidows 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
backif 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

"Greg Burd" <greg@burd.me> writes:
> On Mon, Mar 23, 2026, at 7:57 AM, Peter Eisentraut wrote:
>> We currently require MSVC 2019, so before this could be accepted, this 
>> requirement would need to be adjusted (including documentation, 
>> buildfarm updates, etc.).

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

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.

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.  Note that the thread title is
"Trying out <stdatomic.h>", not "We're marrying <stdatomic.h>
sight-unseen, and there will be no divorce".  So I want to see a
patch that treats <stdatomic.h> as an alternative implementation,
not The Only Way.

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".

            regards, tom lane

On Mon, Mar 23, 2026, at 10:13 AM, Tom Lane wrote:
> "Greg Burd" <greg@burd.me> writes:
>> On Mon, Mar 23, 2026, at 7:57 AM, Peter Eisentraut wrote:
>>> We currently require MSVC 2019, so before this could be accepted, this 
>>> requirement would need to be adjusted (including documentation, 
>>> buildfarm updates, etc.).
>

Hi Tom, thanks for chiming in. :)

>> Fair point, it does seem that's the minimum supported version (2022).
>
> 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.

>             regards, tom lane

best.

-greg