Re: [HACKERS] log_error_verbosity and unexpected errors
On 02/07/14 22:10, Tom Lane wrote: 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. [...] [ 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. I had a patch for making log_min_error_statement configurable per SQLSTATE in https://commitfest.postgresql.org/action/patch_view?id=1360 but you pointed out various issues in it and I didn't have time to update it for 9.4. I'm going to rewrite it based on the comments and submit it again for a 9.5 commitfest. The same mechanism could be used to set verbosity per SQLSTATE. / Oskari -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] log_error_verbosity and unexpected errors
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
Re: [HACKERS] log_error_verbosity and unexpected errors
On Wed, Jul 2, 2014 at 2:10 PM, Tom Lane t...@sss.pgh.pa.us wrote: 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. That's a really nifty idea. If you recall, I griped a while back about the fact that there was no good setting for the psql VERBOSITY switch. In particular, it would be nice to have context for errors but not for notices. Marko had proposed a new verbosity level (see commentary leading to unfinished patch here; http://postgresql.1045698.n5.nabble.com/PL-pgSQL-RAISE-and-error-context-td5768176.html). Not trying to hijack your thread, just wondering out load if a SQLSTATE driven verbosity decision, if you were to do that, could/should also be hooked to client console logging and/or psql. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] log_error_verbosity and unexpected errors
Merlin Moncure mmonc...@gmail.com writes: Not trying to hijack your thread, just wondering out load if a SQLSTATE driven verbosity decision, if you were to do that, could/should also be hooked to client console logging and/or psql. Yeah, you could certainly argue that a similar facility on the client side would be equally useful. That would also lend some support to my gut feeling that it should not be elog-vs-ereport that drives the decision, because the client is not going to be able to tell which was used. But the client side could have functionally equivalent behavior if it were based on SQLSTATE and/or severity level. 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
