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

Поиск
Список
Период
Сортировка
От Alexander Korotkov
Тема Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)
Дата
Msg-id CAPpHfdtpK=VxPGcdtHLh-btj6FycK8eTY1JdoKdVqv7iNs5+7g@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)  (Heikki Linnakangas <hlinnaka@iki.fi>)
Список 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 

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alexander Korotkov
Дата:
Сообщение: Re: SET TRANSACTION in PL/pgSQL
Следующее
От: Alexander Korotkov
Дата:
Сообщение: Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)