Re: Proposal: new ereport option "errdetail_log"

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Proposal: new ereport option "errdetail_log"
Date: 2008-03-24 23:21:02
Message-ID: 12691.1206400862@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2008-03-24 23:29:38 Re: [pgsql-www] New email list for emergency communications
Previous Message Alvaro Herrera 2008-03-24 23:16:05 Re: Proposal: new ereport option "errdetail_log"