On Sat, 22 Jun 2024 at 17:00, Alexander Lakhin <exclusion@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.