ERROR: too late to create a new PlaceHolderInfo

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

Responses

Browse pgsql-hackers by date

  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