On 08/02/2026 21:05, Jelte Fennema-Nio wrote:
> On Sun Dec 14, 2025 at 3:40 PM CET, Jelte Fennema-Nio wrote:
>> A bunch of frontend tools, including psql, still used PQcancel to send
>> cancel requests to the server. That function is insecure, because it
>> does not use encryption to send the cancel request. This starts using
>> the new cancellation APIs (introduced in 61461a300) for all these
>> frontend tools.
>
> Small update. Split up the fe_utils and pg_dump changes into separate
> commits, to make patches easier to review. Also use non-blocking writes
> to the self-pipe from the signal handler to avoid potential deadlocks
> (extremely unlikely for such blocks to occur, but better safe than sorry).
Had a brief look at this:
It took me a while to get the big picture of how this works. cancel.c
could use some high-level comments explaining how to use the facility;
it's a real mixed bag right now.
The SIGINT handler now does three things:
- Set CancelRequested global variable,
- call callback if set, and
- wake up the cancel thread to send the cancel message, if cancel
connection is set.
There's no high-level overview documentation or comments on how those
three mechanism work or interact. It took me a while to understand that
they are really separate, alternative ways to handle SIGINT, all mashed
into the same signal handler function. At first read, I thought they're
somehow part of the one same mechanism.
The cancelConn mechanism is a global variable, which means that it can
only be used with one connection in the process. That's OK with the
current callers, but seems short-sighted. What if we wanted to use it
for pgbench, for example, which uses multiple threads and connections?
Or if we changed pg_dump to use multiple threads, like you also
suggested as a possible follow-up.
The "self-pipe trick" usually refers to interrupting the main thread
from select(); this uses it to wake up the other, separate cancellation
thread. That's fine, but again it took me a while to understand that
that's what it does. Comments!
This is racy, if the cancellation thread doesn't immediately process the
wakeup. For example, because it's still busy processing a previous
wakeup, because there's a network hiccup or something. By the time the
cancellation thread runs, the main thread might already be running a
different query than it was when the user hit CTRL-C.
- Heikki
