Stefan Froehlich <postgresql@xxxxxxxxxxxxxxxxx> 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
