On 3/10/26 7:43 AM, Greg Sabino Mullane wrote:
On Tue, Mar 10, 2026 at 10:24 AM Wim Rouquart <[email protected]
<mailto:[email protected]>> wrote:
Let me get this straight, are you still contesting that the index is
actually not part of the dumpfile and I somehow just keep on
‘missing it’?
That is one possibility, yes, but there are others. We just don't have
enough data. It would be great to see exactly what pg_dump is doing so
we know where the corruption/disconnect is. If you have access, could
you try:
I am convinced that the index definition is not in the pg_dump output.
The crux of the matter seems to be from here:
https://www.postgresql.org/message-id/78328b08-249e-4251-8a10-b5dac183442a%40aklaver.com
"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 thrown when the table is
dumped."
Where the pg_basebackup was done from the production database in order
to set up a test database and the logical dumps where done from the test
database.
Hopefully the below will tease that out.
psql -c "alter system set log_statement='all' " -c "select pg_reload_conf()"
pg_dump -t bcf_work_type --schema-only > bcf.debug
psql -c "alter system reset log_statement" -c "select pg_reload_conf()"
Then send us bcf.debug as well as the Postgres logs generated during
that request?
Cheers,
Greg
--
Adrian Klaver
[email protected]
