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

Re: Proposal: new ereport option "errdetail_log"

From: Decibel! <decibel(at)decibel(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Proposal: new ereport option "errdetail_log"
Date: 2008-04-02 22:33:38
Message-ID: 321B24DF-80FE-42AF-AE8F-C0F27D1852DB@decibel.org (view raw or flat)
Thread:
Lists: pgsql-hackers
On Mar 24, 2008, at 6:21 PM, Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>> Gregory Stark wrote:
>>> The axis on which I still see real room for improvement here is  
>>> on the
>>> description of the locks. It's awfully hard for a user to tell  
>>> from the
>>> deadlock message exactly what operation of the query was  
>>> acquiring what lock
>>> when it deadlocked.
>
>> Are the involved queries not enough?  Why?  What would you like to
>> have?
>
> Greg's certainly got a point.  Consider for example tuple-level locks
> taken as a result of an FK check --- which one, and which rows are
> involved?  Or the case where the logged query is just "SELECT
> some_huge_user_defined_function()" and you have no idea what part  
> of the
> function is triggering it.  (The CONTEXT traceback will help here  
> if the
> backend running the function is the one that errors out, but not when
> it's some other backend.)
>
> I don't have any immediate ideas for improvement either, but we
> certainly shouldn't consider this a totally solved problem.

Something I always find myself wanting when debugging locking issues  
is what's in pg_locks. Could we save that information somewhere when  
we detect a deadlock? In a real table would be nice, but I'd settle  
for just dumping it to a file somewhere. Or maybe into the logs.
-- 
Decibel!, aka Jim C. Nasby, Database Architect  decibel(at)decibel(dot)org
Give your computer some brain candy! www.distributed.net Team #1828


In response to

Responses

pgsql-hackers by date

Next:From: Decibel!Date: 2008-04-02 22:53:10
Subject: Re: TRUNCATE TABLE with IDENTITY
Previous:From: James MansionDate: 2008-04-02 21:51:41
Subject: Re: notify with payload (pgkill, notify)

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