"ccold" left by reindex concurrently are droppable?

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>
Subject: "ccold" left by reindex concurrently are droppable?
Date: 2020-08-19 21:13:12
Message-ID: 20200819211312.GA15497@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2020-08-19 21:59:38 Re: Hybrid Hash/Nested Loop joins and caching results from subplans
Previous Message Pavel Stehule 2020-08-19 19:20:51 Re: Problem with accessing TOAST data in stored procedures