| From: | "Greg Burd" <greg(at)burd(dot)me> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Peter Eisentraut" <peter(at)eisentraut(dot)org>, "Thomas Munro" <thomas(dot)munro(at)gmail(dot)com>, "PostgreSQL Hackers" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Trying out <stdatomic.h> |
| Date: | 2026-03-23 14:24:51 |
| Message-ID: | ec57c6d3-a14c-4b52-8309-4ef8c6a79f80@app.fastmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Mar 23, 2026, at 10:13 AM, Tom Lane wrote:
> "Greg Burd" <greg(at)burd(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2026-03-23 14:33:10 | Re: Avoid use of TopMemoryContext for resource owner cleanup in portals |
| Previous Message | Bharath Rupireddy | 2026-03-23 14:24:23 | Re: Add logical_decoding_spill_limit to cap spill file disk usage per slot |