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

From: Shubham Barai <shubhambaraiss(at)gmail(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Cc: Andrew Borodin <amborodin86(at)gmail(dot)com>, Kevin Grittner <kgrittn(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Subject: GSoC 2017: weekly progress reports (week 4) and patch for hash index
Date: 2017-06-27 09:21:41
Message-ID: CALxAEPvNsM2GTiXdRgaaZ1Pjd1bs+sxfFsf7Ytr+iq+5JJoYXA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

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>

Attachment Content-Type Size
Predicate-Locking-in-hash-index_3.patch application/octet-stream 28.4 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Sharma 2017-06-27 10:46:40 Re: pg_basebackup fails on Windows when using tablespace mapping
Previous Message Masahiko Sawada 2017-06-27 08:51:31 Re: Get stuck when dropping a subscription during synchronizing table