On Sat, 31 Aug 2024 at 06:04, Alexander Lakhin <exclus...@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.
