On Mon, Mar 12, 2018 at 9:47 AM, Andrey Borodin <x4...@yandex-team.ru>
> > 12 марта 2018 г., в 1:54, Alexander Korotkov <a.korot...@postgrespro.ru>
> > On Wed, Mar 7, 2018 at 8:30 PM, Alvaro Herrera <alvhe...@2ndquadrant.com>
> > 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
> + * relation as fast update postpones the insertion of tuples into
> + * 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?
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company