From: Tom Lane <tgl@sss.pgh.pa.us>
To: michalalbrycht@gmail.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #16840: Rows not found in table partitioned by hash when not
 all partitions exists
In-reply-to: <16840-571a22976f829ad4@postgresql.org>
References: <16840-571a22976f829ad4@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Wed, 27 Jan 2021 17:02:21 +0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2407554.1611770914.1@sss.pgh.pa.us>
Date: Wed, 27 Jan 2021 13:08:34 -0500
Message-ID: <2407555.1611770914@sss.pgh.pa.us>
Precedence: bulk

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