Hi, On 2021-08-23 10:13:03 -0400, Robert Haas wrote: > On Mon, Aug 23, 2021 at 4:15 AM 蔡梦娟(玊于) <mengjuan....@alibaba-inc.com> wrote: > > I want to know why the interrupt is only handled when ProcDiePending is > > true, I think query which is supposed to be canceled also should respond to > > the signal. > > Well, if we're halfway through sending a message to the client and we > abort the write, we have no way of re-establishing protocol sync, > right? It's OK to die without sending any more data to the client, > since then the connection is closed anyway and the loss of sync > doesn't matter, but continuing the session doesn't seem workable.
Right. > Your proposed patch actually seems to dodge this problem and I think > perhaps we could consider something along those lines. It would be > interesting to hear what Andres thinks about this idea, since I think > he was the last one to rewrite that code. I think it's a reasonable idea. I have some quibbles with the implementation (new code should be in ProcessClientWriteInterrupt(), not secure_write()), and I suspect we should escalate more quickly to killing the connection, but those seem like details. I think that if we want to tackle this, we need to do the same for secure_read() as well. secure_read() will process interrupts normally while DoingCommandRead, but if we're already in a command, we'd just as well be prevented from processing a !ProcDiePending interrupt. Greetings, Andres Freund