On Sat, 22 Jun 2024 at 17:00, Alexander Lakhin <exclus...@gmail.com> wrote: > @@ -2775,6 +2775,7 @@ > SET LOCAL statement_timeout = '10ms'; > select count(*) from ft1 CROSS JOIN ft2 CROSS JOIN ft4 CROSS JOIN ft5; -- > this takes very long > ERROR: canceling statement due to statement timeout > +WARNING: could not get result of cancel request due to timeout > COMMIT;
As you describe it, this problem occurs when the cancel request is processed by the foreign server, before the query is actually received. And postgres then (rightly) ignores the cancel request. I'm not sure if the existing test is easily changeable to fix this. The only thing that I can imagine works in practice is increasing the statement_timeout, e.g. to 100ms. > I also came across another failure of the test: > @@ -2774,7 +2774,7 @@ > BEGIN; > SET LOCAL statement_timeout = '10ms'; > select count(*) from ft1 CROSS JOIN ft2 CROSS JOIN ft4 CROSS JOIN ft5; -- > this takes very long > -ERROR: canceling statement due to statement timeout > +ERROR: canceling statement due to user request > COMMIT; > > which is reproduced with a sleep added here: > @@ -1065,6 +1065,7 @@ exec_simple_query(const char *query_string) > */ > parsetree_list = pg_parse_query(query_string); > +pg_usleep(11000); After investigating, I realized this actually exposes a bug in our statement timeout logic. It has nothing to do with posgres_fdw and reproduces with any regular postgres query too. Attached is a patch that fixes this issue. This one should probably be backported.
v1-0001-Do-not-reset-statement_timeout-indicator-outside-.patch
Description: Binary data
