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
