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)
|
Список | 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 по дате отправления: