| From: | Stefan Froehlich <postgresql(at)froehlich(dot)priv(dot)at> |
|---|---|
| To: | |
| 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:05:04 |
| Message-ID: | 20221107140504.GB7369@static.231.150.9.176.clients.your-server.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Mon, Nov 07, 2022 at 09:02:26AM -0500, Tom Lane wrote:
> 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.
Thanks, yes. This is in fact on my schedule for the next weekend as
it implies a downtime of serveral hours.
Bye,
Stefan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ron | 2022-11-07 14:40:21 | Re: server process (PID 2964738) was terminated by signal 11: Segmentation fault |
| Previous Message | Tom Lane | 2022-11-07 14:02:26 | Re: server process (PID 2964738) was terminated by signal 11: Segmentation fault |