Feedback-ID: i76984098:Fastmail
Message-ID: <5043ff13-2f39-4a80-a8f8-6765746b6a89@aklaver.com>
Date: Tue, 27 Jan 2026 08:02:17 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Index (primary key) corrupt?
To: Wim Rouquart <wim.rouquart@kbc.be>,
 Greg Sabino Mullane <htamfids@gmail.com>
Cc: "pgsql-general@lists.postgresql.org" <pgsql-general@lists.postgresql.org>
References: <AS2PR05MB1075477BA334D4DA262AD75BFEF16A@AS2PR05MB10754.eurprd05.prod.outlook.com>
 <1bfa0b6b-11a8-458f-a3f3-3f86574abc1d@aklaver.com>
 <AS2PR05MB107548567EEDAAB3AF74A6C59EF11A@AS2PR05MB10754.eurprd05.prod.outlook.com>
 <f3ea70b8-c822-4b0f-b564-5e73d34188d4@aklaver.com>
 <AS2PR05MB10754A51AB7FC85161189FF7CEF11A@AS2PR05MB10754.eurprd05.prod.outlook.com>
 <CAKAnmmLNaQ9NnjP=-kMj4t6wjt3+5nmMbQc2+F2Ekv_=zJWs5w@mail.gmail.com>
 <AS2PR05MB10754BFE319E2594C9E076EE2EFFDA@AS2PR05MB10754.eurprd05.prod.outlook.com>
 <b812d3b4-b471-479c-b22a-2380fd3ab984@aklaver.com>
 <AS2PR05MB107549DDE42DC0B8E31CB52BFEF90A@AS2PR05MB10754.eurprd05.prod.outlook.com>
Content-Language: en-US
From: Adrian Klaver <adrian.klaver@aklaver.com>
In-Reply-To: <AS2PR05MB107549DDE42DC0B8E31CB52BFEF90A@AS2PR05MB10754.eurprd05.prod.outlook.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/5043ff13-2f39-4a80-a8f8-6765746b6a89%40aklaver.com>
Precedence: bulk

On 1/27/26 04:18, Wim Rouquart wrote:
> Internal
> 
> Again, sorry for the late response. More pressing things tend to get in the way.

Bottom line the index exists, it is just not being applied.

Questions:

1) What is the restore command being used?

2) From this post:
https://www.postgresql.org/message-id/AS2PR05MB10754BFE319E2594C9E076EE2EFFDA%40AS2PR05MB10754.eurprd05.prod.outlook.com

What does this:

"The steps that show the index is missing is an export of the database 
while the index is ‘corrupt’, and then importing it. The import fails on 
foreign keys that are pointing to this index because it is indeed not 
created."

mean?

If you REINDEX before the export is the index attached to the table on 
import?

Define 'corrupt'.

3) The field the index points at, id, has:

bigint nextval('bcf_work_type_id_seq'::regclass).

Is that coming from a bigserial definition or a DEFAULT setting?

4) What happens if you create a test database and restore bcf_work_type 
by itself, with and without data?


> 
> So the output of these queries before the reindex is:
> 
> db_name_hidden=# select * from pg_index where indexrelid  = 'idx_376814_primary'::regclass;
> -[ RECORD 1 ]-------+--------
> indexrelid          | 2006873
> indrelid            | 1998823
> indnatts            | 1
> indnkeyatts         | 1
> indisunique         | t
> indnullsnotdistinct | f
> indisprimary        | t
> indisexclusion      | f
> indimmediate        | t
> indisclustered      | f
> indisvalid          | t
> indcheckxmin        | f
> indisready          | t
> indislive           | t
> indisreplident      | f
> indkey              | 1
> indcollation        | 0
> indclass            | 3124
> indoption           | 0
> indexprs            |
> indpred             |
> 
> db_name_hidden =# \d bcf_work_type
> 
>                       Table "name_hidden.bcf_work_type"
>    Column   |  Type  | Collation | Nullable |                  Default
> -----------+--------+-----------+----------+-------------------------------------------
>   id        | bigint |           | not null | nextval('bcf_work_type_id_seq'::regclass)
>   aml_score | bigint |           | not null |
> Referenced by:
>      TABLE "bcf_work_type_translation" CONSTRAINT "fk_3cf130ab108734b1" FOREIGN KEY (work_type_id) REFERENCES bcf_work_type(id) ON UPDATE RESTRICT ON DELETE RESTRICT
>      TABLE "bcf_investment" CONSTRAINT "fk_83580679108734b1" FOREIGN KEY (work_type_id) REFERENCES bcf_work_type(id) ON UPDATE RESTRICT ON DELETE RESTRICT
>      TABLE "bcf_id_information" CONSTRAINT "fk_f56a0f6b108734b1" FOREIGN KEY (work_type_id) REFERENCES bcf_work_type(id) ON UPDATE RESTRICT ON DELETE RESTRICT
> 
> 
> After the REINDEX command (REINDEX INDEX idx_376814_primary; ) this becomes:
> 
> db_name_hidden=# select * from pg_index where indexrelid  = 'idx_376814_primary'::regclass;
> -[ RECORD 1 ]-------+--------
> indexrelid          | 2006873
> indrelid            | 1998823
> indnatts            | 1
> indnkeyatts         | 1
> indisunique         | t
> indnullsnotdistinct | f
> indisprimary        | t
> indisexclusion      | f
> indimmediate        | t
> indisclustered      | f
> indisvalid          | t
> indcheckxmin        | f
> indisready          | t
> indislive           | t
> indisreplident      | f
> indkey              | 1
> indcollation        | 0
> indclass            | 3124
> indoption           | 0
> indexprs            |
> indpred             |
> 
> db_name_hidden =# \d bcf_work_type
>                       Table "name_hidden.bcf_work_type"
>    Column   |  Type  | Collation | Nullable |                  Default
> -----------+--------+-----------+----------+-------------------------------------------
>   id        | bigint |           | not null | nextval('bcf_work_type_id_seq'::regclass)
>   aml_score | bigint |           | not null |
> Indexes:
>      "idx_376814_primary" PRIMARY KEY, btree (id)
> Referenced by:
>      TABLE "bcf_work_type_translation" CONSTRAINT "fk_3cf130ab108734b1" FOREIGN KEY (work_type_id) REFERENCES bcf_work_type(id) ON UPDATE RESTRICT ON DELETE RESTRICT
>      TABLE "bcf_investment" CONSTRAINT "fk_83580679108734b1" FOREIGN KEY (work_type_id) REFERENCES bcf_work_type(id) ON UPDATE RESTRICT ON DELETE RESTRICT
>      TABLE "bcf_id_information" CONSTRAINT "fk_f56a0f6b108734b1" FOREIGN KEY (work_type_id) REFERENCES bcf_work_type(id) ON UPDATE RESTRICT ON DELETE RESTRICT
> 
> So the first result stays the same, in the description of the table now the index shows up...
> 
> 
> 

-- 
Adrian Klaver
adrian.klaver@aklaver.com