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

From Adrian Klaver
Subject Re: Index (primary key) corrupt?
Date
Msg-id fd548bde-54d3-426a-a2b6-058750cfb554@aklaver.com
Whole thread Raw
In response to RE: Index (primary key) corrupt?  (Wim Rouquart <wim.rouquart@kbc.be>)
Responses RE: Index (primary key) corrupt?
List pgsql-general
On 2/11/26 01:05, Wim Rouquart wrote:
> Internal
> 
> I know the initial thread was started a while ago, but as was explained there the restore was done purely to have a
playgrounddb for this specific issue. I know the difference between pg_dump and pg_restore.
 
> The issue is with pg_dump, not with pg_basebackup (as is proven as pg_basebackup and then the restore perfectly
transfersthe 'situation' as is between the production database and the playground database).
 

Are you saying that you used pg_basebackp to create a test instance and 
then did a pg_dump from the test instance and used that output in a 
pg_restore to another database?


> 
> I just did the dumps as requested, neither of them are showing the index create as expected.

As requested being?:

For table w/data:


pg_dump -d some_db -U some_user -t name_hidden.bcf_work_type -f
bcf_work_type.sql


with table schema only:


pg_dump -d some_db -U some_user -s -t name_hidden.bcf_work_type -f
bcf_work_type.sql


This will produce a plain text SQL script.


To restore:


psql -d some_other_db -U some_user -f bcf_work_type.sql


Was this with the index in the originating database being in a 
functional state?

As a general note you need to provide more supporting information when 
replying. This thread has gone through so many iterations of conditions 
it helps to know the exact conditions you are currently working under.




-- 
Adrian Klaver
adrian.klaver@aklaver.com



pgsql-general by date:

Previous
From: Greg Sabino Mullane
Date:
Subject: Re: Guarantee order of batched pg_advisory_xact_lock
Next
From: Nico Heller
Date:
Subject: Re: Guarantee order of batched pg_advisory_xact_lock