Thread: "ccold" left by reindex concurrently are droppable?
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
On Wed, Aug 19, 2020 at 05:13:12PM -0400, Alvaro Herrera wrote: > 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. Yes, that's an improvement. It would be better to backpatch that. So +1 from me. > (The original talks about "the concurrent index", which seems somewhat > sloppy thinking. I used the term "transient index" instead.) Using transient to refer to an index aimed at being ephemeral sounds fine to me in this context. -- Michael
Attachment
On Thu, Aug 20, 2020 at 7:17 AM Michael Paquier <michael@paquier.xyz> wrote: > > On Wed, Aug 19, 2020 at 05:13:12PM -0400, Alvaro Herrera wrote: > > 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. > > Yes, that's an improvement. It would be better to backpatch that. So > +1 from me. +1, that's an improvement and should be backpatched. > > > (The original talks about "the concurrent index", which seems somewhat > > sloppy thinking. I used the term "transient index" instead.) > > Using transient to refer to an index aimed at being ephemeral sounds > fine to me in this context. Agreed.
Thanks, Michael and Julien! Pushed to 12-master, with a slight rewording to use the passive voice, hopefully matching the surrounding text. I also changed "temporary" to "transient" in another line, for consistency. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services