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

On 2021-Aug-23, 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.

Yeah, I agree.

> 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.
>
> Your proposed patch actually seems to dodge this problem and I think
> perhaps we could consider something along those lines.

Do we actually need new GUCs, though? I think we should never let an
unresponsive client dictate what the server does, because that opens the
door for uncooperative or malicious clients to wreak serious havoc. I
think the implementation should wait until time now+X to cancel the
query, but if by time now+2X (or whatever we deem reasonable -- maybe
now+1.1X) we're still waiting, then it's okay to just close the
connection. This suggests a completely different implementation, though.

I wonder if it's possible to write a test for this. We would have to
send a query and then hang the client somehow. I recently added a TAP
test that uses SIGSTOP to a walsender ... can we use SIGSTOP with a
background psql that's running SELECT pg_sleep() perhaps?
(Or maybe it's sufficient to start background psql and not pump() it?)

--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"It takes less than 2 seconds to get to 78% complete; that's a good sign.
A few seconds later it's at 90%, but it seems to have stuck there. Did
somebody make percentages logarithmic while I wasn't looking?"
http://smylers.hates-software.com/2005/09/08/1995c749.html