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

Internal

> Alright, so the corrupt index is transferred by the binary pg_basebackup, but not in logical backups done via
pg_dump/pg_restore.

Correct

> The issue then is on the source database with whatever process is corrupting the index and causing no error to be
thrownwhen the table is dumped.
 

"Whatever process is corrupting the index" -> I think this was more of a one-off incident that happened somewhere in
thepast, this is not a recurring issue. It's not like this index becomes corrupt again after I reindex it, to be
clear.

>Just to be clear we are talking about this table:
>CREATE TABLE bcf_work_type (
>         id bigserial NOT NULL,
>         aml_score int8 NOT NULL,
>        CONSTRAINT idx_376814_primary PRIMARY KEY (id) );

Yes

> What is the use pattern for this table?

Well, I understood from the devs it is basically no longer used currently, probably explaining why no issues have shown
upuntil the datarefresh.
 

> As I recall this is not a large table, but for completeness what is it's average size?

It has only 12 rows 😊

> What are the Postgres log settings, on the source database, for?:

log_error_verbosity = 'default'
log_min_error_statement = 'fatal'
log_min_messages = 'warning'
log_statement = 'ddl'

> Are there any entries in the Postgres log that reference this table?

Nope, none found, probably because it isn't used anymore (and because of above log settings if it would be)

-----Original Message-----
From: Adrian Klaver <adrian.klaver@aklaver.com>
Sent: donderdag 5 maart 2026 17:05
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 3/5/26 5:23 AM, Wim Rouquart wrote:
> Internal
>
>> So the REINDEX on the source PK is prompted by it not showing up on the target?
>
> That's how we noticed the initial issue yes, we got errors during the datarefresh on the target  database where
foreignkeys wanted to reference the non-existing index (because it wasn't imported).
 
>
>> On the test instance you set up with pg_basebackup and that has the corrupted index what happens if you try to
INSERTa record with a duplicate id?
 
>
> Good question, as I kind of expected, it doesn't complain at all when I do an insert with a duplicate id (and the row
actuallygets inserted). If I consecutively try to do the reindex, then I get the error that it can't because of
doubles...
>
>
> -----Original Message-----
> From: Adrian Klaver <adrian.klaver@aklaver.com>
> Sent: vrijdag 13 februari 2026 18:33
> 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 8:27 AM, Wim Rouquart wrote:
>> 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.
>
> So the REINDEX on the source PK is prompted by it not showing up on the target?
>
>>
>>> 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
notcreated in the target (because it was not in the dumpfile).
 
>
> On the test instance you set up with pg_basebackup and that has the corrupted index what happens if you try to INSERT
arecord with a duplicate id?
 

Alright, so the corrupt index is transferred by the binary pg_basebackup, but not in logical backups done via
pg_dump/pg_restore.
The issue then is on the source database with whatever process is corrupting the index and causing no error to be
thrownwhen the table is dumped.
 

Just to be clear we are talking about this table:

CREATE TABLE bcf_work_type (
         id bigserial NOT NULL,
         aml_score int8 NOT NULL,
         CONSTRAINT idx_376814_primary PRIMARY KEY (id) );

What is the use pattern for this table?

As I recall this is not a large table, but for completeness what is it's average size?

What are the Postgres log settings, on the source database, for?:

log_min_messages

log_min_error_statement

log_error_verbosity

log_statement

Are there any entries in the Postgres log that reference this table?

>
>>
>
>>> I hope this clears out any confusion.
>>>
>>> -----Original Message-----
>> Adrian Klaver
>> adrian.klaver@aklaver.com
>>
>> Disclaimer <https://www.kbc.com/KBCmailDisclaimer>
>
>
> Disclaimer <https://www.kbc.com/KBCmailDisclaimer>


--
Adrian Klaver
adrian.klaver@aklaver.com

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