| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: PATCH: backtraces for error messages |
| Date: | 2018-06-20 17:51:13 |
| Message-ID: | CA+TgmobC8zKGYZiOEZUMWTGcSgKLeNDNU+SCWewXA9pvFWqSKg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jun 20, 2018 at 1:15 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> I don't think that's ok. It's perfectly possible to hit
> ERRCODE_INTERNAL_ERROR at a high frequency in some situations,
Really? How?
> and
> there's plenty cases that aren't ERRCODE_INTERNAL_ERROR where we'd want
> this. E.g. a lot of generic filesystem errors have
> errcode_for_file_access(), but are too generic messages to debug. So I
> think we'll just need a separate GUC for things that aren't PANIC and
> haven't explicitly opt-ed in.
Mmph. I don't like that much. I mean I can hold my nose, but I hope
we can find a way to do better.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Korotkov | 2018-06-20 17:54:29 | Re: [HACKERS] WIP: long transactions on hot standby feedback replica / proof of concept |
| Previous Message | Andres Freund | 2018-06-20 17:50:28 | Re: Avoiding Tablespace path collision for primary and standby |