Message-ID: <faea6e93-32ab-46ad-8caa-4f502cb3e63c@gmail.com>
Date: Fri, 3 Jul 2026 10:35:35 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Can we get rid of TerminateThread() in pg_dump?
To: Heikki Linnakangas <hlinnaka@iki.fi>,
 Thomas Munro <thomas.munro@gmail.com>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
Cc: 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>
Content-Language: en-US
From: Bryan Green <dbryan.green@gmail.com>
In-Reply-To: <56821e0d-bfd5-4619-b13f-12e28c78289b@iki.fi>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/faea6e93-32ab-46ad-8caa-4f502cb3e63c%40gmail.com>
Precedence: bulk

On 7/3/2026 10:05 AM, Heikki Linnakangas wrote:
> On 03/07/2026 06:32, Thomas Munro wrote:
>> Following up on this ancient discussion and resulting commit e652273e...
>>
>> https://www.postgresql.org/message-id/
>> flat/11515.1464961470%40sss.pgh.pa.us#3e78a2af445dd7e566cf499023e8cb97
>>
>> write(fd, ...) locks fd's entry in a user space descriptor table on
>> Windows, so if the terminated thread was also writing to stderr, I am
>> pretty sure it would hang.  Someone with Windows might be able to
>> repro that by hacking the workers to write to stderr a lot?
>> WriteFile(_get_osfhandle(STDERR_FILENO), ...) might avoid that
>> specific issue, but for all I know that's just the tip of the iceberg
>> considering the socket stuff.
>>
>> Apparently this hasn't been a problem in practice.  Error reporting
>> coinciding with ^C must be unlikely?  I'd still like to find a
>> non-evil way to suppress log output, though.  What if we atomically
>> pointed STDERR_FILENO to /dev/null, with dup2()?  I wrote a patch to
>> try that idea out, but I don't have Windows, so I'm sharing this as a
>> curiosity in case anyone wants to try it and/or comment on all this.
>> Or has a better idea.  Preferably that would work on Windows and Unix
>> (if it also used threads).
> 
> Huh, that's pretty hacky. I think we should adopt our usual signal
> handling approach here: Instead of calling PQcancel() from the signal
> handler (or consoleHandler()), just set a global flag, wake up the main
> thread, and perform the cancellation from the main thread. In the worker
> threads, you can refrain from printing the cancellation error if the
> flag is set.
> 
> Dunno how complicated that is to change..
> 
> - Heikki
> 
> 
> 
The main thread is waiting at the select()...waking that from a
different thread is going to be doable but awkward in the current
implementation on Windows (pipe and sockets).

-- 
Bryan Green
EDB: https://www.enterprisedb.com