Date: Thu, 24 Mar 2022 15:49:09 -0700
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jacob Champion <pchampion@vmware.com>,
	"Jelte.Fennema@microsoft.com" <Jelte.Fennema@microsoft.com>,
	pgsql-hackers@lists.postgresql.org
Subject: Re: Add non-blocking version of PQcancel
Message-ID: <20220324224909.4tnubqv2owmfoyoc@alap3.anarazel.de>
References: 
 <AM5PR83MB0178D3B31CA1B6EC4A8ECC42F7529@AM5PR83MB0178.EURPRD83.prod.outlook.com>
 <20220113004411.3tdgiqdmmo4musb5@alap3.anarazel.de>
 <AM5PR83MB0178CE0CEB690F1C041355B7F7539@AM5PR83MB0178.EURPRD83.prod.outlook.com>
 <b6e02c2ef43a4c8dcbca03dd677ae8331c892175.camel@vmware.com>
 <3150365.1648158113@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3150365.1648158113@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/20220324224909.4tnubqv2owmfoyoc%40alap3.anarazel.de>
Precedence: bulk

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