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

On Mon, Mar 12, 2018 at 9:47 AM, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
wrote:

> > 12 марта 2018 г., в 1:54, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
> написал(а):
> >
> > On Wed, Mar 7, 2018 at 8:30 PM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)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.
>

And what happen if somebody concurrently set (fastupdate = on)?
Can we miss conflicts because of that?

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