On Sun, Apr 5, 2026 at 4:00 AM Alexander Lakhin <[email protected]> wrote: > I and SQLsmith have discovered one more anomaly (reproduced starting from > e0e4c132e): > load 'test_plan_advice'; > select object_type from > (select object_type from information_schema.element_types limit 1), > lateral > (select sum(1) over (partition by a) from generate_series(1, 2) g(a) where > false); > > triggers an internal error: > ERROR: XX000: no rtoffset for plan unnamed_subquery > LOCATION: pgpa_plan_walker, pgpa_walker.c:110 > > Could you please have a look?
Thanks for the report. What seems to be happening here is that the whole query is replaced by a single Result node, since the join must be empty. But that means that unnamed_subquery doesn't make it into the final plan tree, and then pgpa_plan_walker() is sad about not finding it. Normally it wouldn't care, but apparently this query involves at least one semijoin someplace that the planner considered converting into a regular join with one side made unique, so pgpa_plan_walker() has an entry in sj_unique_rels and then wants to adjust that entry for the final, flattened range table, and it can't. I'm inclined to think that the fix is just: - elog(ERROR, "no rtoffset for plan %s", proot->plan_name); + continue; ...plus a comment update, but I want to spend some time mulling over whether that might break anything else before I go do it. -- Robert Haas EDB: http://www.enterprisedb.com
