Re: Proposal: new ereport option "errdetail_log"

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal: new ereport option "errdetail_log"
Date: 2008-03-24 22:36:43
Message-ID: 87y787oikk.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Gregory Stark <stark(at)enterprisedb(dot)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!

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2008-03-24 22:37:17 Re: New email list for emergency communications
Previous Message Marc G. Fournier 2008-03-24 22:31:42 Re: New email list for emergency communications