Re: Index (primary key) corrupt? - Mailing list pgsql-general

From Adrian Klaver
Subject Re: Index (primary key) corrupt?
Date
Msg-id f3ea70b8-c822-4b0f-b564-5e73d34188d4@aklaver.com
Whole thread Raw
In response to Index (primary key) corrupt?  (Wim Rouquart <wim.rouquart@kbc.be>)
Responses RE: Index (primary key) corrupt?
List pgsql-general
On 9/19/25 02:40, Wim Rouquart wrote:
> Internal
> 
>>> Internal
>>>
>>>
>>> Hello,
>>>
>>> When doing a pg_dump of one of our databases one of the tables primary
>>> keys doesn’t get exported. Pg_dump just skips this index, without any
>>> warning whatsoever (verbose mode was used to doublecheck).
> 
>> What is the complete table definition?
> 
> CREATE TABLE bcf_work_type (
>          id bigserial NOT NULL,
>          aml_score int8 NOT NULL,
>          CONSTRAINT idx_376814_primary PRIMARY KEY (id)
> );

The table was defined in one step using the above definition?

Or was the the PK added later?

What is the result for the query?:

select * from pg_index where indexrelid  = 'idx_376814_primary'::regclass;

How is the table populated with data?

> 
>> What is the complete pg_dump command being given?
> 
> pg_dump --verbose -p <xxx> -U <xxx> -d <xxx> > dumpverbose.sql 2> dumpverbose.log
> 
>> Is the PK definition in the pg_dump file? For plain text format can you grep/find it?
> 
> It is in neither, that’s why I'm sure it doesn't get exported. After a REINDEX statement it is.
> 
>> How is the dump file being restored?
> 
> As the code to generate the index is not in the dumpfile this seems irrelevant to me.
> 



-- 
Adrian Klaver
adrian.klaver@aklaver.com



pgsql-general by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: Client/server certificates verification support on Android platform
Next
From: Wim Rouquart
Date:
Subject: RE: Index (primary key) corrupt?