Re: Proposal: new ereport option "errdetail_log"
От | Gregory Stark |
---|---|
Тема | Re: Proposal: new ereport option "errdetail_log" |
Дата | |
Msg-id | 87y787oikk.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответ на | Re: Proposal: new ereport option "errdetail_log" (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Proposal: new ereport option "errdetail_log"
|
Список | 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 по дате отправления: