Yes, it is more appropriate to set a duration time to determine whether
secure_write() is stuck, but it is difficult to define how long the duration
time is.
in my first patch, I add a GUC to allow the user to set the time, or it can be
hardcoded if a time deemed reasonable is provided?
-
On 2021/09/22 1:14, 蔡梦娟(玊于) wrote:
Hi all, I want to know your opinion on this patch, or in what way do you think
we should solve this problem?
I agree that something like the patch (i.e., introduction of promotion
from cancel request to terminate one) is necessary for the fix. One concern
：回复：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
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
I add a test to reproduce the problem, you can see the attachment for specific
content
during the last sleep time of the test, use pstack to get the stack of the
backend process, which is as follows:
#0 0x7f6ebdd744d3 in __epoll_wait_nocancel () from /lib64/libc.so.6
#1 0x007738d
Yes, pg_terminate_backend() can terminate the connection successfully in this
case because ProcDiePending is set as true and ProcessClientWriteInterrupt()
can handle it.
Queries those exceed standby delay limit can be terminated in this way, but
what about other queries that should be canceled
