Re: Does a cancelled REINDEX CONCURRENTLY need to be messy?

Поиск
Список
Период
Сортировка
От Thom Brown
Тема Re: Does a cancelled REINDEX CONCURRENTLY need to be messy?
Дата
Msg-id CAA-aLv6jncBAp1s_tHuQ0p0cFyJPL4qt-yMv1YCKRUTS2SMApg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Does a cancelled REINDEX CONCURRENTLY need to be messy?  (Álvaro Herrera <alvherre@alvh.no-ip.org>)
Ответы Re: Does a cancelled REINDEX CONCURRENTLY need to be messy?  (Álvaro Herrera <alvherre@alvh.no-ip.org>)
Список pgsql-hackers
On Thu, 29 Jun 2023, 14:45 Álvaro Herrera, <alvherre@alvh.no-ip.org> wrote:
ALTER TABLE DETACH CONCURRENTLY had to deal with this also, and it did it by having a COMPLETE option you can run later in case things got stuck the first time around. I suppose we could do something similar, where the server automatically does the needful, whatever that is.

So there doesn't appear to be provision for deferred activities.

Could, perhaps, the fact that it is an invalid index that has no locks on it, and is dependent on the table mean it could be removed by a VACUUM?

I just don't like the idea of the user needing to remove broken things.

Thom

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

Предыдущее
От: Noah Misch
Дата:
Сообщение: Re: check_strxfrm_bug()
Следующее
От: Noah Misch
Дата:
Сообщение: Re: ICU locale validation / canonicalization