Re: Can we get rid of TerminateThread() in pg_dump? - Mailing list pgsql-hackers

From Jelte Fennema-Nio
Subject Re: Can we get rid of TerminateThread() in pg_dump?
Date
Msg-id DJPQS3FYSD4U.3DBTXA6U8IQ0Q@jeltef.nl
Whole thread
In response to Re: Can we get rid of TerminateThread() in pg_dump?  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Can we get rid of TerminateThread() in pg_dump?
Re: Can we get rid of TerminateThread() in pg_dump?
List pgsql-hackers
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?

To be clear, I do think we should stop using TerminateThread because I
wanna replace PQcancel there with PQcancelBlocking[1] PQcancelBlocking
does a whole TLS handshake, which is almost certainly taking some locks.

Note that the way to achieve that I moved the Ctrl+C handler to a
dedicated thread on Unix too, so it starts behaving the same as Windows
in that respect. I think combined with you changing pg_dump to use
worker *threads* on Unix too, we would then get pretty much identical
behaviour across OSes for pg_dump.

P.S. I now realize that anything involving the (already existing)
CancelRequested flag is actually not actually safe/correct on Windows,
because it's not using read nor written using atomic operations while
the consoleHandler runs on its own thread. Would be good to fix that too
I guess, but it seems that for now it has worked in practice at least.

[1]: https://www.postgresql.org/message-id/flat/DJPAH0WPJV3K.1PYZ8P0QXZVMX%40jeltef.nl#5642e337a4e4d04b21c66e089484f80d

Attachment

pgsql-hackers by date:

Previous
From: Jim Jones
Date:
Subject: Re: Truncate logs by max_log_size
Next
From: Dilip Kumar
Date:
Subject: Re: Proposal: Conflict log history table for Logical Replication