Re: Proposal: new ereport option "errdetail_log" - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Proposal: new ereport option "errdetail_log"
Date
Msg-id 87y787oikk.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: Proposal: new ereport option "errdetail_log"  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Proposal: new ereport option "errdetail_log"  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> Gregory Stark <stark@enterprisedb.com> writes:
>> I wonder how useful it is to output process ids at all. And for that matter
>> whether leaking process ids alone could be considered a security risk.
>
> Seems overly paranoid, especially considering we've output that
> information after a deadlock for many years and no one's complained.

Well I was coming at it from the other direction -- questioning whether it's
at all useful and if it's not whether there's any marginal downside even if
it's slight.

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.

I'm not sure how to improve that though. It's an inherent problem that
understanding deadlocks requires understanding a certain amount of internal
implementation details.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support!


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [pgsql-www] New email list for emergency communications
Next
From: Bruce Momjian
Date:
Subject: Re: [pgsql-www] New email list for emergency communications