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

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

From: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Dorochevsky,Michel" <michel(dot)dorochevsky(at)softcon(dot)de>, 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 j ect
Date: 2007-04-23 19:30:44
Message-ID: 462D0964.5030609@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackerspgsql-patches
Tom Lane wrote:
> "Dorochevsky,Michel" <michel(dot)dorochevsky(at)softcon(dot)de> writes:
>> I am not used to the command line tools. So I made a backup
>> using the pgadmin GUI. I selected options 'PLAIN format', 'with OIDs' and
>> 'schema only'. See
>>     www.dorochevsky.de/infos/TestSchema.txt
>> I hope that is what you needed.
> 
> Yeah, this is great, particularly since it includes the OIDs.  However,
> the OIDs don't seem to entirely match up with the LOCK_DEBUG output.
> I'm wondering if somehow we're locking the wrong OIDs?  Hard to believe
> a bug like that could've escaped detection though.  Still trying to
> trace through it to see where things first go wrong.  (If anyone else is
> looking at this, note that a constraint's index will generally have an
> OID one less than the constraint, so you can infer the OIDs of indexes
> that aren't explicitly given in the dump.)

It looks like the table 433757 is locked three times in the transaction. 
First in RowExclusive mode, and then twice in AccessShare mode. At 
prepare time, the proclock is correctly transfered to the dummy PGPROC, 
with the lock hold in both modes. But when it comes time to commit, the 
lock is released twice in AccessShare mode.

Locking the same lock twice is usually handled correctly, I don't 
understand why it fails in this case. I'm thinking that the locallock 
structs somehow get out of sync with the lock structs in shared memory. 
The twophase-records are created from the locallock structs alone, so if 
there's extra entries in the locallocks table for some reason, we'd get 
the symptoms we have.

Unless you have a better idea, I'd like to add some more debug-prints to 
AtPrepare_Locks to see what gets written to the state file and why.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2007-04-23 19:47:20
Subject: Re: BUG #3245: PANIC: failed to re-find shared loc k o b j ect
Previous:From: Josh BerkusDate: 2007-04-23 19:26:31
Subject: Hyena down, to be replaced by other Sun systems on Buildfarm

pgsql-bugs by date

Next:From: Heikki LinnakangasDate: 2007-04-23 19:35:08
Subject: Re: BUG #3245: PANIC: failed to re-find shared loc k o b j e ct
Previous:From: Tom LaneDate: 2007-04-23 19:18:15
Subject: Re: BUG #3245: PANIC: failed to re-find shared loc k o b j e ct

pgsql-patches by date

Next:From: Tom LaneDate: 2007-04-23 19:47:20
Subject: Re: BUG #3245: PANIC: failed to re-find shared loc k o b j ect
Previous:From: Tom LaneDate: 2007-04-23 18:51:51
Subject: Re: BUG #3245: PANIC: failed to re-find shared loc k o b j ect

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