| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | 蔡梦娟(玊于) <mengjuan(dot)cmj(at)alibaba-inc(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de> |
| Subject: | Re: Queries that should be canceled will get stuck on secure_write function |
| Date: | 2021-08-23 14:13:03 |
| Message-ID: | CA+TgmoZiZQF5YFLTM_S7TWOy6UKO0639sxDWYOQMYgvHfZ_rMA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
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.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2021-08-23 14:15:04 | Re: Mark all GUC variable as PGDLLIMPORT |
| Previous Message | Bruce Momjian | 2021-08-23 14:07:16 | Re: Mark all GUC variable as PGDLLIMPORT |