Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-admin by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group