public inbox for [email protected]  

help / color / mirror / Atom feed

From: Heikki Linnakangas <[email protected]>
To: Thomas Munro <[email protected]>
To: Jelte Fennema-Nio <[email protected]>
Cc: Bryan Green <[email protected]>
Cc: pgsql-hackers <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Kyotaro Horiguchi <[email protected]>
Subject: Re: Can we get rid of TerminateThread() in pg_dump?
Date: Tue, 7 Jul 2026 00:11:54 +0300
Message-ID: <[email protected]> (raw)
In-Reply-To: <CA+hUKGJ3WNcqtj0xt8k9cnBRTEjAPkT4QrQrAbEgO6T7fUfPXA@mail.gmail.com>
References: <CA+hUKGJgO=o-vLFahGdR2WesuX3h1-0j=a8z72fChc-MG1Hveg@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<CA+hUKGL0ZeiO0ND+ksAi5inRY98GEGtyM4t8CVhF1mZaAqYjVA@mail.gmail.com>
	<[email protected]>
	<CA+hUKGJ3WNcqtj0xt8k9cnBRTEjAPkT4QrQrAbEgO6T7fUfPXA@mail.gmail.com>

On 05/07/2026 08:03, Thomas Munro wrote:
> On Sat, Jul 4, 2026 at 11:15 PM Jelte Fennema-Nio <[email protected]> wrote:
>> On Sat, 4 Jul 2026 at 02:51, Thomas Munro <[email protected]> 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

view thread (18+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Can we get rid of TerminateThread() in pg_dump?
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox