Re: server process (PID 2964738) was terminated by signal 11: Segmentation fault
От
Stefan Froehlich
Тема
Re: server process (PID 2964738) was terminated by signal 11: Segmentation fault
Дата
Msg-id
20221107140504.GB7369@static.231.150.9.176.clients.your-server.de
Ответ на
Список
Дерево обсуждения
server process (PID 2964738) was terminated by signal 11: Segmentation fault Stefan Froehlich <postgresql@froehlich.priv.at>
Re: server process (PID 2964738) was terminated by signal 11: Segmentation fault Tom Lane <tgl@sss.pgh.pa.us>
Re: server process (PID 2964738) was terminated by signal 11: Segmentation fault Stefan Froehlich <postgresql@froehlich.priv.at>
Re: server process (PID 2964738) was terminated by signal 11: Segmentation fault Tom Lane <tgl@sss.pgh.pa.us>
Re: server process (PID 2964738) was terminated by signal 11: Segmentation fault Stefan Froehlich <postgresql@froehlich.priv.at>
Re: server process (PID 2964738) was terminated by signal 11: Segmentation fault Laurenz Albe <laurenz.albe@cybertec.at>
Re: server process (PID 2964738) was terminated by signal 11: Segmentation fault Mladen Gogala <gogala.mladen@gmail.com>
Re: server process (PID 2964738) was terminated by signal 11: Segmentation fault Stefan Froehlich <postgresql@froehlich.priv.at>
Re: server process (PID 2964738) was terminated by signal 11: Segmentation fault Tom Lane <tgl@sss.pgh.pa.us>
Re: server process (PID 2964738) was terminated by signal 11: Segmentation fault Stefan Froehlich <postgresql@froehlich.priv.at>
Re: server process (PID 2964738) was terminated by signal 11: Segmentation fault Ron <ronljohnsonjr@gmail.com>
Re: server process (PID 2964738) was terminated by signal 11: Segmentation fault Tom Lane <tgl@sss.pgh.pa.us>
Re: server process (PID 2964738) was terminated by signal 11: Segmentation fault Ron <ronljohnsonjr@gmail.com>
On Mon, Nov 07, 2022 at 09:02:26AM -0500, Tom Lane wrote: > Stefan Froehlich 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
В списке pgsql-general по дате отправления
От: Tom Lane
Дата:
От: Ron
Дата: