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)
|
| Список | 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
Alexander Korotkov
Postgres Professional: http://www.
The Russian Postgres Company
В списке pgsql-hackers по дате отправления: