SEO

#1 (**permalink**) 04-10-2008, 10:44 AM

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

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

#2 (**permalink**) 04-10-2008, 10:45 AM

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

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

SEO

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