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
-
Re-think predicate locking on GIN indexes.
- 0bef1c0678d9 11.0 landed
-
Predicate locking in GIN index
- 43d1ed60fdd9 11.0 landed