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

Internal

1) ) It won't be included with the CREATE TABLE statement per:-

Yes, let's keep it at: it's not in the dumpfile anywhere.

> 2) The issue seems to be not the dump, but the non-functional state of the index on the source database.

>Is there any indication of why that is happening?

Not as far as I know.

> Also what error do you get on the source database that tells you the PK is not working?

None, only noticed the issue because of the datarefresh to another instance where it turned out the primary key was not
createdin the target (because it was not in the dumpfile).
 



-----Original Message-----
From: Adrian Klaver <adrian.klaver@aklaver.com>
Sent: vrijdag 13 februari 2026 17:09
To: Wim Rouquart <wim.rouquart@kbc.be>; Greg Sabino Mullane <htamfids@gmail.com>
Cc: pgsql-general@lists.postgresql.org
Subject: Re: Index (primary key) corrupt?



The real sender of this external email is adrian.klaver@aklaver.com





On 2/13/26 00:08, Wim Rouquart wrote:
> Internal
>
> Ok, to do a small recap because indeed this thread has been extended for a while now.
>
> - The issue with the specific index was noted on a production database (after a datarefresh that partly failed
becauseof the missing index).
 
>
> - To reproduce and experiment with the issue, a pg_basebackup was taken from that prod instance and restored to a
testinstance. Every single test step is executed on this test instance, the prod database is no longer involved,
pg_basebackupis no longer involved, everything is pg_dump based from here on onwards.
 
>
> - So this means the test pg_dumps where done with the index in a 'non-fuctional state'. As expected, the create
statementof the index does NOT show up in the generated .sql scripts (neither 'loose' nor in the create statement of
thetable).
 

1) It won't be included with the CREATE TABLE statement per:-

https://www.postgresql.org/docs/current/app-pgdump.html

"--section=sectionname

     Only dump the named section. The section name can be pre-data, data, or post-data. This option can be specified
morethan once to select multiple sections. The default is to dump all sections.
 

     The data section contains actual table data, large-object contents, sequence values, and statistics for tables,
materializedviews, and foreign tables. Post-data items include definitions of indexes, triggers, rules, statistics for
indexes,and constraints other than validated check and not-null constraints. Pre-data items include all other data
definitionitems.
 
"
2) The issue seems to be not the dump, but the non-functional state of the index on the source database.

Is there any indication of why that is happening?

Also what error do you get on the source database that tells you the PK is not working?




>
> I hope this clears out any confusion.
>
> -----Original Message-----
Adrian Klaver
adrian.klaver@aklaver.com

Disclaimer <https://www.kbc.com/KBCmailDisclaimer>