On 05/07/2026 08:03, Thomas Munro wrote:
> On Sat, Jul 4, 2026 at 11:15 PM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
>> On Sat, 4 Jul 2026 at 02:51, Thomas Munro <thomas.munro@gmail.com> wrote:
>>> We don't actually care about the threads
>>> themselves, and it doesn't seem that great if we have to introduce an
>>> IPC ping-pong of some kind with each thread.
>>
>> Agreed. But I do agree with Heikki that swapping out stderr seems pretty
>> hacky. At the very least because now the main thread cannot write to
>> stderr either anymore (which is why you removed the "terminated by user"
>> write I guess).
>>
>> How about instead we do something like the attached?
>
> That's definitely nicer, if we know that all potential error logging
> caused by cancellation happens in a context that can check the flag.
+1, much nicer!
> I didn't even look into that, because I was deliberately trying to
> avoid needing atomics from here, because I need this to work on Unix
> too, and I didn't want to open too many cans of worms at the same
> time. Hence the appeal of a simple async-signal-safe system call that
> has the right concurrency properties already and works also on Windows
> without a separate code path. But... reaching for the can opener...
>
> 1. If we're ready to drop VS < 2022 and GCC < 4.9, we could just use
> <stdatomic.h> directly in frontend code (independently of the project
> to use it in the backend).
> 2. If we're not ready yet we could make "port/atomics.h" or selected
> parts of it frontend-allowed.
> 3. Maybe all we really need for this case is memory barriers, and we
> could move those out to a frontend-allowed header.
To be honest, I didn't realize we didn't allow "port/atomics.h" in
frontend code. I think spinlock-simulated 64-bit atomics is the only
thing that wouldn't just work.
- Heikki
