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

Started by Dave Pagealmost 19 years ago3 messagesbugs
Jump to latest
#1Dave Page
dpage@pgadmin.org

------- Original Message -------
From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Dorochevsky,Michel" <michel.dorochevsky@softcon.de>
Sent: 23/04/07, 19:51:51
Subject: Re: [BUGS] BUG #3245: PANIC: failed to re-find shared loc k o b j ect

"Dorochevsky,Michel" <michel.dorochevsky@softcon.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.)

For Michel's benefit; pgAdmin 1.6.3 and below incorrectly display the index OID for unique/pkey constraints, not the constraint OID. Hope this doesn't confuse!

The next version will correct the bug and display the index OID as well for good measure.

/D

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Dave Page (#1)

I wrote:

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?

This may be a false alarm --- I had forgotten that relation locks are
taken at Parse or Bind time, hence the lock-grabbing associated with a
given command will be logged *before* the exec_execute_message log
entry. Still sifting through the log, but thought I'd better mention
this in case anyone else is equally confused.

There is one completely unexplainable bit here, though: I see no
evidence of LOCKTAG_TRANSACTION locks being taken or released anywhere
in this log excerpt. That makes no sense to me ... anyone?

regards, tom lane

#3Heikki Linnakangas
heikki.linnakangas@enterprisedb.com
In reply to: Tom Lane (#2)

Tom Lane wrote:

There is one completely unexplainable bit here, though: I see no
evidence of LOCKTAG_TRANSACTION locks being taken or released anywhere
in this log excerpt. That makes no sense to me ... anyone?

They're filtered out by the trace_lock_oidmin test.

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