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