Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)
От | Teodor Sigaev |
---|---|
Тема | Re: [HACKERS] GSoC 2017: weekly progress reports (week 6) |
Дата | |
Msg-id | a3a6f770-8834-70a3-9a59-1a9ad810426c@sigaev.ru обсуждение исходный текст |
Ответ на | Re: [HACKERS] GSoC 2017: weekly progress reports (week 6) (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Ответы |
Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)
|
Список | pgsql-hackers |
Alvaro Herrera wrote: > I don't quite understand the new call in gininsert -- I mean I see that > it wants to check for conflicts even when fastupdate is set, but why? If fastupdate is set then we check conflict with whole index, not a particular pages in it. Predicate lock on penging list pages will be effectively a lock over index, because every scan will begin from pending list and each insert will insert into it. I > Maybe, just maybe, it would be better to add a new flag to the > GinCheckForSerializableConflictIn function, that's passed differently > for this one callsite, and then a comment next to it that indicates why > do we test for fastupdates in one case and not the other case. > If you don't like this idea, then I think more commentary on why > fastupdate is not considered in gininsert is warranted. > > In startScanEntry, if you "goto restartScanEntry" in the fastupdate > case, are you trying to acquire the same lock again? Maybe the lock > acquire should occur before the goto target? (If this doesn't matter for > some reason, maybe add a comment about it) Thank you for noticing that, I've completely rework this part. Somehow I misreaded actual work of GinGetPendingListCleanupSize() :(. See attached patch -- Teodor Sigaev E-mail: teodor@sigaev.ru WWW: http://www.sigaev.ru/
Вложения
В списке pgsql-hackers по дате отправления: