Re: Autovacuum daemon terminated by signal 11
От | Justin Pasher |
---|---|
Тема | Re: Autovacuum daemon terminated by signal 11 |
Дата | |
Msg-id | 496FB261.8040303@newmediagateway.com обсуждение исходный текст |
Ответ на | Re: Autovacuum daemon terminated by signal 11 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Autovacuum daemon terminated by signal 11
|
Список | pgsql-general |
Tom Lane wrote: > Justin Pasher <justinp@newmediagateway.com> writes: > >> Richard Huxton wrote: >> >>> Segmentation fault - probably a bug or bad RAM. >>> >> It's a relatively new machine, but that's obviously a possibility with >> any hardware. I haven't seen any other programs experiencing problems on >> the box, but the Postgres daemon is the one that is primarily utilized, >> so it's a little biased toward that. >> > > I agree that the behavior seems a bit too specific to be a hardware > issue. > > Can you get a stack trace from the crash? You might need to restart the > postmaster under "ulimit -c unlimited" to get a core dump from the > crashing autovacuum process. > > regards, tom lane > I'm working on getting the database running on another server so I can perform more tests. So far I was able to get a copy of the cluster up and running. Once the autovacuum process kicked in, it started experiencing the same segfault on the new box. At this point, the hardware on the original box no longer seems to be a culprit (assuming the data files themselves aren't corrupted and I didn't just bring the corruption along with the cluster). I'll let you know when I get a chance to get a core dump from the process. I assume I will need a version of Postgres built with debug symbols for it to be useful? I'm not seeing one in the standard Debian repositories, so I might have to compile from source. Justin Pasher
В списке pgsql-general по дате отправления: