Re: Queries that should be canceled will get stuck on secure_write function

Fujii Masao <masao.fujii@oss.nttdata.com>

From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: Robert Haas <robertmhaas@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: 蔡梦娟(玊于) <mengjuan.cmj@alibaba-inc.com>, pgsql-hackers <pgsql-hackers@lists.postgresql.org>, Andres Freund <andres@anarazel.de>
Date: 2021-08-24T05:14:57Z
Lists: pgsql-hackers
On 2021/08/24 0:26, Alvaro Herrera wrote:
> Aren't we talking about query cancellations that occur in response to a
> standby delay limit?  Those aren't in response to user action.  What I
> mean is that if the standby delay limit is exceeded, then we send a
> query cancel; we expect the standby to cancel its query at that time and
> then the primary can move on.  But if the standby doesn't react, then we
> can have it terminate its connection.

+1


On 2021/08/24 3:45, Robert Haas wrote:
> On Mon, Aug 23, 2021 at 11:26 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>> Aren't we talking about query cancellations that occur in response to a
>> standby delay limit?  Those aren't in response to user action.
> 
> Oh, you're right. But I guess a similar problem could also occur in
> response to pg_terminate_backend(), no?

There seems no problem in that case because pg_terminate_backend() causes
a backend to set ProcDiePending to true in die() signal hander and
ProcessClientWriteInterrupt() called by secure_write() handles ProcDiePending.
No?

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION