Re: Internal error XX000 with enable_partition_pruning=on, pg 11beta1 on Debian - Mailing list pgsql-hackers

From David Rowley
Subject Re: Internal error XX000 with enable_partition_pruning=on, pg 11beta1 on Debian
Date
Msg-id CAKJS1f9KG5nnOFhigWm4ND5Ut-yU075iJyA+ACVyQnZ-ZW1Qtw@mail.gmail.com
Whole thread Raw
In response to Re: Internal error XX000 with enable_partition_pruning=on, pg 11beta1 on Debian  (David Rowley <david.rowley@2ndquadrant.com>)
Responses Re: Internal error XX000 with enable_partition_pruning=on, pg 11 beta1 on Debian
List pgsql-hackers
On 9 June 2018 at 06:50, David Rowley <david.rowley@2ndquadrant.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

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Supporting tls-server-end-point as SCRAM channel binding forOpenSSL 1.0.0 and 1.0.1
Next
From: Thomas Kellerer
Date:
Subject: Re: Compromised postgresql instances