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

Alexander Korotkov <a.korotkov@postgrespro.ru>

From: Alexander Korotkov <a.korotkov@postgrespro.ru>
To: Andrey Borodin <x4mmm@yandex-team.ru>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, Shubham Barai <shubhambaraiss@gmail.com>, Thomas Munro <thomas.munro@enterprisedb.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Andrew Borodin <amborodin86@gmail.com>, Kevin Grittner <kgrittn@gmail.com>
Date: 2018-03-15T22:26:17Z
Lists: 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

Commits

  1. Re-think predicate locking on GIN indexes.

  2. Predicate locking in GIN index