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

> ------- 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
constraintOID. Hope this doesn't confuse! 

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

/D

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

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