Re: Can we get rid of TerminateThread() in pg_dump?

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