Re: BUG #19692: Generic partition-pruning plan delays statement_timeout cancellation

On Thu, 17 Sept 2026 at 22:23, PG Bug reporting form
<noreply(at)postgresql(dot)org> wrote:
> 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.

There is nothing specifically slow about generating steps for a
partitioned table with exactly 18 partition keys. The point of
interest here is that the step generation can take a long time when
there are many partition keys and the query is complex.

I've pushed a patch that adds a CHECK_FOR_INTERRUPTS() in
get_steps_using_prefix_recurse().

David.