From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | 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-06-09 03:39:25 |
Message-ID: | CAKJS1f9KG5nnOFhigWm4ND5Ut-yU075iJyA+ACVyQnZ-ZW1Qtw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 9 June 2018 at 06:50, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> wrote:
> It looks like this was 499be013de6, which was one of mine.
>
> A more simple case to reproduce is:
>
> drop table listp;
> create table listp (a int, b int) partition by list(a);
> create table listp1 partition of listp for values in (1);
> select * from (select * from listp union all select * from listp) t where a = 1;
>
> I'll look in more detail after sleeping.
So it looks like I've assumed that the Append path's partitioned_rels
will only ever be set for partitioned tables, but it can, in fact, be
set for UNION ALL parents too when the union children are partitioned
tables.
As a discussion topic, I've attached a patch which does resolve the
error, but it also disables run-time pruning in this case.
There might be some way we can treat UNION ALL parents differently
when building the PartitionPruneInfos. I've just not thought of what
this would be just yet. If I can't think of that, I wonder if this is
a rare enough case not to bother with run-time partition pruning.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Attachment | Content-Type | Size |
---|---|---|
run-time_prune_only_for_partitioned_tables.patch | application/octet-stream | 568 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Kellerer | 2018-06-09 05:27:35 | Re: Compromised postgresql instances |
Previous Message | Michael Paquier | 2018-06-09 00:28:17 | Re: Supporting tls-server-end-point as SCRAM channel binding for OpenSSL 1.0.0 and 1.0.1 |