On 2020-May-27, Andrey Klychkov wrote:
> =======
> BEFORE:
> =======
>
> Indexes:
> "act_re_procdef_pkey" PRIMARY KEY, btree (id_)
> "act_uniq_procdef" UNIQUE CONSTRAINT, btree (key_, version_, tenant_id_)
> "act_re_procdef_deployment_id_idx" btree (deployment_id_)
> =====
> AFTER
> =====
>
> Indexes:
> "act_re_procdef_pkey" PRIMARY KEY, btree (id_)
> "act_re_procdef_pkey_ccnew" UNIQUE, btree (id_) INVALID
> "act_uniq_procdef" UNIQUE CONSTRAINT, btree (key_, version_, tenant_id_)
> "act_uniq_procdef_ccnew" UNIQUE, btree (key_, version_, tenant_id_) INVALID
> "act_re_procdef_deployment_id_idx" btree (deployment_id_)
> "act_re_procdef_deployment_id_idx_ccnew" btree (deployment_id_) INVALID
> I got the error related to the one UNIQUE index, why all the new indexes are invalid?
> >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.
I think this part remains unanswered: why are there *three* invalid
indexes, and not two? It makes sense for the UNIQUE indexes to acquire
invalid duplicates, but strangely we also have a
act_re_procdef_deployment_id_idx_ccnew which is *not* unique. What
happened there?
(I also wonder if it wouldn't make more sense to reindexdb to attempt to
drop indexes that it couldn't complete.)
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
