[HACKERS] 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
Вложения
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Masahiko SawadaДата:
Сообщение: Re: [HACKERS] Get stuck when dropping a subscription duringsynchronizing table
Следующее
От: Ashutosh SharmaДата:
Сообщение: Re: [HACKERS] pg_basebackup fails on Windows when using tablespace mapping