On Mon, Mar 12, 2018 at 9:47 AM, Andrey Borodin <x4...@yandex-team.ru> wrote:
> > 12 марта 2018 г., в 1:54, Alexander Korotkov <a.korot...@postgrespro.ru> > написал(а): > > > > On Wed, Mar 7, 2018 at 8:30 PM, Alvaro Herrera <alvhe...@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. > 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
