David Christian <[EMAIL PROTECTED]> writes:
> On Thursday, Sep 19, 2002, at 18:33 US/Eastern, Tom Lane wrote:
>> There should be a core file left in the database subdirectory after
>> the assert failure --- would you gdb it and get a stack trace from it?

> Unfortunately, I see no core file under the source tree after the 
> assert failure.

If you are using "make check" then look for
src/test/regress/tmp_check/data/base/*/core

If you don't see one then you must be running with a ulimit setting that
forbids core dumps --- try "ulimit -c unlimited" before starting the 
postmaster.

> TRAP: Failed Assertion("!(lock->shared > 0):", File: "lwlock.c", Line: 
> 434)

This confirms my suspicion that something is busted in lock handling on
your machine, but there's not enough info here to tell just what.  We
still need a stack trace.

Another interesting line of attack would be to try compiling 
src/backend/storage/lmgr/lwlock.c at different optimization levels,
to see if the problem goes away with less optimization.  We saw a
problem on AIX (if memory serves) before 7.2 release that turned out
to be due to overaggressive optimization by the compiler.  We thought
we'd added enough "volatile" keywords to lwlock.c to discourage any
code rearrangement, but maybe we still need more.

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

Reply via email to