On Fri, Apr 9, 2021 at 6:36 AM Michael Paquier <michael@paquier.xyz> wrote:
>
> On Fri, Apr 09, 2021 at 01:11:35AM +0800, Julien Rouhaud wrote:
> > On Thu, Apr 08, 2021 at 07:04:01PM +0200, Fabien COELHO wrote:
> >> It is definitely a open item. I'm not sure where you want to add it…
> >> possibly the "Pg 14 Open Items" wiki page?
> >
> > Correct.
>
> I was running a long query this morning and wondered why the
> cancellation was suddenly broken. So I am not alone, and here you are
> with already a solution :)
>
> So, studying through 3a51306, this stuff has changed the query
> execution from a sync PQexec() to an async PQsendQuery(). And the
> proposed fix changes back to the behavior where the cancellation
> reset happens after getting a result, as there is no need to cancel
> anything.
>
> No strong objections from here if the consensus is to make
> SendQueryAndProcessResults() handle the cancel reset properly though I
> am not sure if this is the cleanest way to do things, but let's make
> at least the whole business consistent in the code for all those code
> paths. For example, PSQLexecWatch() does an extra ResetCancelConn()
> that would be useless once we are done with
> SendQueryAndProcessResults(). Also, I can see that
> SendQueryAndProcessResults() would not issue a cancel reset if the
> query fails, for \watch when cancel is pressed, and for \watch with
> COPY. So, my opinion here would be to keep ResetCancelConn() within
> PSQLexecWatch(), just add an extra one in SendQuery() to make all the
> three code paths printing results consistent, and leave
> SendQueryAndProcessResults() out of the cancellation logic.
Hi, I'm also facing the query cancellation issue, I have to kill the
backend everytime to cancel a query, it's becoming difficult.
With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com
