Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-bugs by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group