Re: [HACKERS] REINDEX CONCURRENTLY 2.0

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: [HACKERS] REINDEX CONCURRENTLY 2.0
Дата
Msg-id d26799a0-14ba-7c2c-ca86-c13203a5901f@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: [HACKERS] REINDEX CONCURRENTLY 2.0  (Sergei Kornilov <sk@zsrv.org>)
Ответы Re: [HACKERS] REINDEX CONCURRENTLY 2.0  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
On 09/12/2018 19:55, Sergei Kornilov wrote:
>>       <para>
>>       An index build with the <literal>CONCURRENTLY</literal> option failed, leaving
>>       an <quote>invalid</quote> index. Such indexes are useless but it can be
>> -      convenient to use <command>REINDEX</command> to rebuild them. Note that
>> -      <command>REINDEX</command> will not perform a concurrent build. To build the
>> -      index without interfering with production you should drop the index and
>> -      reissue the <command>CREATE INDEX CONCURRENTLY</command> command.
>> +      convenient to use <command>REINDEX</command> to rebuild them.
>>      </para>
> This documentation change seems wrong for me: reindex concurrently does not rebuild invalid indexes. To fix invalid
indexeswe still need reindex with lock table or recreate this index concurrently.
 
> 

The current patch prevents REINDEX CONCURRENTLY of invalid indexes, but
I wonder why that is so.  Anyone remember?

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


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

Предыдущее
От: Mitar
Дата:
Сообщение: Re: Feature: temporary materialized views
Следующее
От: Dmitry Dolgov
Дата:
Сообщение: Re: [HACKERS] [PATCH] Generic type subscripting