From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stefan Froehlich <postgresql(at)froehlich(dot)priv(dot)at> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: server process (PID 2964738) was terminated by signal 11: Segmentation fault |
Date: | 2022-11-06 14:48:32 |
Message-ID: | 3010779.1667746112@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Stefan Froehlich <postgresql(at)froehlich(dot)priv(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Rafal Pietrak | 2022-11-06 15:48:59 | Re: an difficult SQL |
Previous Message | Stefan Froehlich | 2022-11-06 14:35:44 | Re: server process (PID 2964738) was terminated by signal 11: Segmentation fault |