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
