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)lists(dot)postgresql(dot)org |
Subject: | Re: server process (PID 2964738) was terminated by signal 11: Segmentation fault |
Date: | 2022-11-07 14:02:26 |
Message-ID: | 3192952.1667829746@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:
> On Mon, Nov 07, 2022 at 08:17:10AM -0500, Mladen Gogala wrote:
>> On 11/7/22 06:19, Laurenz Albe wrote:
>>> Don't continue to work with that cluster even if everything seems OK now.
>>> "pg_dumpall" and restore to a new cluster on good hardware.
>> Why would that be necessary if the original machine works well now?
> I can understand the idea not to trust hardware anymore once a (not
> clearly identified) problem occured.
> In this case new hardware would - for reasons beyond the scope of
> this list - not be any more or less trustworthy than the existing
> one and thus (IMO) not make any difference.
Whether you want to continue to trust the hardware or not is your
call. It'd still be recommendable to pg_dumpall and restore into
a freshly-initdb'd cluster, because otherwise you can't be real
sure that you identified and cleared all the data corruption.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Stefan Froehlich | 2022-11-07 14:05:04 | Re: server process (PID 2964738) was terminated by signal 11: Segmentation fault |
Previous Message | Stefan Froehlich | 2022-11-07 13:47:10 | Re: server process (PID 2964738) was terminated by signal 11: Segmentation fault |