File: query_cancel.sql

package info (click to toggle)
postgresql-17 17.6-1
  • links: PTS, VCS
  • area: main
  • in suites: sid
  • size: 150,868 kB
  • sloc: ansic: 945,304; sql: 118,799; perl: 51,715; xml: 30,905; yacc: 20,742; lex: 8,812; makefile: 6,624; sh: 4,972; cpp: 1,021; python: 414; asm: 40; sed: 3
file content (22 lines) | stat: -rw-r--r-- 938 bytes parent folder | download | duplicates (3)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
SELECT version() ~ 'cygwin' AS skip_test \gset
\if :skip_test
\quit
\endif

-- Let's test canceling a remote query.  Use a table that does not have
-- remote_estimate enabled, else there will be multiple queries to the
-- remote and we might unluckily send the cancel in between two of them.
-- First let's confirm that the query is actually pushed down.
EXPLAIN (VERBOSE, COSTS OFF)
SELECT count(*) FROM ft1 a CROSS JOIN ft1 b CROSS JOIN ft1 c CROSS JOIN ft1 d;

BEGIN;
-- Make sure that connection is open and set up.
SELECT count(*) FROM ft1 a;
-- On most machines, 10ms will be enough to be sure that we've sent the slow
-- query.  We may sometimes exercise the race condition where we send cancel
-- before the remote side starts the query, but that's fine too.
SET LOCAL statement_timeout = '10ms';
-- This would take very long if not canceled:
SELECT count(*) FROM ft1 a CROSS JOIN ft1 b CROSS JOIN ft1 c CROSS JOIN ft1 d;
COMMIT;