| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Andrey Klychkov <aaklychkov(at)mail(dot)ru>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Re[2]: |
| Date: | 2020-05-27 07:48:53 |
| Message-ID: | 20200527074736.GG103662@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2020-05-27 08:00:46 | BUG #16465: Inconsistent results from comparison of row value expressions |
| Previous Message | Tulegen Nuryshov | 2020-05-27 04:33:14 | RE: error |