Re: diagnosing a db crash - server exit code 2

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Burgholzer, Robert (DEQ)" <Robert(dot)Burgholzer(at)deq(dot)virginia(dot)gov>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: diagnosing a db crash - server exit code 2
Date: 2011-09-25 23:54:21
Message-ID: 10606.1316994861@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

"Burgholzer, Robert (DEQ)" <Robert(dot)Burgholzer(at)deq(dot)virginia(dot)gov> writes:
> I am trying to get my head around why I keep getting crashes to my PG
> 8.3.7 database on CentOS - Linux version 2.6.18-164.el5.
> LOG: server process (PID 5978) exited with exit code 2

Just like it says, this implies that a backend process exited with
"exit(2)". A quick grep through the 8.3 sources says that the only such
call in the backend code is in the SIGQUIT signal handler. Now it's
possible that what you're seeing is an exit(2) somewhere in the R
library rather than in Postgres code. But I think it's more likely that
some external source is SIGQUIT'ing the backend. Joe suggested an OOM
kill, but I've never heard of the OOM code using anything but SIGKILL
(signal 9). Have you got any other software that runs as root and
thinks it's licensed to kill processes in the name of
something-or-other?

Anyway, I concur with the plan of getting a stack trace to determine
where the exit call is, so that we can positively eliminate (or not)
the R library.

regards, tom lane

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Mridul Mathew 2011-09-26 10:36:17 PostgreSQL question
Previous Message MirrorX 2011-09-25 12:15:34 standby becomes primary and then?