Re: [HACKERS] Proposal: new ereport option "errdetail_log"

[Decibel!]

On Mar 24, 2008, at 6:21 PM, Tom Lane wrote:

Alvaro Herrera <[EMAIL PROTECTED]> 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

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.

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

--
Decibel!, aka Jim C. Nasby, Database Architect  [EMAIL PROTECTED]
Give your computer some brain candy! www.distributed.net Team #1828

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.

smime.p7s
Description: S/MIME cryptographic signature