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

Поиск
Список
Период
Сортировка
От Teodor Sigaev
Тема Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)
Дата
Msg-id 0e3e4216-4288-49ef-57ee-7e1e7275c4d9@sigaev.ru
обсуждение исходный текст
Ответ на Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)  (Heikki Linnakangas <hlinnaka@iki.fi>)
Ответы Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)  (Andrey Borodin <x4mmm@yandex-team.ru>)
Список 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/


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Shinoda, Noriyoshi"
Дата:
Сообщение: RE: WIP: Covering + unique indexes.
Следующее
От: Teodor Sigaev
Дата:
Сообщение: Re: WIP: Covering + unique indexes.