Re: Queries that should be canceled will get stuck on secure_write function
От | Fujii Masao |
---|---|
Тема | Re: Queries that should be canceled will get stuck on secure_write function |
Дата | |
Msg-id | 042d38b9-c2d6-0424-1dd4-76df5ed20e30@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: Queries that should be canceled will get stuck on secure_write function (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
回复: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 |
Список | 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 по дате отправления: