Re: BUG #16840: Rows not found in table partitioned by hash when not all partitions exists - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #16840: Rows not found in table partitioned by hash when not all partitions exists
Date
Msg-id 2407555.1611770914@sss.pgh.pa.us
Whole thread Raw
In response to BUG #16840: Rows not found in table partitioned by hash when not all partitions exists  (PG Bug reporting form <noreply@postgresql.org>)
Responses Re: BUG #16840: Rows not found in table partitioned by hash when not all partitions exists
List pgsql-bugs
PG Bug reporting form <noreply@postgresql.org> writes:
> CREATE TABLE dir (
>    id SERIAL,
>    volume_id BIGINT,
>    path TEXT
> ) PARTITION BY HASH (volume_id);
> CREATE TABLE  dir_part_2 PARTITION OF dir FOR VALUES WITH (modulus 3,
> remainder 2);
> SELECT * FROM dir WHERE volume_id=1 AND (path='abc' OR path='def')  --
> returns 0 rows - NOT OK!

Hmm, seems to be a case of faulty partition exclusion, because the
plan isn't scanning anything:

=# explain SELECT * FROM dir WHERE volume_id=1 AND (path='abc' OR path='def');
                QUERY PLAN                
------------------------------------------
 Result  (cost=0.00..0.00 rows=0 width=0)
   One-Time Filter: false
(2 rows)

Probably the reason we'd not noticed is that an incomplete set of
hash partitions isn't a very useful situation: if you don't
populate all of the partitions, you risk unexpected insertion
failures, since you really shouldn't be assuming which partition
any given key value will map into.  Still, it's clearly a bug.
Thanks for the report!

            regards, tom lane



pgsql-bugs by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: Inconsistent application of [, ...] in documentation
Next
From: Alvaro Herrera
Date:
Subject: Re: BUG #16794: BEFORE UPDATE FOR EACH ROW triggers on partitioned tables can break tuple moving UPDATEs