Re: Proposal: new ereport option "errdetail_log"

On Mar 24, 2008, at 6:21 PM, Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.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@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828