David Rowley <david.rowley@2ndquadrant.com> writes:
> On Wed, 6 Feb 2019 at 10:57, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Also, I'd really like to know why I had to put in the exception seen
>> in the loop for AppendRelInfos that do not point to a valid parent.
>> It seems to me that that is almost certainly working around a bug in
>> the partitioning logic. (Without it, the partition_prune regression test
>> crashes.) Or would somebody like to own up to having created that state
>> of affairs intentionally? If so why?
> Sounds pretty strange to me. What exactly do you mean by not
> pointing to a valid parent? Do you mean the parent_relid index is not
> a valid RelOptInfo?
Exactly --- the parent_relid index does not have a RelOptInfo in
simple_rel_array[].
> Can you point to the regression test that's doing this?
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.
regards, tom lane
