Horton

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

Thomas Munro <thomas.munro@gmail.com>

View thread View on postgr.es
From: Thomas Munro <thomas.munro@gmail.com>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Jelte Fennema-Nio <postgres@jeltef.nl>, 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>
Date: 2026-07-07T23:40:23Z
Lists: pgsql-hackers 
On Tue, Jul 7, 2026 at 9:23 AM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> 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.

You're right.  So basically Jelte's patch, except it doesn't need the
Win32 atomics stuff, just volatile, and a comment to explain that
assumption.  (Then some later version could use an explicit barrier
instead of a comment, I guess, just to be clearer.)

Commits

  1. Redesign handling of SIGTERM/control-C in parallel pg_dump/pg_restore.