Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Subject: BUG #19692: Generic partition-pruning plan delays statement_timeout
 cancellation
To: pgsql-bugs@lists.postgresql.org
From: PG Bug reporting form <noreply@postgresql.org>
Cc: imchifan@163.com
Reply-To: imchifan@163.com, pgsql-bugs@lists.postgresql.org
Date: Thu, 17 Sep 2026 08:49:01 +0000
Message-ID: <19692-dacfc57cda5035fc@postgresql.org>
Auto-Submitted: auto-generated
Archived-At: 
 <https://www.postgresql.org/message-id/19692-dacfc57cda5035fc%40postgresql.org>
Precedence: bulk

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:       =20

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=E2=80=93346 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 =3D force_generic_plan;
SET statement_timeout =3D '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 >=3D $1  AND c01 >=3D $2
  AND c02 >=3D $3  AND c02 >=3D $4
  AND c03 >=3D $5  AND c03 >=3D $6
  AND c04 >=3D $7  AND c04 >=3D $8
  AND c05 >=3D $9  AND c05 >=3D $10
  AND c06 >=3D $11 AND c06 >=3D $12
  AND c07 >=3D $13 AND c07 >=3D $14
  AND c08 >=3D $15 AND c08 >=3D $16
  AND c09 >=3D $17 AND c09 >=3D $18
  AND c10 >=3D $19 AND c10 >=3D $20
  AND c11 >=3D $21 AND c11 >=3D $22
  AND c12 >=3D $23 AND c12 >=3D $24
  AND c13 >=3D $25 AND c13 >=3D $26
  AND c14 >=3D $27 AND c14 >=3D $28
  AND c15 >=3D $29 AND c15 >=3D $30
  AND c16 >=3D $31 AND c16 >=3D $32
  AND c17 >=3D $33 AND c17 >=3D $34
  AND c18 >=3D $35 AND c18 >=3D $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=E2=80=93296 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.