ERROR: SubPlan found with no parent plan

From: Richard Guo <guofenglinux(at)gmail(dot)com>
To: Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: ERROR: SubPlan found with no parent plan
Date: 2026-09-20 10:01:20
Message-ID: CAMbWs48nYDu7joYeyMKYdX8kHoL_ASEax2fqZH6L+HHqO2nkXA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Fuzzing with Claude reported this bug:

create table pt (a int) partition by range (a);
create table pt1 partition of pt for values from (0) to (3);
create table pt2 partition of pt for values from (3) to (5);
create table t (a int);

select * from pt where a = (null::int in (select a from t))::int;
ERROR: SubPlan found with no parent plan

This one is interesting. In the testexpr of the SubPlan, we have the
NULL arg and the strict comparison operator =, so the whole testexpr
is const-folded to const NULL, which means the PARAM_EXEC Param is
const-folded away. As a result, match_clause_to_partition_key()
treats it as usable for executor-startup pruning, so the expression
ends up in initial_pruning_steps, where ExecDoInitialPruning() has to
evaluate it before any PlanState exists.

I think the simplest fix is to just disallow expressions containing
SubPlans for executor-startup pruning, like attached. There may well
be a better approach, though.

- Richard

Attachment Content-Type Size
v1-0001-Don-t-use-SubPlan-containing-expressions-for-star.patch application/octet-stream 4.6 KB

Browse pgsql-hackers by date

  From Date Subject
Previous Message Trakshan Mishra 2026-09-20 09:37:09 Intermittent Assert("plan->magic == _SPI_PLAN_MAGIC") in 027_stream_regress