Re: Queries that should be canceled will get stuck on secure_write function

Hi,

On 2021-08-23 10:13:03 -0400, Robert Haas wrote:
> On Mon, Aug 23, 2021 at 4:15 AM 蔡梦娟(玊于) <mengjuan(dot)cmj(at)alibaba-inc(dot)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