From: Andrey Klychkov <aaklychkov@mail.ru>
To: Michael Paquier <michael@paquier.xyz>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: pgsql-bugs@lists.postgresql.org, Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re[4]:
Date: Wed, 27 May 2020 15:10:18 +0300
Message-ID: <1590581418.481387288@f493.i.mail.ru> (raw)
In-Reply-To: <20200527074736.GG103662@paquier.xyz>
References: <1590486572.205117372@f500.i.mail.ru>
<17907.1590504619@sss.pgh.pa.us>
<20200527074736.GG103662@paquier.xyz>
=======
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@paquier.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.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: aaklychkov@mail.ru, michael@paquier.xyz, peter.eisentraut@2ndquadrant.com, tgl@sss.pgh.pa.us
Subject: Re: Re[4]:
In-Reply-To: <1590581418.481387288@f493.i.mail.ru>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox