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

From Fujii Masao
Subject Re: Queries that should be canceled will get stuck on secure_write function
Date
Msg-id 042d38b9-c2d6-0424-1dd4-76df5ed20e30@oss.nttdata.com
Whole thread Raw
In response to Re: Queries that should be canceled will get stuck on secure_write function  (Robert Haas <robertmhaas@gmail.com>)
Responses 回复:Queries that should be canceled will get stuck on secure_write function
Re: Queries that should be canceled will get stuck on secure_write function
List 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



pgsql-hackers by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: Mark all GUC variable as PGDLLIMPORT
Next
From: Craig Ringer
Date:
Subject: Re: Mark all GUC variable as PGDLLIMPORT