On 3/10/26 7:43 AM, Greg Sabino Mullane wrote:
> On Tue, Mar 10, 2026 at 10:24 AM Wim Rouquart <wim.rouquart@kbc.be
> <mailto:wim.rouquart@kbc.be>> 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
adrian.klaver@aklaver.com
