Re: BUG #3245: PANIC: failed to re-find shared loc k o b ject

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Dorochevsky,Michel" <michel(dot)dorochevsky(at)softcon(dot)de>
Cc: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, pgsql-bugs(at)postgresql(dot)org, Dave Page <dpage(at)postgresql(dot)org>
Subject: Re: BUG #3245: PANIC: failed to re-find shared loc k o b ject
Date: 2007-04-23 16:56:04
Message-ID: 10275.1177347364@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

"Dorochevsky,Michel" <michel(dot)dorochevsky(at)softcon(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Dorochevsky,Michel 2007-04-23 17:28:22 Re: BUG #3245: PANIC: failed to re-find shared loc k o b j ect
Previous Message Magnus Hagander 2007-04-23 16:44:54 Re: BUG #3242: FATAL: could not unlock semaphore: error code 298