Re: Parallel Bitmap scans a bit broken

On Wed, Mar 15, 2017 at 10:21 PM, Emre Hasegeli <emre(at)hasegeli(dot)com> wrote:
>> hasegeli=# create table r2 as select (random() * 3)::int as i from generate_series(1, 1000000);
>> SELECT 1000000
>> hasegeli=# create index on r2 using brin (i);
>> CREATE INDEX
>> hasegeli=# analyze r2;
>> ANALYZE
>> hasegeli=# explain select * from only r2 where i = 10;
>> QUERY PLAN
>> -------------------------------------------------------------------------------------
>> Gather (cost=2867.50..9225.32 rows=1 width=4)
>> Workers Planned: 2
>> -> Parallel Bitmap Heap Scan on r2 (cost=1867.50..8225.22 rows=1 width=4)
>> Recheck Cond: (i = 10)
>> -> Bitmap Index Scan on r2_i_idx (cost=0.00..1867.50 rows=371082 width=0)
>> Index Cond: (i = 10)
>> (6 rows)
>>
>> hasegeli=# select * from only r2 where i = 10;

I am able to reproduce the bug, and attached patch fixes the same.
Problem is that I am not handling TBM_EMPTY state properly. I
remember that while reviewing the patch Robert mentioned that we might
need to handle the TBM_EMPTY and I told that since we are not handling
in non-parallel mode so we don't need to handle here as well. But, I
was wrong. So the problem is that if state is not TBM_HASH then it's
directly assuming TBM_ONE_PAGE which is completely wrong. I have
fixed that and also fixed in other similar locations.

Please verify the fix.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com