From: Tom Lane <tgl@sss.pgh.pa.us>
To: exclusion@gmail.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18778: Query planning fails in ExecInitExprRec with
 unrecognized node type
In-reply-to: <18778-24cd399df6c806af@postgresql.org>
References: <18778-24cd399df6c806af@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Thu, 16 Jan 2025 20:00:01 +0000"
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0"
Content-ID: <1919514.1737070495.0@sss.pgh.pa.us>
Date: Thu, 16 Jan 2025 18:35:34 -0500
Message-ID: <1919554.1737070534@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1919554.1737070534%40sss.pgh.pa.us>
Precedence: bulk

------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1919514.1737070495.1@sss.pgh.pa.us>

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


------- =_aaaaaaaaaa0
Content-Type: text/x-diff;
	name="apply-setrefs-fixups-to-pruning-expressions.patch";
	charset="us-ascii"
Content-ID: <1919514.1737070495.2@sss.pgh.pa.us>
Content-Description: apply-setrefs-fixups-to-pruning-expressions.patch
Content-Transfer-Encoding: quoted-printable

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 =3D lfirst(l2);
 =

 				pinfo->rtindex +=3D rtoffset;
+				pinfo->initial_pruning_steps =3D
+					fix_scan_list(root, pinfo->initial_pruning_steps,
+								  rtoffset, 1);
+				pinfo->exec_pruning_steps =3D
+					fix_scan_list(root, pinfo->exec_pruning_steps,
+								  rtoffset, 1);
 			}
 		}
 	}
@@ -1871,6 +1877,12 @@ set_mergeappend_references(PlannerInfo *root,
 				PartitionedRelPruneInfo *pinfo =3D lfirst(l2);
 =

 				pinfo->rtindex +=3D rtoffset;
+				pinfo->initial_pruning_steps =3D
+					fix_scan_list(root, pinfo->initial_pruning_steps,
+								  rtoffset, 1);
+				pinfo->exec_pruning_steps =3D
+					fix_scan_list(root, pinfo->exec_pruning_steps,
+								  rtoffset, 1);
 			}
 		}
 	}

------- =_aaaaaaaaaa0--