On Thu, 18 Nov 2004 10:17:21 -0500, Tom Lane <tgl (AT) sss (DOT) pgh.pa.us> wrote:
Ok, it just happened again, and this is what showed up in the log just before:

PANIC: XX000: stuck spinlock (0x4035a0a0) detected at lwlock.c:242
LOCATION: s_lock_stuck, s_lock.c:36
LOG: 00000: server process (PID 13804) was terminated by signal 6
LOCATION: LogChildExit, postmaster.c:2087
LOG: 00000: terminating any other active server processes
LOCATION: CleanupProc, postmaster.c:2008

Earlier in the night, however, it also crashed and this is what preceded it:

LOG: 00000: server process (PID 20195) was terminated by signal 11
LOCATION: LogChildExit, postmaster.c:2087
LOG: 00000: terminating any other active server processes
LOCATION: CleanupProc, postmaster.c:2008

I don't know if it's relevant, but Postgres does bring itself back up
after the crash:

LOG: 00000: all server processes terminated; reinitializing
LOCATION: reaper, postmaster.c:1920
LOG: 00000: database system was interrupted at 2004-11-18 15:06:58 GMT

It'll probably crash again in 3-4 hours; if I get any more info I'll pass it on.

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Mike Richards <mrmikerich (AT) gmail (DOT) com> writes:
If you were getting just one of these then I might think you'd come
across a previously unknown PG bug. Given the variety of failure modes,
though, I'm strongly inclined to suspect that the common root cause is
flaky RAM. Time to get out memtest86 or some such tool.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo (AT) postgresql (DOT) org