Re: proposal: additional error fields

Noah Misch <noah(at)leadboat(dot)com> writes:
> I agree that some means to mechanically distinguish these cases would
> constitute a significant boon for admin monitoring. Note, however, that the
> same split appears at other severity levels:

> FATAL, routine: terminating connection due to conflict with recovery
> FATAL, critical: incorrect checksum in control file
> WARNING, routine: nonstandard use of escape in a string literal
> WARNING, critical: locallock table corrupted

> We'd be adding at least three new severity levels to cover the necessary
> messages by this approach.

The reason why this is a problem is that the severity level is simply
the wrong thing for this. Really, there are four severity levels in
elog.c, and what they have to do with is the post-error path of control:

NOTICE: return to caller
ERROR: longjmp to someplace that can recover
FATAL: end the session
PANIC: crash, forcing database-wide restart

We haven't done ourselves any favors by conflating a log-verbosity
setting, which is what the subflavors of NOTICE really are, with this
fundamental path-of-control issue. Adding subflavors of ERROR isn't
going to make that better.

To make matters worse, the severity level for a given error condition
is not fixed, but can be context sensitive; for instance we sometimes
promote ERROR to FATAL or PANIC if the backend's state is such that
normal error recovery is inappropriate or possibly unsafe. Not to
mention the numerous places that actually have logic to decide which
severity level to report to begin with.

So to do what Peter wants by means of severity levels, we'd need the
same subflavors of FATAL and PANIC as well, which gets out of hand
really quickly from a maintenance standpoint, and makes the scheme not
nearly as user-friendly or easy to understand as he hopes, anyway.
(Now it's possible that you could get away with lumping all PANICs
into one "sound the alarms" category, but this is surely not the case
for FATAL. Unless you want to be gotten out of bed anytime somebody
fat-fingers their username or password.)

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. We might wish to move a small number of
messages from one category to another to make the boundaries a bit
clearer, but that would be vastly less painful for both implementors
and users than inventing multiple new severity levels.

regards, tom lane