Re: proposal: additional error fields
От | Pavel Stehule |
---|---|
Тема | Re: proposal: additional error fields |
Дата | |
Msg-id | CAFj8pRCus5NSQDQ=QtTiK_SxFS4AqKDRCBzOfLMKYzvREDPhUw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: proposal: additional error fields (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
2012/5/2 Robert Haas <robertmhaas@gmail.com>: > On Tue, May 1, 2012 at 4:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I continue to maintain that the SQLSTATE is a much better basis for >> solving this problem. Its categories are already pretty close to >> what Peter needs: basically, IIUC, he wants to know about classes >> 53, 58, maybe F0, and XX. > > This is really too mushy, IMHO. ERRCODE_TOO_MANY_CONNECTIONS isn't > what I'd call an oh-shit condition even though it's in class 53, but > this "could not create archive status file \"%s\"" is definitely an > oh-shit regardless of what errcode_for_file_access() returns. > > Also, the fact is that most people do not log SQLSTATEs. And even if > they did, they're not going to know to grep for 53|58|maybe F0|XX. > What we need is an easy way for people to pick out any log entries > that represent conditions that should never occur as a result of any > legitimate user activity. Like, with grep. And, without needing to > have a PhD in Postgresology. long time I wish Pg supports more log files and now I had to write extension for forwarding slow queries to other log. so possible solutions can be extension that support mapping, forwarding, post processing of log items. We have no example for log_hook still. Regards Pavel > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: