> On Thu, Jun 18, 2020 at 10:05:12PM +0900, Etsuro Fujita wrote:
> On Thu, Jun 18, 2020 at 6:49 PM PG Bug reporting form
> <noreply@postgresql.org> wrote:
> > I will send a reproduction script.
>
> > drop table if exists pt_test01 ;
> > create table pt_test01
> > ( kbn smallint not null
> > , nen char(4) not null
> > , mm char(2) not null
> > , cd char(3) not null
> > , val00 numeric(15, 3)
> > , usr varchar(10)
> > )
> > partition by range(kbn, nen) with (oids=false)
> > ;
> > create table pt_test01_1_2019 partition of pt_test01 for values from (1,
> > '2019') to (1, '2020') ;
> > create table pt_test01_1_2020 partition of pt_test01 for values from (1,
> > '2020') to (1, '2021') ;
> > create table pt_test01_2_2019 partition of pt_test01 for values from (2,
> > '2019') to (2, '2020') ;
> > create table pt_test01_2_2020 partition of pt_test01 for values from (2,
> > '2020') to (2, '2021') ;
>
> > select * from pt_test01 where kbn <= 1 and nen = '2020' ;
>
> This caused a server crash in my environment as well. Maybe I'm
> missing something, but ISTM that it's odd to allow partitions with
> empty range bounds. I'll dig into this (and another one Kobayashi-san
> reported).
Yep, I also can reproduce it easily. Can't say I'm familiar with this
code, but after looking through it a bit it seems something strange is
going on with a pruning step generated using prefix. Looks like it has
only expressions for the second attribute of the partition key, but
tries to compare with the full boundinfo. Without this pruning step the
query above doesn't crash for me.