| 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>, "Fujii Masao" <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-24 03:59:42 |
| Message-ID: | 0de88f81-4932-4572-a01c-e4041d7be722.mengjuan.cmj@alibaba-inc.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Yes, it is more appropriate to set a duration time to determine whether secure_write() is stuck, but it is difficult to define how long the duration time is.
in my first patch, I add a GUC to allow the user to set the time, or it can be hardcoded if a time deemed reasonable is provided?
------------------------------------------------------------------I agree that something like the patch (i.e., introduction of promotion
from cancel request to terminate one) is necessary for the fix. One concern
on the patch is that the cancel request can be promoted to the terminate one
even when secure_write() doesn't actually get stuck. Is this acceptable?
Maybe I'm tempted to set up the duration until the promotion happens....
Or we should introduce the dedicated timer for communication on the socket?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2021-09-24 03:59:54 | Re: proposal: possibility to read dumped table's name from file |
| Previous Message | Thomas Munro | 2021-09-24 03:32:25 | Re: Atomic rename feature for Windows. |