"ccold" left by reindex concurrently are droppable? - Mailing list pgsql-hackers

From Alvaro Herrera
Subject "ccold" left by reindex concurrently are droppable?
Date
Msg-id 20200819211312.GA15497@alvherre.pgsql
Whole thread Raw
Responses Re: "ccold" left by reindex concurrently are droppable?  (Michael Paquier <michael@paquier.xyz>)
List 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 by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Problem with accessing TOAST data in stored procedures
Next
From: David Rowley
Date:
Subject: Re: Hybrid Hash/Nested Loop joins and caching results from subplans