Re: [EXTERNAL] Re: Add non-blocking version of PQcancel

From: Jelte Fennema <postgres(at)jeltef(dot)nl>
To: Denis Laxalde <denis(dot)laxalde(at)dalibo(dot)com>
Cc: Greg Stark <stark(at)mit(dot)edu>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Gregory Stark (as CFM)" <stark(dot)cfm(at)gmail(dot)com>, Jelte Fennema <Jelte(dot)Fennema(at)microsoft(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Jacob Champion <jchampion(at)timescale(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [EXTERNAL] Re: Add non-blocking version of PQcancel
Date: 2023-03-28 15:54:06
Message-ID: CAGECzQQUw3UFP8ivMYg0tt3-vDscSZMRuwpABjkUO2m9=JUSTA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 28 Mar 2023 at 16:54, Denis Laxalde <denis(dot)laxalde(at)dalibo(dot)com> wrote:
> I had a look into your patchset (v16), did a quick review and played a
> bit with the feature.
>
> Patch 2 is missing the documentation about PQcancelSocket() and contains
> a few typos; please find attached a (fixup) patch to correct these.

Thanks applied that patch and attached a new patchset

> Namely, I wonder why it returns a PGcancelConn and what's the
> point of requiring the user to call PQcancelStatus() to see if something
> got wrong. Maybe it could be defined as:
>
> int PQcancelSend(PGcancelConn *cancelConn);
>
> where the return value would be status? And the user would only need to
> call PQcancelErrorMessage() in case of error. This would leave only one
> single way to create a PGcancelConn value (i.e. PQcancelConn()), which
> seems less confusing to me.

To clarify what you mean, the API would then be like this:
PGcancelConn cancelConn = PQcancelConn(conn);
if (PQcancelSend(cancelConn) == CONNECTION_BAD) {
printf("ERROR %s\n", PQcancelErrorMessage(cancelConn))
exit(1)
}

Instead of:
PGcancelConn cancelConn = PQcancelSend(conn);
if (PQcancelStatus(cancelConn) == CONNECTION_BAD) {
printf("ERROR %s\n", PQcancelErrorMessage(cancelConn))
exit(1)
}

Those are so similar, that I have no preference either way. If more
people prefer one over the other I'm happy to change it, but for now
I'll keep it as is.

> As part of my testing, I've implemented non-blocking cancellation in
> Psycopg, based on v16 on this patchset. Overall this worked fine and
> seems useful; if you want to try it:
>
> https://github.com/dlax/psycopg3/tree/pg16/non-blocking-pqcancel

That's great to hear! I'll try to take a closer look at that change tomorrow.

> (The only thing I found slightly inconvenient is the need to convey the
> connection encoding (from PGconn) when handling error message from the
> PGcancelConn.)

Could you expand a bit more on this? And if you have any idea on how
to improve the API with regards to this?

Attachment Content-Type Size
v17-0002-Copy-and-store-addrinfo-in-libpq-owned-private-m.patch application/octet-stream 11.6 KB
v17-0005-Start-using-new-libpq-cancel-APIs.patch application/octet-stream 9.2 KB
v17-0003-Return-2-from-pqReadData-on-EOF.patch application/octet-stream 4.3 KB
v17-0004-Add-non-blocking-version-of-PQcancel.patch application/octet-stream 44.6 KB
v17-0001-libpq-Run-pgindent-after-a9e9a9f32b3.patch application/octet-stream 22.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message gkokolatos 2023-03-28 16:07:30 Re: Add LZ4 compression in pg_dump
Previous Message Tomas Vondra 2023-03-28 15:25:49 Re: Memory leak from ExecutorState context?