"Dorochevsky,Michel" <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
