ERROR: SubPlan found with no parent plan
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t253862psql -h localhost -U postgresBuilt from patchset v1 (message #1), September 20, 2026 at 10:14 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t253862_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t253862_1 && git checkout t253862_1Patchset v1 (message #1) is on t253862_1
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