Re: Add non-blocking version of PQcancel

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jacob Champion <pchampion(at)vmware(dot)com>, "Jelte(dot)Fennema(at)microsoft(dot)com" <Jelte(dot)Fennema(at)microsoft(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Add non-blocking version of PQcancel
Date: 2022-03-24 22:49:09
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


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.


Andres Freund

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2022-03-24 22:51:30 Re: SQL/JSON: functions
Previous Message David Christensen 2022-03-24 22:40:30 Re: [PATCH] add relation and block-level filtering to pg_waldump