Re: Re[2]:
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrey Klychkov <aaklychkov@mail.ru>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, pgsql-bugs@lists.postgresql.org
Date: 2020-05-27T07:48:53Z
Lists: pgsql-bugs
On Tue, May 26, 2020 at 10:50:19AM -0400, Tom Lane wrote: > 2. Is reindexdb handling the failure sanely? While I'd agree that > this behavior isn't especially desirable, it's the price of using > REINDEX CONCURRENTLY. On failure, you're expected to clean up > manually by removing the leftover invalid index. Perhaps the > documentation isn't clear enough about that, but I don't see a > bug there. There is a paragraph about the handling of invalid indexes on the reindex page: https://www.postgresql.org/docs/devel/sql-reindex.html#SQL-REINDEX-CONCURRENTLY "The recommended recovery method in such cases is to drop the invalid index and try again to perform REINDEX CONCURRENTLY. The concurrent index created during the processing has a name ending in the suffix ccnew, or ccold if it is an old index definition which we failed to drop. Invalid indexes can be dropped using DROP INDEX, including invalid toast indexes." -- Michael
Commits
-
Doc: Mention about caveats of --concurrently on reindexdb page
- 38be24228dcd 12.4 landed
- 9b60c4b979bc 13.0 landed