| From: | Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> |
|---|---|
| To: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Noah Misch <noah(at)leadboat(dot)com>, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, Denis Laxalde <denis(dot)laxalde(at)dalibo(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, "Gregory Stark (as CFM)" <stark(dot)cfm(at)gmail(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> |
| Subject: | Re: [EXTERNAL] Re: Add non-blocking version of PQcancel |
| Date: | 2024-08-31 07:08:51 |
| Message-ID: | CAGECzQQM1N0H3e9RbSqi4=mmFgfLaFNr6R7gNpFoePb9exRryg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, 31 Aug 2024 at 06:04, Alexander Lakhin <exclusion(at)gmail(dot)com> wrote:
> At the same time, mylodon confirmed my other finding at [1] and failed [2] with:
> -ERROR: canceling statement due to statement timeout
> +ERROR: canceling statement due to user request
>
> [1] https://www.postgresql.org/message-id/4db099c8-4a52-3cc4-e970-14539a319466%40gmail.com
> [2] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mylodon&dt=2024-08-30%2023%3A03%3A31
Interestingly that's a different test that failed, but it looks like
it failed for the same reason that my 0002 patch fixes.
I also took a quick look at the code again, and completely removing
the outstanding interrupt seems hard to do. Because there's no way to
know if there were multiple causes for the interupt, i.e. someone
could have pressed ctrl+c as well and we wouldn't want to undo that.
So I think the solution in 0002, while debatable if strictly correct,
is the only fix that we can easily do. Also I personally believe the
behaviour resulting from 0002 is totally correct: The new behaviour
would be that if a timeout occurred, right before it was disabled or
reset, but the interrupt was not processed yet, then we process that
timeout as normal. That seems totally reasonable behaviour to me from
the perspective of an end user: You get a timeout error when the
timeout occurred before the timeout was disabled/reset.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Xing Guo | 2024-08-31 08:04:40 | JIT: The nullness of casetest.value can be determined at the JIT compile time. |
| Previous Message | Thomas Munro | 2024-08-31 05:38:33 | Re: Streaming read-ready sequential scan code |