| From: | Richard Guo <guofenglinux(at)gmail(dot)com> |
|---|---|
| To: | Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | ERROR: too late to create a new PlaceHolderInfo |
| Date: | 2026-09-17 01:14:01 |
| Message-ID: | CAMbWs4_tg90KxNVdABpBnx2oGBQTCAHAV45mPEfCdKvo11ZEVQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
While fixing the assertion failure with LATERAL UNION ALL reported by
Fujii-san [1], I ran into this:
create table t (a int);
select *
from t t1 left join (t t2 join t t3 on true) j on true,
lateral ((select j offset 0) union all (select null offset 0)) ss;
ERROR: too late to create a new PlaceHolderInfo
This goes back to v16, when add_nullingrels_if_needed() was first
introduced.
When a LATERAL UNION ALL subquery is pulled up as an appendrel,
find_lateral_references looks only at the parent RTE's subquery,
assuming the children are copies of parts of it. But the parent's
subquery and the children get their join alias Vars expanded
separately, later in subquery_planner. If the expansion needs a PHV
(here, the whole-row Var of j, which is nulled by the left join), each
flatten_join_alias_vars call makes its own PHV with a new phid. So
the children end up asking for PHVs that have no PlaceHolderInfo.
A straightforward fix is to expand join alias Vars in the LATERAL
subquery in pull_up_simple_union_all, before its rtable gets copied,
so that all the copies share the same PHVs. Doing this that early
should be OK, since a LATERAL item can only reference FROM items to
its left, and pull_up_subqueries has already processed those, so their
join alias lists are final. See attached.
This feels more like a band-aid though. I think the more principled
fix would be a PHV cache in add_nullingrels_if_needed, so that we
don't generate identical PHVs with different IDs, like what rv_cache
does in pullup_replace_vars_callback. But since
flatten_join_alias_vars is called many times per query level, the
cache would have to live in PlannerInfo, which seems too invasive to
back-patch.
Any thoughts?
[1] https://postgr.es/m/CAHGQGwGZBZmb7Yq+UTT0Lp5wvztQZtMT94ehcMHQs9Dk6jaaXQ@mail.gmail.com
- Richard
| Attachment | Content-Type | Size |
|---|---|---|
| v1-0001-Fix-mismatched-PHVs-for-join-aliases-in-LATERAL-U.patch | application/octet-stream | 9.3 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Henson Choi | 2026-09-17 01:21:27 | Re: Row pattern recognition |
| Previous Message | shihao zhong | 2026-09-17 01:07:51 | Re: REPACK (CONCURRENTLY) backend waits indefinitely when decoding worker fails to start |