Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)
От | Teodor Sigaev |
---|---|
Тема | Re: [HACKERS] GSoC 2017: weekly progress reports (week 6) |
Дата | |
Msg-id | 1f33318a-0150-7611-c1bb-fcb16b943c74@sigaev.ru обсуждение исходный текст |
Ответ на | Re: [HACKERS] GSoC 2017: weekly progress reports (week 6) (Dmitry Ivanov <d.ivanov@postgrespro.ru>) |
Ответы |
Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)
Re: [HACKERS] GSoC 2017: weekly progress reports (week 6) |
Список | pgsql-hackers |
Hi! I slightly modified test for clean demonstration of difference between fastupdate on and off. Also I added CheckForSerializableConflictIn() to fastupdate off codepath, but only in case of non-empty pending list. The next question what I see: why do not we lock entry leaf pages in some cases? As I understand, scan should lock any visited page, but now it's true only for posting tree. Seems, it also should lock pages in entry tree because concurrent procesess could add new entries which could be matched by partial search, for example. BTW, partial search (see collectMatchBitmap()) locks correctly entry tree, but regular startScanEntry() doesn't lock entry page in case of posting tree, only in case of posting list. Dmitry Ivanov wrote: >> I'd like to see fastupdate=on in test too, now tests cover only case >> without fastupdate. Please, add them. > > Here's a couple of tests for pending list (fastupdate = on). > -- Teodor Sigaev E-mail: teodor@sigaev.ru WWW: http://www.sigaev.ru/
Вложения
В списке pgsql-hackers по дате отправления: