Message-ID: <400c93d2-0b81-4a0b-ac60-0fd6512d5b5d@iki.fi>
Date: Tue, 7 Jul 2026 00:23:42 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Can we get rid of TerminateThread() in pg_dump?
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Thomas Munro <thomas.munro@gmail.com>,
 Jelte Fennema-Nio <postgres@jeltef.nl>
Cc: Bryan Green <dbryan.green@gmail.com>,
 pgsql-hackers <pgsql-hackers@postgresql.org>, Tom Lane <tgl@sss.pgh.pa.us>,
 Kyotaro Horiguchi <horikyota.ntt@gmail.com>
References: 
 <CA+hUKGJgO=o-vLFahGdR2WesuX3h1-0j=a8z72fChc-MG1Hveg@mail.gmail.com>
 <56821e0d-bfd5-4619-b13f-12e28c78289b@iki.fi>
 <faea6e93-32ab-46ad-8caa-4f502cb3e63c@gmail.com>
 <CA+hUKGL0ZeiO0ND+ksAi5inRY98GEGtyM4t8CVhF1mZaAqYjVA@mail.gmail.com>
 <DJPQS3FYSD4U.3DBTXA6U8IQ0Q@jeltef.nl>
 <CA+hUKGJ3WNcqtj0xt8k9cnBRTEjAPkT4QrQrAbEgO6T7fUfPXA@mail.gmail.com>
 <5e4a28ec-d5e1-4817-889c-b8aefe5f48ed@iki.fi>
Content-Language: en-US
In-Reply-To: <5e4a28ec-d5e1-4817-889c-b8aefe5f48ed@iki.fi>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/400c93d2-0b81-4a0b-ac60-0fd6512d5b5d%40iki.fi>
Precedence: bulk

On 07/07/2026 00:11, Heikki Linnakangas wrote:
> 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.

In this case, though, I think all we need is a "volatile sigatomic_t" 
flag. Sending the query cancellation over the network surely acts as a 
full compiler and memory barrier in the cancelling thread. And similarly 
receiving the error message from the network acts as a full barrier in 
the other threads that might receive the cancellation error from the 
backend.

- Heikki