On 15/03/2026 17:09, Jelte Fennema-Nio wrote:
On Fri Mar 6, 2026 at 8:51 PM CET, Heikki Linnakangas wrote:
I worry how this behaves if establishing the cancel connection gets
stuck for a long time. Because of a network hiccup, for example.
That's also not a new problem though; it's perhaps even worse today,
if the signal handler gets stuck for a long time, trying to establish
the connection. Still, would be good to do some testing with a bad
network.
After thinking on this again, I thought of a much easier solution to
this problem than the direction I was exploring in my previous response
to this: We can have SetCancelConn() and ResetCancelConn() wait for any
pending
cancel to complete before letting them replace/remove the cancelConn.
That way even in case of a bad network, we know that an already
in-flight cancel request will never cancel a query from a next
SetCancelConn() call. It does mean that you cannot submit a new query
before we've received a response to the in-flight cancel request (either
because the hiccup is reselved or because TCP timeouts report a
failure). That's the current behaviour too with running PQcancel in the
signal handler, and I also think that's the behaviour that makes the
most sense.
+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().
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.
- Heikki
