GSoC 2017: weekly progress reports (week 4) and patch for hash index

Project: Explicitly support predicate locks in index AMs besides b-tree

Hi,

During this week, I continued my work on predicate locking in the hash
index and created a patch for it. As I have written in my proposal for the
hash index, every scan operation acquires a predicate lock on the primary
page of the bucket.
And hash indexes are used for equality comparison. So, this can still
generate false positives when a scan operation and an insert operation are
trying to access the same bucket but are looking for different tuples.
Let's see that with an example.

setup:

create table hash_tbl(id int4, p integer);

create index hash_pointidx on hash_tbl using hash(p);

insert into hash_tbl (id, p)
select g, g*2 from generate_series(1, 10000000) g;

read operation:
select * from hash_tbl where p=78988658;

insert operation:
insert into hash_tbl values(99999999, 546789888);

If these two hash keys (78988658 and 546789888) mapped to the same bucket,
this will result in false serialization failure.
Please correct me if this assumption about false positives is wrong.

In summary, I have done following things in this week.

1) found appropriate places in the hash index AM to insert calls to
existing functions (PredicateLockPage(), CheckForSerializableConflictIn()
...etc)

2) created tests to check serialization failures and false positives

3) tested my patch on the current head

Regards,

Shubham

<https://mailtrack.io/> Sent with Mailtrack
<https://mailtrack.io/install?source=signature&lang=en&referral=shubhambaraiss(at)gmail(dot)com&idSignature=22>