Re: Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM?

Поиск
Список
Период
Сортировка
От Andrey Borodin
Тема Re: Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM?
Дата
Msg-id CA989C25-C66B-4D5D-94D2-F4F095A46120@yandex-team.ru
обсуждение исходный текст
Ответ на Re: Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM?  (Peter Geoghegan <pg@bowt.ie>)
Ответы Re: Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM?  (Peter Geoghegan <pg@bowt.ie>)
Список pgsql-hackers

> 4 нояб. 2021 г., в 20:58, Peter Geoghegan <pg@bowt.ie> написал(а):
> That's a pretty unlikely scenario. And even
> if it happened it would only happen once (until the next time we get
> unlucky). What are the chances of somebody noticing a more or less
> once-off, slightly wrong answer?

I'd say next to impossible, yet not impossible. Or, perhaps, I do not see protection from this.

Moreover there's a "microvacuum". It kills tuples with BUFFER_LOCK_SHARE. AFAIU it should take cleanup lock on buffer
too?

Best regards, Andrey Borodin.


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

Предыдущее
От: Andrey Borodin
Дата:
Сообщение: Re: Supply restore_command to pg_rewind via CLI argument
Следующее
От: Hayk Manukyan
Дата:
Сообщение: Re: Feature request for adoptive indexes