Re: Queries that should be canceled will get stuck on secure_write function - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Queries that should be canceled will get stuck on secure_write function
Date
Msg-id CA+TgmoZiZQF5YFLTM_S7TWOy6UKO0639sxDWYOQMYgvHfZ_rMA@mail.gmail.com
Whole thread Raw
In response to Queries that should be canceled will get stuck on secure_write function  ("蔡梦娟(玊于)" <mengjuan.cmj@alibaba-inc.com>)
Responses Re: Queries that should be canceled will get stuck on secure_write function  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Re: Queries that should be canceled will get stuck on secure_write function  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Mon, Aug 23, 2021 at 4:15 AM 蔡梦娟(玊于) <mengjuan.cmj@alibaba-inc.com> wrote:
> I want to know why the interrupt is only handled when ProcDiePending is true, I think query which is supposed to be
canceledalso should respond to the signal. 

Well, if we're halfway through sending a message to the client and we
abort the write, we have no way of re-establishing protocol sync,
right? It's OK to die without sending any more data to the client,
since then the connection is closed anyway and the loss of sync
doesn't matter, but continuing the session doesn't seem workable.

Your proposed patch actually seems to dodge this problem and I think
perhaps we could consider something along those lines. It would be
interesting to hear what Andres thinks about this idea, since I think
he was the last one to rewrite that code.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: "houzj.fnst@fujitsu.com"
Date:
Subject: RE: [BUG] wrong refresh when ALTER SUBSCRIPTION ADD/DROP PUBLICATION
Next
From: Tom Lane
Date:
Subject: Re: Mark all GUC variable as PGDLLIMPORT