Postmaster crashes

Mark Alliban <MarkA@idnltd.com> wrote:

pq_recvbuf: unexpected EOF on client connection
Server process (pid 2087) exited with status 139 at Tue Feb 13 15:38:08 2001

Or signal 139 - 128 = 11. You didn't provide details about the hardware
platform and OS, so it is difficult to guess what the cause is.

This problem may indicate hardware (or hardware configuration) problems, in
particular if the signal 11s appear to be random. See
http://www.bitwizard.nl/sig11/
for details.

HTH,
Ray
--
Do Microsoft's TCO calculations include TC of downtime?

"Mark Alliban" <MarkA@idnltd.com> writes:

pq_recvbuf: unexpected EOF on client connection
Server process (pid 2087) exited with status 139 at Tue Feb 13 15:38:08 2001
Terminating any active server processes...
Server processes were terminated at Tue Feb 13 15:38:08 2001
Reinitializing shared memory and semaphores

The first line appears many times (once every few minutes) but doesn't cause
a problem. However the server then exits and the database is down.

The unexpected-EOF messages are probably unrelated to the crash. What
Postgres version are you running? There should be a corefile left from
the crashed backend --- can you get a stack trace from it? How about
running the postmaster with -d2 to log queries, so that you can see what
queries were being executed at the time of the crash?

regards, tom lane

"Mark Alliban" <MarkA@idnltd.com> writes:

pq_recvbuf: unexpected EOF on client connection
Server process (pid 2087) exited with status 139 at Tue Feb 13 15:38:08

2001

Terminating any active server processes...
Server processes were terminated at Tue Feb 13 15:38:08 2001
Reinitializing shared memory and semaphores

The unexpected-EOF messages are probably unrelated to the crash.

Yes I figure these are from a client not closing connections properly.

What Postgres version are you running? There should be a corefile left

from

the crashed backend --- can you get a stack trace from it? How about
running the postmaster with -d2 to log queries, so that you can see what
queries were being executed at the time of the crash?

7.0.3 on Redhat Linux 6.1 from RPM.

Core was generated by `/usr/bin/postgres 172.16.1.2 postgres'.
Program terminated with signal 11, Segmentation fault.
#0 0x80aa10a in DLGetSucc ()

Signal 11 was already suggested, which probably means hardware problems. I
know the machine has a flaky power supply which causes it to power-cycle on
a daily basis, so this seems to me to be a likely cause of these errors too.
I can't enable -d2 because this is a live production database and there is
so much activity that logging slows the system down too much and generates
huge files. The problem is not reproducable on test systems, which further
suggests to me that it is a hardware problem. Time to replace it I think.

Thanks,
Mark.

"Mark Alliban" <MarkA@idnltd.com> writes:

Program terminated with signal 11, Segmentation fault.
#0 0x80aa10a in DLGetSucc ()

Signal 11 was already suggested, which probably means hardware problems.

Either that or software bugs... as an ex-electrical engineer, I always
blame the software first ;-)

But if you can't reproduce the problem on another machine, hardware
problems do sound like a plausible explanation.

regards, tom lane

hello

i want to find the differences between two database schemas...is there a
function for this or do i just pg_dump both of them and do a diff in unix?

thanks
chris

On Thu, Mar 01, 2001 at 10:21:53AM -0500, some SMTP stream spewed forth:

hello

i want to find the differences between two database schemas...is there a
function for this or do i just pg_dump both of them and do a diff in unix?

As far as I know, such a function (or program/script) does not exist.

It occured to me a few days ago that such a beast would be useful, but I
have to finish the projects that are two months behind, first. ;-/

dan