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

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
Cc: Denis Laxalde <denis(dot)laxalde(at)dalibo(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, 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>, 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: 2024-03-12 09:19:27
Message-ID: 202403120919.fxltdpmxq4u4@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Here's a last one for the cfbot.

I have a question about this one

PQcancelStart(PGcancelConn *cancelConn)
if (cancelConn->conn.status != CONNECTION_ALLOCATED)
"cancel request is already being sent on this connection");
cancelConn->conn.status = CONNECTION_BAD;
return 0;

If we do this and we see conn.status is not ALLOCATED, meaning a cancel
is already ongoing, shouldn't we leave conn.status alone instead of
changing to CONNECTION_BAD? I mean, we shouldn't be juggling the elbow
of whoever's doing that, should we? Maybe just add the error message
and return 0?

Álvaro Herrera PostgreSQL Developer —
"If it is not right, do not do it.
If it is not true, do not say it." (Marcus Aurelius, Meditations)

Attachment Content-Type Size
v34-0001-libpq-Add-encrypted-and-non-blocking-query-cance.patch text/x-diff 48.2 KB
v34-0002-Start-using-new-libpq-cancel-APIs.patch text/x-diff 10.7 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Himanshu Upadhyaya 2024-03-12 09:41:58 Re: remaining sql/json patches
Previous Message Alexander Lakhin 2024-03-12 09:00:00 Re: Spurious pgstat_drop_replslot() call