Re: REINDEX CONCURRENTLY unexpectedly fails

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: REINDEX CONCURRENTLY unexpectedly fails
Дата
Msg-id 20200121024303.GB2552@paquier.xyz
обсуждение исходный текст
Ответ на Re: REINDEX CONCURRENTLY unexpectedly fails  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: REINDEX CONCURRENTLY unexpectedly fails  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-bugs
On Mon, Jan 20, 2020 at 10:59:13AM +0900, Michael Paquier wrote:
> Except for the part with index_drop() where I would rather do the
> decision-making for the concurrent behavior in RemoveRelations()
> rather than index_drop() (as I did in v4), what you have here looks
> fine to me.  Would you prefer wrapping up this stuff yourself or
> should I?  This needs a backpatch down to 9.4 for the CIC/DIC part.

Same feeling after sleeping on it.  I have worked more this morning on
this stuff and I am finishing with the attached, which is a gathering
of everything that has been discussed, and based on Heikki's v5:
- Changed the part for DROP INDEX CONCURRENTLY to do the
decision-making in RemoveRelations() at the earliest stage possible.
- Removed the call to CheckTableNotInUse() in
ReindexRelationConcurrently().  Let's use a separate patch/thread for
that.
- Found one typo in the docs of REINDEX.

If there are no objections, I would like to wrap that in the next day
or so (still need to do the work for the back-branches).
--
Michael

Вложения

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

Предыдущее
От: PG Bug reporting form
Дата:
Сообщение: BUG #16220: FTS queries slow for large table when using low "gin_fuzzy_search_limit"
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: Wrong hash table size calculation in Parallel Hash Join