Greg Stark <stark@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