Re: Don't use the deprecated and insecure PQcancel in our frontend tools anymore

On Mon, 16 Mar 2026 at 10:57, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> +1. With a little extra effort, the cancellation can be made abortable
> too, so that you don't need to wait for the TCP timeout. I.e when
> ResetCancelConn() is called, the cancellation thread can immediately
> call PQcancelReset().

I agree we could do that, but I don't think we should. Then we'd be
getting into the exact situation where psql doesn't wait for an already
in-flight cancel request to be processed by the server before sending
the next query. i.e. while this would be fine if there's a network
issue, it would be bad if the server is just slow to respond to the
cancel request (e.g. because there's a PgBouncer in the middle that
hasn't forwarded the request yet).

> One a different topic, is there any guarantee on which thread will
> receive the SIGINT? It matters because psql's cancel callback sometimes
> calls longjmp(), which assumes that the signal handler is executed in
> the main thread.

Good point, I had thought about whether this mattered, but hadn't
considered the callbacks. Attached is v7 that makes sure the signal is
always handled by the main thread by blocking SIGINT before creating the
cancel thread.

I manually tested that this works by sending signals to specific threads
using htop, and logging thread the id from the signal handler. Before
this change the thread id would be from different threads, after this
change it's always from the same one.