Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)
От | Alexander Korotkov |
---|---|
Тема | Re: [HACKERS] GSoC 2017: weekly progress reports (week 6) |
Дата | |
Msg-id | CAPpHfdsZeAp7_SG=a6bwQowy5oLmmO7vHBCvJH-jfJ0vx8FA0w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] GSoC 2017: weekly progress reports (week 6) (Andrey Borodin <x4mmm@yandex-team.ru>) |
Ответы |
Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)
Re: [HACKERS] GSoC 2017: weekly progress reports (week 6) |
Список | pgsql-hackers |
On Mon, Mar 12, 2018 at 9:47 AM, Andrey Borodin <x4mmm@yandex-team.ru> wrote:
> 12 марта 2018 г., в 1:54, Alexander Korotkov <a.korotkov@postgrespro.ru> написал(а):
>
> On Wed, Mar 7, 2018 at 8:30 PM, Alvaro Herrera <alvherre@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
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
В списке pgsql-hackers по дате отправления: