| From: | Stefan Froehlich <postgresql(at)froehlich(dot)priv(dot)at> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| 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:35:44 |
| Message-ID: | 20221106143544.GA4940@static.231.150.9.176.clients.your-server.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Sun, Nov 06, 2022 at 09:13:08AM -0500, Tom Lane wrote:
> > | 2022-11-06 11:52:36.367 CET [2098-35] LOG: server process (PID 2964738) was terminated by signal 11: Segmentation fault
> contrib/amcheck might help to identify the faulty data (at this
> point there's reason to fear multiple corruptions ...). If you're
> running v14 or v15 there's a frontend for that called pg_amcheck.
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
| This probably means the server terminated abnormally
| before or while processing the request.
| The connection to the server was lost. Attempting reset: Failed.
This seems to be quite fucked up ("how" would be a good question,
too, but for the moment priority is to work around the problem).
If I have to delete 1k records in this table, I'll do and survive,
but first I have to find out which ones.
Bye,
Stefan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2022-11-06 14:48:32 | Re: server process (PID 2964738) was terminated by signal 11: Segmentation fault |
| Previous Message | Erik Wienhold | 2022-11-06 14:23:19 | Re: an difficult SQL |