Re: [HACKERS] GSoC 2017: weekly progress reports (week 6) - Mailing list pgsql-hackers

From Andrey Borodin
Subject Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)
Date
Msg-id 61F92BBF-D100-4D66-902A-E1219B0E2FDA@yandex-team.ru
Whole thread Raw
In response to Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Responses Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
List pgsql-hackers

> 12 марта 2018 г., в 1:54, Alexander Korotkov <a.korotkov@postgrespro.ru> написал(а):
>
> On Wed, Mar 7, 2018 at 8:30 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> I suggest to create a new function GinPredicateLockPage() that checks
> whether fast update is enabled for the index.  The current arrangement
> looks too repetitive and it seems easy to make a mistake.
>
> BTW, should we also skip CheckForSerializableConflictIn() when
> fast update is enabled?  AFAICS, now it doesn't cause any errors or
> false positives, but makes useless load.  Is it correct?
>
BTW to BTW. I think we should check pending list size with GinGetPendingListCleanupSize() here
+
+    /*
+     * If fast update is enabled, we acquire a predicate lock on the entire
+     * relation as fast update postpones the insertion of tuples into index
+     * structure due to which we can't detect rw conflicts.
+     */
+    if (GinGetUseFastUpdate(ginstate->index))
+        PredicateLockRelation(ginstate->index, snapshot);

Because we can alter alter index set (fastupdate = off), but there still will be pending list.

We were discussing this with Shubham back in July, chosen some approach that seemed better, but I can't remember what
wasthat... 

Best regards, Andrey Borodin.

pgsql-hackers by date:

Previous
From: Kuntal Ghosh
Date:
Subject: Re: Inconsistent behavior in serializable snapshot
Next
From: Pavel Luzanov
Date:
Subject: Re: [HACKERS] proposal: schema variables