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

From: Teodor Sigaev <teodor(at)sigaev(dot)ru>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Dmitry Ivanov <d(dot)ivanov(at)postgrespro(dot)ru>, Shubham Barai <shubhambaraiss(at)gmail(dot)com>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Andrew Borodin <amborodin86(at)gmail(dot)com>, Kevin Grittner <kgrittn(at)gmail(dot)com>
Subject: Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)
Date: 2018-03-29 17:07:33
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers pgsql-www

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(at)sigaev(dot)ru

Attachment Content-Type Size
Predicate-Locking-in-gin-index_v12.patch text/x-patch 50.6 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-03-29 17:09:48 Re: [HACKERS] [PATCH] Vacuum: Update FSM more frequently
Previous Message Tomas Vondra 2018-03-29 16:55:45 Re: [HACKERS] path toward faster partition pruning

Browse pgsql-www by date

  From Date Subject
Next Message Alvaro Herrera 2018-03-29 17:24:46 Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)
Previous Message Alexander Korotkov 2018-03-29 13:10:24 Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)