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!
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 |