"ccold" left by reindex concurrently are droppable?

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема "ccold" left by reindex concurrently are droppable?
Дата
Msg-id 20200819211312.GA15497@alvherre.pgsql
обсуждение исходный текст
Ответы Re: "ccold" left by reindex concurrently are droppable?  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
Hello

The REINDEX CONCURRENTLY documentation states that if a transient index
used lingers, the fix is to drop the invalid index and perform RC again;
and that this is to be done for "ccnew" indexes and also for "ccold"
indexes:

    The recommended recovery method in such cases is to drop the invalid index
    and try again to perform <command>REINDEX CONCURRENTLY</command>.  The
    concurrent index created during the processing has a name ending in the
    suffix <literal>ccnew</literal>, or <literal>ccold</literal> if it is an
    old index definition which we failed to drop. Invalid indexes can be
    dropped using <literal>DROP INDEX</literal>, including invalid toast
    indexes.

But this seems misleading to me.  It is correct advice for "ccnew"
indexes, of course.  But if the index is named "ccold", then the rebuild
of the index actually succeeded, so you can just drop the ccold index
and not rebuild anything.

In other words I propose to reword this paragraph as follows:

   If the transient index created during the concurrent operation is
   suffixed <literal>ccnew</literal>, the recommended recovery method
   is to drop the invalid index using <literal>DROP INDEX</literal>,
   and try to perform <command>REINDEX CONCURRENTLY</command> again. 
   If the transient index is instead suffixed <literal>ccold</literal>,
   it corresponds to the original index which we failed to drop;
   the recommended recovery method is to just drop said index, since the
   rebuild proper has been successful.

(The original talks about "the concurrent index", which seems somewhat
sloppy thinking.  I used the term "transient index" instead.)

-- 
Álvaro Herrera                            39°49'30"S 73°17'W



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

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: Problem with accessing TOAST data in stored procedures
Следующее
От: David Rowley
Дата:
Сообщение: Re: Hybrid Hash/Nested Loop joins and caching results from subplans