reindex documentation
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.
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
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