Stefan Froehlich <postgresql@froehlich.priv.at> writes:
> I am using v13, but well:
> | # create extension amcheck;
> | # select oid, relname from pg_class where relname ='faultytablename_pkey';
> | [returns oid 537203]
> | # select bt_index_check(537203, true);
> | server closed the connection unexpectedly
Oh ... up through v13, amcheck lacks any functions to check heaps,
only indexes, so I guess it won't help you much. You could try
reindexing, but if pg_dump is failing that's a good sign you have
heap corruption not (or at least not only) index corruption.
Another idea is to try using contrib/pageinspect to examine each
page of the table. Its output is just gobbledegook to most people,
but there's a good chance it'd fail visibly on the corrupted page(s).
Also, please read
https://wiki.postgresql.org/wiki/Corruption
if you didn't already.
regards, tom lane
