Tom Lane wrote:
Justin Pasher <just...@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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
