File: query_cancel.sql

package info (click to toggle)
postgresql-18 18~beta3-1
  • links: PTS, VCS
  • area: main
  • in suites: experimental
  • size: 155,816 kB
  • sloc: ansic: 993,154; sql: 127,411; perl: 58,874; xml: 30,905; yacc: 21,023; lex: 9,000; makefile: 6,880; sh: 5,353; cpp: 984; python: 710; 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;