=======
BEFORE:
=======
ep2_test=# \d act_re_procdef
Table "public.act_re_procdef"
Column | Type | Collation | Nullable | Default
-------------------------+-------------------------+-----------+----------+-----------------------
id_ | character varying(64) | | not null |
rev_ | integer | | |
category_ | character varying(255) | | |
name_ | character varying(255) | | |
key_ | character varying(255) | | not null |
version_ | integer | | not null |
deployment_id_ | character varying(64) | | |
resource_name_ | character varying(4000) | | |
dgrm_resource_name_ | character varying(4000) | | |
description_ | character varying(4000) | | |
has_start_form_key_ | boolean | | |
suspension_state_ | integer | | |
tenant_id_ | character varying(255) | | | ''::character varying
has_graphical_notation_ | boolean | | |
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_)
Referenced by:
TABLE "act_ru_identitylink" CONSTRAINT "act_fk_athrz_procedef" FOREIGN KEY (proc_def_id_) REFERENCES act_re_procdef(id_)
TABLE "act_ru_execution" CONSTRAINT "act_fk_exe_procdef" FOREIGN KEY (proc_def_id_) REFERENCES act_re_procdef(id_)
TABLE "act_procdef_info" CONSTRAINT "act_fk_info_procdef" FOREIGN KEY (proc_def_id_) REFERENCES act_re_procdef(id_)
TABLE "act_ru_task" CONSTRAINT "act_fk_task_procdef" FOREIGN KEY (proc_def_id_) REFERENCES act_re_procdef(id_)
I’ve run the following command once
time reindexdb -d ep2_test --concurrently
WARNING: cannot reindex system catalogs concurrently, skipping all
reindexdb: error: reindexing of database "ep2_test" failed: ERROR: could not create unique index "act_uniq_procdef_ccnew"
DETAIL: Key (key_, version_, tenant_id_)=(com.edisoft.doc.fns.upd.service.act, 3, ) is duplicated.
=====
AFTER
=====
ep2_test=# \d act_re_procdef
Table "public.act_re_procdef"
Column | Type | Collation | Nullable | Default
-------------------------+-------------------------+-----------+----------+-----------------------
id_ | character varying(64) | | not null |
rev_ | integer | | |
category_ | character varying(255) | | |
name_ | character varying(255) | | |
key_ | character varying(255) | | not null |
version_ | integer | | not null |
deployment_id_ | character varying(64) | | |
resource_name_ | character varying(4000) | | |
dgrm_resource_name_ | character varying(4000) | | |
description_ | character varying(4000) | | |
has_start_form_key_ | boolean | | |
suspension_state_ | integer | | |
tenant_id_ | character varying(255) | | | ''::character varying
has_graphical_notation_ | boolean | | |
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?
It would be good:
* if other indexes are possible to rebuild, reindexdb rebuilds them
* if not (why?), reindexdb reports why
>Среда, 27 мая 2020, 10:49 +03:00 от Michael Paquier <michael(at)paquier(dot)xyz>:
>
>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
>
--
Regards,
Andrew K.