Hi, On 2022-03-24 17:41:53 -0400, Tom Lane wrote: > I kind of feel that this patch is going in the wrong direction. > I do see the need for a version of PQcancel that can encrypt the > transmitted cancel request (and yes, that should work on the backend > side; see recursion in ProcessStartupPacket). I have not seen > requests for a non-blocking version, and this doesn't surprise me. > I feel that the whole non-blocking aspect of libpq probably belongs > to another era when people didn't trust threads.
That's not a whole lot of fun if you think of cases like postgres_fdw (or citus as in Jelte's case), which run inside the backend. Even with just a single postgres_fdw, we don't really want to end up in an uninterruptible PQcancel() that doesn't even react to pg_terminate_backend(). Even if using threads weren't an issue, I don't really buy the premise - most networking code has moved *away* from using dedicated threads for each connection. It just doesn't scale. Leaving PQcancel aside, we use the non-blocking libpq stuff widely ourselves. I think walreceiver, isolationtester, pgbench etc would be *much* harder to get working equally well if there was just blocking calls. If anything, we're getting to the point where purely blocking functionality shouldn't be added anymore. Greetings, Andres Freund
