Horton

Thread

Commits

  1. doc: Clarify use of _ccnew and _ccold in REINDEX CONCURRENTLY

  1. reindex documentation

    The Post Office <noreply@postgresql.org> — 2025-05-15T18:12:54Z

    The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/17/sql-reindex.html
Description:

The following paragraph:
"If the index marked INVALID is suffixed ccnew, then it corresponds to the
transient index created during the concurrent operation, and the recommended
recovery method is to drop it using DROP INDEX, then attempt REINDEX
CONCURRENTLY again. If the invalid index is instead suffixed ccold, it
corresponds to the original index which could not be dropped; the
recommended recovery method is to just drop said index, since the rebuild
proper has been successful."
It seems to me that the indexes are suffixed with _ccnew and _ccold not
ccnew and ccold. Also, if _ccnew or _ccold indexes alread exist, an integer
value starting from 1 will be added until a unique index is found - e.g.
_ccnew1, _ccold1, _ccnew2 etc.

  2. Re: reindex documentation

    Michael Paquier <michael@paquier.xyz> — 2025-05-17T12:44:09Z

    On Thu, May 15, 2025 at 06:12:54PM +0000, PG Doc comments form wrote:
> The following paragraph:
> "If the index marked INVALID is suffixed ccnew, then it corresponds to the
> transient index created during the concurrent operation, and the recommended
> recovery method is to drop it using DROP INDEX, then attempt REINDEX
> CONCURRENTLY again. If the invalid index is instead suffixed ccold, it
> corresponds to the original index which could not be dropped; the
> recommended recovery method is to just drop said index, since the rebuild
> proper has been successful."
> It seems to me that the indexes are suffixed with _ccnew and _ccold not
> ccnew and ccold. Also, if _ccnew or _ccold indexes alread exist, an integer
> value starting from 1 will be added until a unique index is found - e.g.
> _ccnew1, _ccold1, _ccnew2 etc.

Right, following the rules defined internally by ChooseRelationName()
when creating the new/old indexes in the process.  So this could be
added.  Would you like to suggest a rewording of this sentence for the
extra number optionally appended to the suffix if a duplicated entry
exists?
--
Michael

  3. Re: reindex documentation

    Michael Paquier <michael@paquier.xyz> — 2025-05-21T02:41:16Z

    On Sat, May 17, 2025 at 08:44:09AM -0400, Michael Paquier wrote:
> Right, following the rules defined internally by ChooseRelationName()
> when creating the new/old indexes in the process.  So this could be
> added.  Would you like to suggest a rewording of this sentence for the
> extra number optionally appended to the suffix if a duplicated entry
> exists?

Alec's latest message did not reach the lists, but it was only to
suggest a wording for the whole area, as a reply to my previous
message.  I've reused most of his words with some slight tweaks,
applied the result down to 13 as 54675d898633, marking him as the
author.
--
Michael