Re: REINDEX CONCURRENTLY unexpectedly fails

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: REINDEX CONCURRENTLY unexpectedly fails
Дата
Msg-id 20191115080706.GI1849@paquier.xyz
обсуждение исходный текст
Ответ на Re: REINDEX CONCURRENTLY unexpectedly fails  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: REINDEX CONCURRENTLY unexpectedly fails  (Michael Paquier <michael@paquier.xyz>)
Re: REINDEX CONCURRENTLY unexpectedly fails  (Andres Freund <andres@anarazel.de>)
Список pgsql-bugs
On Fri, Nov 15, 2019 at 12:21:41PM +0900, Michael Paquier wrote:
> On Thu, Nov 14, 2019 at 06:54:12PM -0800, Andres Freund wrote:
>> I think it'd be really user hostile if ReindexMultipleTables() suddenly
>> started to error out if there were any temp tables. That clearly can't
>> be an option.
>
> Okay.

So, here is a patch to address all that.  I have also added a test for
REINDEX SCHEMA on a temporary schema.  While looking at the problem, I
have found a crash if trying to reindex concurrently an index or a
table using a temporary relation from a different session because we
have been lacking checks with RELATION_IS_OTHER_TEMP() in the
concurrent code paths.  For a schema or database reindex this was not
happening as these are filtered out using isTempNamespace().  Please
note that I have not changed index_drop() for the concurrent mode.
Per my checks this does not actually cause any direct bugs as this
code path just takes care of dropping the dependencies with the index.
There could be an argument for changing that on HEAD though, but I am
not sure that this is worth the complication either.
--
Michael

Вложения

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

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: BUG #16116: function lpad(integer, integer, integer) does not exist
Следующее
От: Juan José Santamaría Flecha
Дата:
Сообщение: Re: BUG #16108: Colorization to the output of command-line hasunproperly behaviors at Windows platform