| From: | 蔡梦娟(玊于) <mengjuan(dot)cmj(at)alibaba-inc(dot)com> |
|---|---|
| To: | "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Andres Freund" <andres(at)anarazel(dot)de>, "alvherre" <alvherre(at)alvh(dot)no-ip(dot)org>, "masao(dot)fujii" <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
| Cc: | "pgsql-hackers" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | 回复：Queries that should be canceled will get stuck on secure_write function |
| Date: | 2021-09-09 09:38:06 |
| Message-ID: | 3dcd261f-3f6e-4cb8-9734-b7d3a1ff10fd.mengjuan.cmj@alibaba-inc.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
In the attached patch, I also add a tap test to generate a recovery conflict on a standby during the backend process is stuck on client write, check whether it can handle the cancel query request due to recovery conflict.
what do you think of it, hope to get your reply
Thanks & Best Regards
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Handle-cancel-interrupts-during-client-readwrite.patch | application/octet-stream | 8.2 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Aleksander Alekseev | 2021-09-09 09:48:37 | Re: [PATCH] Proof of concept for GUC improvements |
| Previous Message | Ronan Dunklau | 2021-09-09 09:15:36 | Re: Proposal: More structured logging |