| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com> |
| Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Phil Florent <philflorent(at)hotmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Internal error XX000 with enable_partition_pruning=on, pg 11 beta1 on Debian |
| Date: | 2018-08-07 23:09:49 |
| Message-ID: | 14685.1533683389@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com> writes:
> Consider the below case:
I initially thought the rule might be messing stuff up, but you can get
the same result without the rule by writing out the transformed query
by hand:
regression=# explain UPDATE pt_p1 SET a = 3 from pt
WHERE pt.a = 2 and pt.a = pt_p1.a;
ERROR: child rel 2 not found in append_rel_array
With enable_partition_pruning=off this goes through without an error.
I suspect the join pruning stuff is getting confused by the overlap
between the two partitioning trees involved in the join; although the
fact that one of them is the target rel must be related too, because
if you just write a SELECT for this join it's fine.
I rather doubt that this case worked before 1b54e91fa ... no time
to look closer today, though.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Asim R P | 2018-08-08 01:43:57 | Re: Shared buffer access rule violations? |
| Previous Message | Tom Lane | 2018-08-07 21:24:22 | Re: Page freezing, FSM, and WAL replay |