Re: Bogus lateral-reference-propagation logic in create_lateral_join_info

On 2019/02/06 12:11, Tom Lane wrote:
> Yeah, I misspoke above, it's in partition_join not partition_prune,
> specifically
>
> DELETE FROM prt1_l
> WHERE EXISTS (
> SELECT 1
> FROM int4_tbl,
> LATERAL (SELECT int4_tbl.f1 FROM int8_tbl LIMIT 2) ss
> WHERE prt1_l.c IS NULL);
>
> I didn't run this totally to bottom yet, but what seems to be
> happening is that inheritance_planner is creating a partition-specific
> subplan for the DELETE, and it's allowing AppendRelInfos from the
> parent query to propagate into the subquery even though they have
> nothing to do with that subquery.
>
> We could just decide that it's okay for code dealing with the subquery
> to ignore the irrelevant AppendRelInfos (which is basically what my
> draft patch did), but I find that to be an uncomfortable answer: it
> seems *way* too likely to result in code that can mask real bugs.
> I'd be happier fixing things so that inheritance_planner doesn't
> propagate anything into the subquery that doesn't make sense in the
> subquery's context. But perhaps that's unreasonably hard? Not enough
> data yet.

The target-relation specific entries in the append_rel_list of the
original PlannerInfo are *only* for inheritance_planner to use, so it
seems OK to ignore them during child target planning in any way possible,
which in your patch's case is by ignoring the AppendRelInfos whose
parent_relid fetches a NULL base rel. The reason for them to be NULL, as
might be clear to you, is that reference to the parent target relation in
the child query's jointree gets replaced by the reference to child target
relation. Maybe we could document that in the comment, instead of this
done by your patch:

+ * Apparently append_rel_list can contain bogus parent rels nowadays
+ *
+ if (parentrel == NULL)
+ continue;*/

Note that a RelOptInfo is never built for the *original* target relation
of the query in the inheritance case (only children, including parent in
its role as child in the regular inheritance case), so there's no
possibility of LATERAL info (or anything that's initialized by
query_planner for that matter) ever being associated with that relation.

Thanks,
Amit