Horton

Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)

Teodor Sigaev <teodor@sigaev.ru>

View thread View on postgr.es
From: Teodor Sigaev <teodor@sigaev.ru>
To: Heikki Linnakangas <hlinnaka@iki.fi>, Dmitry Ivanov <d.ivanov@postgrespro.ru>
Cc: Shubham Barai <shubhambaraiss@gmail.com>, Alexander Korotkov <a.korotkov@postgrespro.ru>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Andrey Borodin <x4mmm@yandex-team.ru>, Thomas Munro <thomas.munro@enterprisedb.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Andrew Borodin <amborodin86@gmail.com>, Kevin Grittner <kgrittn@gmail.com>
Date: 2018-04-09T14:50:51Z
Lists: pgsql-hackers 
Hi!


> 1. Why do we lock all posting tree pages, even though they all represent the 
> same value? Isn't it enough to lock the root of the posting tree?
> 2. Why do we lock any posting tree pages at all, if we lock the entry tree page 
> anyway? Isn't the lock on the entry tree page sufficient to cover the key value?
> 3. Why do we *not* lock the entry leaf page, if there is no match? We still need 
> a lock to remember that we probed for that value and there was no match, so that 
> we conflict with a tuple that might be inserted later.
> 
> At least #3 is a bug. The attached patch adds an isolation test that 
> demonstrates it. #1 and #2 are weird, and cause unnecessary locking, so I think 
> we should fix those too, even if they don't lead to incorrect results.

I can't find a hole here. Agree.

> I took a stab at fixing those issues, as well as the bug when fastupdate is 
> turned on concurrently. Does the attached patch look sane to you?

I like an idea use metapage locking, thank you. Patch seems good, will you push it?

-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
                                                    WWW: http://www.sigaev.ru/

Commits

  1. Re-think predicate locking on GIN indexes.

  2. Predicate locking in GIN index