Re: BUG #3245: PANIC: failed to re-find shared loc k o b ject
From: Dave Page [mailto:dpage@postgresql.org]
Heikki Linnakangas wrote:Dave, could you do another build with LOCK_DEBUG enabled? Michel, could
you please add trace_locks=on to postgresql.conf, and run the test one
more time with the LOCK_DEBUG-enabled build. That should give us a much
better picture of what's happening. (be warned, it can generate a lot of
log...)
Sure - Michel, please download from
http://developer.pgadmin.org/~dpage/postgres-8.2.3-debug2.zip.This is the same as the release version, but with
--enable-debug
--enable-cassert
-DLOCK_DEBUG
Tom's patch
Heikki's LOCK_DEBUG patch.
Tom and Heikki,
Here are two panic runs with the Heikki's LOCK_DEBUG patched postgres:
www.dorochevsky.de/infos/PostgresPanicProblem-2007-04-23.zip
The second one is shorter. I have also provided the postgres.conf for Tom.
Best Regards
-- Michel
"Dorochevsky,Michel" <michel.dorochevsky@softcon.de> writes:
Here are two panic runs with the Heikki's LOCK_DEBUG patched postgres:
www.dorochevsky.de/infos/PostgresPanicProblem-2007-04-23.zip
Ok, this does provide a new clue: the problem table is being locked
twice (under two different lock types) in the transaction, and for
some reason the lock object is discarded after the first of these is
released. Furthermore, it looks like both of the references arise
indirectly from foreign-key operations.
Since realizing that your test case doesn't seem to be doing anything
unusual, I've been trying to reproduce it here by tweaking the pgbench
script to use COMMIT PREPARED instead of just COMMIT. No luck so far,
but the pgbench test hasn't got any foreign keys, and maybe that's
important. Can you show us the schema of your database? (pg_dump -s
output would be great.)
Also, if you haven't rebuilt the schema since the second of these runs,
which table has OID 433757 now? I think it must be
requiredqualities_numb5b1c0a0a but would like to confirm that.
regards, tom lane