Re: [EXTERNAL] Re: Add non-blocking version of PQcancel

Поиск
Список
Период
Сортировка
От Jelte Fennema-Nio
Тема Re: [EXTERNAL] Re: Add non-blocking version of PQcancel
Дата
Msg-id CAGECzQQM1N0H3e9RbSqi4=mmFgfLaFNr6R7gNpFoePb9exRryg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [EXTERNAL] Re: Add non-blocking version of PQcancel  (Alexander Lakhin <exclusion@gmail.com>)
Список pgsql-hackers
On Sat, 31 Aug 2024 at 06:04, Alexander Lakhin <exclusion@gmail.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.



В списке pgsql-hackers по дате отправления: