On Fri, Apr 9, 2021 at 6:36 AM Michael Paquier <mich...@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
