BUG #19692: Generic partition-pruning plan delays statement_timeout cancellation - Mailing list pgsql-bugs

The following bug has been logged on the website:

Bug reference:      19692
Logged by:          Qifan Liu
Email address:      imchifan@163.com
PostgreSQL version: 18.6
Operating system:   Linux on amd64
Description:

PostgreSQL version: PostgreSQL 20devel (Git commit
a12600b762c36d91450ce085fa25ef75250bc1c2); PostgreSQL 18.6; PostgreSQL 17.11
Operating system: Linux on amd64

Description
-----------
Generating a fresh generic plan for a range-partitioned table with 18
partition keys and two parameterized lower-bound clauses per key delays
statement_timeout cancellation. With statement_timeout set to 50 ms,
cancellation was not reported until 315–346 ms after the statement began.
The issue is localized to planning, and the backend remains healthy
afterward.

This weakens latency and resource-use limits for planning workloads with
this predicate shape. The demonstrated delay is less than 300 ms beyond the
configured limit.

Steps to reproduce
------------------
Run the following with psql:

\set ON_ERROR_STOP off
CREATE TABLE timeout_partprune
(
  c01 int, c02 int, c03 int, c04 int, c05 int, c06 int,
  c07 int, c08 int, c09 int, c10 int, c11 int, c12 int,
  c13 int, c14 int, c15 int, c16 int, c17 int, c18 int
)
PARTITION BY RANGE
  (c01, c02, c03, c04, c05, c06, c07, c08, c09,
   c10, c11, c12, c13, c14, c15, c16, c17, c18);
CREATE TABLE timeout_partprune_default
  PARTITION OF timeout_partprune DEFAULT;

SET plan_cache_mode = force_generic_plan;
SET statement_timeout = '50ms';
PREPARE timeout_q
  (int, int, int, int, int, int, int, int, int,
   int, int, int, int, int, int, int, int, int,
   int, int, int, int, int, int, int, int, int,
   int, int, int, int, int, int, int, int, int)
AS SELECT * FROM timeout_partprune
WHERE c01 >= $1  AND c01 >= $2
  AND c02 >= $3  AND c02 >= $4
  AND c03 >= $5  AND c03 >= $6
  AND c04 >= $7  AND c04 >= $8
  AND c05 >= $9  AND c05 >= $10
  AND c06 >= $11 AND c06 >= $12
  AND c07 >= $13 AND c07 >= $14
  AND c08 >= $15 AND c08 >= $16
  AND c09 >= $17 AND c09 >= $18
  AND c10 >= $19 AND c10 >= $20
  AND c11 >= $21 AND c11 >= $22
  AND c12 >= $23 AND c12 >= $24
  AND c13 >= $25 AND c13 >= $26
  AND c14 >= $27 AND c14 >= $28
  AND c15 >= $29 AND c15 >= $30
  AND c16 >= $31 AND c16 >= $32
  AND c17 >= $33 AND c17 >= $34
  AND c18 >= $35 AND c18 >= $36;

\timing on
EXPLAIN (COSTS OFF) EXECUTE timeout_q
  (1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
   1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1);
\timing off

Actual result
-------------
ERROR:  canceling statement due to statement timeout
Time: 336.667 ms

Observed cancellation times across the tested versions ranged from 315 to
346 ms despite the 50 ms setting.

Expected result
---------------
The statement should report statement_timeout cancellation near the
configured 50 ms deadline instead of continuing partition-pruning plan
generation for approximately another 265–296 ms. statement_timeout is
intended to bound the duration of a statement, including planning, so
planner work must periodically service pending cancellation.

Additional information
----------------------
The issue reproduced on PostgreSQL 20devel, PostgreSQL 18.6, and PostgreSQL
17.11. plan_cache_mode was set to force_generic_plan; statement_timeout was
set to 50 ms.

Inference: this predicate shape appears to generate a Cartesian expansion of
partition-pruning clause prefixes without sufficiently frequent interrupt
checks.