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

From 蔡梦娟(玊于)
Subject 回复:Queries that should be canceled will get stuck on secure_write function
Date
Msg-id 737f86a2-a387-4e29-b4c3-1dc22ca3211d.mengjuan.cmj@alibaba-inc.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
List pgsql-hackers
Hi all, I want to know your opinion on this patch, or in what way do you think we should solve this problem?
------------------------------------------------------------------
发件人:蔡梦娟(玊于) <mengjuan.cmj@alibaba-inc.com>
发送时间:2021年9月9日(星期四) 17:38
收件人:Robert Haas <robertmhaas@gmail.com>; Andres Freund <andres@anarazel.de>; alvherre <alvherre@alvh.no-ip.org>; masao.fujii <masao.fujii@oss.nttdata.com>
抄 送:pgsql-hackers <pgsql-hackers@lists.postgresql.org>
主 题:回复:Queries that should be canceled will get stuck on secure_write function


I changed the implementation about this problem:
a) if the cancel query interrupt is from db for some reason, such as recovery conflict, then handle it immediately, and cancel request is treated as terminate request;
b) if the cancel query interrupt is from client, then ignore as original way

In the attached patch, I also add a tap test to generate a recovery conflict on a standby during the backend process is stuck on client write, check whether it can handle the cancel query request due to recovery conflict.

what do you think of it, hope to get your reply

Thanks & Best Regards


Attachment

pgsql-hackers by date:

Previous
From: "Bossart, Nathan"
Date:
Subject: Re: Deduplicate code updating ControleFile's DBState.
Next
From: Pavel Stehule
Date:
Subject: Re: proposal: possibility to read dumped table's name from file