On 05/10/2014 10:41 PM, Alexander Korotkov wrote:
> Hackers,
>
> GIN hangs on lossy bitmap scan. Here is test case:
>
> create extension btree_gin;
> create table test as (select random() v from generate_series(1,1000000));
> create index test_idx on test using gin(v);
> set work_mem = '16MB';
> select count(*) from test where v > 0.9;
> count
> ───────
> 99916
> (1 row)
>
> Time: 63,142 ms
>
> set work_mem = '64kB';
> select count(*) from test where v > 0.9;
>
> The last query hangs. I've debugged it. It's another bug in this "cursed"
> loop in entryGetItem. Fix is attached.
Hmm, so if we're scanning a bitmap, as in a partial match query, and the
bitmap contains a lossy page reference, and advancePast is set to a
lossy reference to the same page (as it usually will be), we get stuck
in an infinite loop. The first while-loop is responsible for finding the
right block, and doesn't look at the offsets, so it stops on that block.
But the if-test that checks if it's a lossy page doesn't check if
advancePast was also a lossy reference, so it returns it again.
Committed, thanks!
- Heikki