Re: BUG #18778: Query planning fails in ExecInitExprRec with unrecognized node type
От | Tom Lane |
---|---|
Тема | Re: BUG #18778: Query planning fails in ExecInitExprRec with unrecognized node type |
Дата | |
Msg-id | 1919554.1737070534@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #18778: Query planning fails in ExecInitExprRec with unrecognized node type (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #18778: Query planning fails in ExecInitExprRec with unrecognized node type
|
Список | pgsql-bugs |
PG Bug reporting form <noreply@postgresql.org> writes: > The following script: > CREATE TABLE t (id int, PRIMARY KEY (id)) PARTITION BY RANGE (id); > CREATE TABLE t0 PARTITION OF t FOR VALUES FROM (0) TO (1); > CREATE TABLE t1 PARTITION OF t FOR VALUES FROM (1) TO (2); > SELECT 1 FROM (SELECT EXISTS (SELECT 1 FROM t0 WHERE id = t00.id) AS b FROM > t0 t00) r, t > WHERE t.id > CASE WHEN jsonb_build_object(b) IS NULL THEN 1 ELSE 1 END; > fails with: > ERROR: XX000: unrecognized node type: 24 Thanks for the report! setrefs.c is supposed to remove AlternativeSubPlan nodes from the plan, but it's failing to do so here. Digging, the un-cleaned-up AlternativeSubPlan is inside the exec_pruning_steps of an Append node's part_prune_info, and I see that setrefs is totally unaware that those expressions might need processing. I think it ought to be applying fix_scan_expr to them, as per the attached. There are a bunch of tidying-up things that fix_scan_expr does, so I suspect that there may be more bug symptoms reachable from this oversight. Some of the missed processing may be redundant --- for example it's likely that record_plan_function_dependency is duplicative because functions used here would also be used elsewhere in the query. But it's hard to believe it all is. regards, tom lane diff --git a/src/backend/optimizer/plan/setrefs.c b/src/backend/optimizer/plan/setrefs.c index fff2655595..1e7b7bc6ff 100644 --- a/src/backend/optimizer/plan/setrefs.c +++ b/src/backend/optimizer/plan/setrefs.c @@ -1795,6 +1795,12 @@ set_append_references(PlannerInfo *root, PartitionedRelPruneInfo *pinfo = lfirst(l2); pinfo->rtindex += rtoffset; + pinfo->initial_pruning_steps = + fix_scan_list(root, pinfo->initial_pruning_steps, + rtoffset, 1); + pinfo->exec_pruning_steps = + fix_scan_list(root, pinfo->exec_pruning_steps, + rtoffset, 1); } } } @@ -1871,6 +1877,12 @@ set_mergeappend_references(PlannerInfo *root, PartitionedRelPruneInfo *pinfo = lfirst(l2); pinfo->rtindex += rtoffset; + pinfo->initial_pruning_steps = + fix_scan_list(root, pinfo->initial_pruning_steps, + rtoffset, 1); + pinfo->exec_pruning_steps = + fix_scan_list(root, pinfo->exec_pruning_steps, + rtoffset, 1); } } }
В списке pgsql-bugs по дате отправления: