Greg Stark <st...@mit.edu> writes: > I think log_error_verbosity is a strange variable. It's useless for > expected user-facing errors but essential for unexpected errors that > indicate bugs in the code -- and you can only have it on for > everything or off for everything.
> I'm finding I usually want it set to 'verbose' for anything that > PANICs or is generated by an elog() but it's just noise for anything > generated by an ereport() and is ERROR or below. > The minimum suggested change would to make it implicitly true for > PANIC and any unexpected elog()s and leave the GUC for enabling it in > the other cases. Hm. I'm okay with the PANIC idea, I think, but the other not so much. That would change the rule of thumb that "elog is for non user facing errors" into something more than just permission to be lazy. In particular, elog currently is (and is documented to be) equivalent to an ereport call with suitable parameters. I'm not terribly happy about losing that equivalence, because I don't think that people have been especially careful about which to use. contrib is still full of user-facing conditions reported via elog, for instance, and I expect that third-party code is worse. [ thinks for a bit... ] A slightly cleaner approach is to nominate a specified set of SQLSTATEs, certainly including XX000 and perhaps some others, as being ones that force verbose reporting. That would have the same practical effect as far as elogs go, but wouldn't break the nominal functional equivalence. And that brings up the previous work on SQLSTATE-dependent choices about whether to log at all. I remember a patch was submitted for that but don't remember offhand why it didn't get committed. ISTM we should think about reviving that and making the choice be not just "log or not", but "no log, terse log, normal log, verbose log". regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers