Re: BUG #3245: PANIC: failed to re-find shared loc k o b ject
От | Tom Lane |
---|---|
Тема | Re: BUG #3245: PANIC: failed to re-find shared loc k o b ject |
Дата | |
Msg-id | 10275.1177347364@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #3245: PANIC: failed to re-find shared loc k o b ject ("Dorochevsky,Michel" <michel.dorochevsky@softcon.de>) |
Список | pgsql-bugs |
"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
В списке pgsql-bugs по дате отправления: