Npgsql currently has frontend (or socket) timeouts - if a read is stuck on a socket for too long, an exception is raised and the connection is broken. One disadvantage of this is that the backend is left with the running query, at least until it attempts to write some results back (at which point it would bomb due to the closed connection). For cases of which don't produce any results for a long time, this is problematic.
When a socket timeout occurs, we can trigger a cancellation on the connection to resolve this.
Split off from #1344, and also discussed in #1551.
Npgsql currently has frontend (or socket) timeouts - if a read is stuck on a socket for too long, an exception is raised and the connection is broken. One disadvantage of this is that the backend is left with the running query, at least until it attempts to write some results back (at which point it would bomb due to the closed connection). For cases of which don't produce any results for a long time, this is problematic.
When a socket timeout occurs, we can trigger a cancellation on the connection to resolve this.
Split off from #1344, and also discussed in #1551.