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