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

From Alexander Korotkov
Subject Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)
Date
Msg-id CAPpHfdtpK=VxPGcdtHLh-btj6FycK8eTY1JdoKdVqv7iNs5+7g@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)  (Andrey Borodin <x4mmm@yandex-team.ru>)
Responses Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)  (Heikki Linnakangas <hlinnaka@iki.fi>)
List pgsql-hackers
On Tue, Mar 13, 2018 at 3:26 PM, Andrey Borodin <x4mmm@yandex-team.ru> wrote:
> 13 марта 2018 г., в 17:02, Alexander Korotkov <a.korotkov@postgrespro.ru> написал(а):
>
> 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.
>
> And what happen if somebody concurrently set (fastupdate = on)?
> Can we miss conflicts because of that?
No, AccessExclusiveLock will prevent this kind of problems with enabling fastupdate.

True.  I didn't notice that ALTER INDEX SET locks index in so high mode.
Thus, everything is fine from this perspective.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company 

pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: SET TRANSACTION in PL/pgSQL
Next
From: Alexander Korotkov
Date:
Subject: Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)