Re: [HACKERS] Re: Backend core dump, Please help, Urgent!

> Sure sounds like a corrupted-data problem.  Can you use gdb on the
> corefiles to get a backtrace of what they were doing?
> 
> > My biggest hang-up is why all of a sudden?
> 
> Good question.  We'll probably know the answer when we find the problem.

Besides the problem Tom has pointed out its possibility, there is a
known problem with 6.5.x on FreeBSD. It would be rather important,
since it results in a core dump as well. The problem occurs while a
backend is waiting for acquiring a lock. Thus it tends to happen on
relatively heavy load (I observed the problem starting with 4
concurrent transactions). As far as I know, Linux does not have the
problem at all, but FreeBSD does. I'm not sure about other
platforms. Solaris seems to be not suffered.

You could try following patch. It was made for 6.5.3, but you could
apply it to 6.5.1 or 6.5.2 as well. Current has been already fixed
with more complex and long-term-aid solution. But I would prefer to
minimize the impact to existing releases. Keeping that in mind, I have
made the patch the simplest.
--
Tatsuo Ishii

---------------------------- cut here -----------------------------
*** postgresql-6.5.3/src/backend/storage/lmgr/lock.c~    Sat May 29 15:14:42 1999
--- postgresql-6.5.3/src/backend/storage/lmgr/lock.c    Mon Dec 13 16:45:47 1999
***************
*** 940,946 **** {     PROC_QUEUE *waitQueue = &(lock->waitProcs);     LOCKMETHODTABLE *lockMethodTable =
LockMethodTable[lockmethod];
!     char        old_status[64],                 new_status[64];      Assert(lockmethod < NumLockMethods);
--- 940,946 ---- {     PROC_QUEUE *waitQueue = &(lock->waitProcs);     LOCKMETHODTABLE *lockMethodTable =
LockMethodTable[lockmethod];
!     static char        old_status[64],                 new_status[64];      Assert(lockmethod < NumLockMethods);