Ugh, it indeed seems like I somehow messed up sending the new patch.
Here's the correct one.
0001-Add-non-blocking-version-of-PQcancel.patch
Description: 0001-Add-non-blocking-version-of-PQcancel.patch
On 10/5/22 06:23, Jelte Fennema wrote:
> In my first version of this patch, this is exactly what I did. But then
> I got this feedback from Jacob, so I changed it to reusing PGconn:
>
>> [snip]
>
> I changed it back to use PGcancelConn as per your suggestion and I
> agree that the API got
Thanks for all the feedback. I attached a new patch that I think
addresses all of it. Below some additional info.
> On the whole it feels like a mistake to have two separate kinds of
> PGconn with fundamentally different behaviors and yet no distinction
> in the API. I think I'd recommend having
Jelte Fennema writes:
> [ non-blocking PQcancel ]
I pushed the 0001 patch (libpq_pipeline documentation) with a bit
of further wordsmithing.
As for 0002, I'm not sure that's anywhere near ready. I doubt it's
a great idea to un-deprecate PQrequestCancel with a major change
in its behavior. If
On 2022-Jun-27, Justin Pryzby wrote:
> On Fri, Jun 24, 2022 at 07:36:16PM -0500, Justin Pryzby wrote:
> > Apparently there's still an occasional issue.
> > https://cirrus-ci.com/task/6613309985128448
>
> I think that failure is actually not related to this patch.
Yeah, it's not -- Kyotaro
On Fri, Jun 24, 2022 at 07:36:16PM -0500, Justin Pryzby wrote:
> Resending with a problematic email removed from CC...
>
> On Mon, Apr 04, 2022 at 03:21:54PM +, Jelte Fennema wrote:
> > 2. Added some extra sleeps to the cancellation test, to remove random
> > failures on FreeBSD.
>
>
(resent because it was blocked from the mailing-list due to inclusion of a
blocked email address in the To line)
From: Andres Freund
> On 2022-04-04 15:21:54 +, Jelte Fennema wrote:
> > 2. Added some extra sleeps to the cancellation test, to remove random
> > failures on FreeBSD.
>
>
Resending with a problematic email removed from CC...
On Mon, Apr 04, 2022 at 03:21:54PM +, Jelte Fennema wrote:
> 2. Added some extra sleeps to the cancellation test, to remove random
> failures on FreeBSD.
Apparently there's still an occasional issue.
Hereby what I consider the final version of this patch. I don't have any
changes planned myself (except for ones that come up during review).
Things that changed since the previous iteration:
1. postgres_fdw now uses the non-blocking cancellation API (including test).
2. Added some extra sleeps
Attached is the latest version of this patch, which I think is now in a state
in which it could be merged. The changes are:
1. Don't do host and address discovery for cancel connections. It now
reuses raddr and whichhost from the original connection. This makes
sure the cancel always goes
Note that the patch is still variously failing in cirrus.
https://cirrus-ci.com/github/postgresql-cfbot/postgresql/commitfest/37/3511
You may already know that it's possible to trigger the cirrus ci tasks using a
github branch. See src/tools/ci/README.
I attached a new version of this patch. Which does three main things:
1. Change the PQrequestCancel implementation to use the regular
connection establishement code, to support all connection options
including encryption.
2. Add PQrequestCancelStart which is a thread-safe and
Thanks for all the feedback everyone. I'll try to send a new patch
later this week that includes user facing docs and a simplified API.
For now a few responses:
> Yeah. We need to choose a name for these new function(s) that is
> sufficiently different from "PQcancel" that people won't expect
Robert Haas writes:
> Well, that's a fair point, but it's somewhat orthogonal to the one I'm
> making, which is that a non-blocking version of function X might be
> expected to share code or at least functionality with X itself. Having
> something that is named in a way that implies asynchrony
On Fri, Mar 25, 2022 at 2:47 PM Tom Lane wrote:
> I think you misunderstand where the real pain point is. The reason
> that PQcancel's functionality is so limited has little to do with
> blocking vs non-blocking, and everything to do with the fact that
> it's designed to be safe to call from a
Robert Haas writes:
> That said, I don't think that this particular patch is going in the
> right direction. I think Jacob's comment upthread is right on point:
> "This seems like a big change compared to PQcancel(); one that's not
> really hinted at elsewhere. Having the async version of an API
On Thu, Mar 24, 2022 at 6:49 PM Andres Freund wrote:
> 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()
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
Jacob Champion writes:
> On Thu, 2022-01-13 at 14:51 +, Jelte Fennema wrote:
>> 2. Cancel connections benefit automatically from any improvements made
>> to the normal connection establishment codepath. Examples of things
>> that it currently gets for free currently are TLS support and
>>
On Thu, 2022-01-13 at 14:51 +, Jelte Fennema wrote:
> Attached is an updated patch which I believe fixes windows and the other test
> failures.
> At least on my machine make check-world passes now when compiled with
> --enable-tap-tests
>
> I also included a second patch which adds some
Attached is an updated patch which I believe fixes windows and the other test
failures.
At least on my machine make check-world passes now when compiled with
--enable-tap-tests
I also included a second patch which adds some basic documentation for the
libpq tests.
Hi,
On 2022-01-12 15:22:18 +, Jelte Fennema wrote:
> This patch also includes a test for this new API (and also the already
> existing cancellation APIs). The test can be easily run like this:
>
> cd src/test/modules/libpq_pipeline
> make && ./libpq_pipeline cancel
Right now tests
The existing PQcancel API is using blocking IO. This makes PQcancel
impossible to use in an event loop based codebase, without blocking the
event loop until the call returns.
This patch adds a new cancellation API to libpq which is called
PQcancelConnectionStart. This API can be used to send
101 - 123 of 123 matches
Mail list logo
