Peter Geoghegan <pe...@2ndquadrant.com> wrote: > Currently the following informal categories of error are bunched > together at ERROR severity: > > * Integrity constraint violations > * Very serious situations, like running out of disk space > * Serious disasters that often relate to hardware failure, like > "xlog flush request %X/%X is not satisfied --- flushed only to > %X/%X" > * Errors that if seen relate to a bug within PostgreSQL, with > obscure error messages, as from most of the elog calls within the > planner, for example. You forgot a few: * Syntax errors in submitted statements. * State-related errors, like trying to execute VACUUM in a transaction or trying to UPDATE a row in a READ ONLY transaction. * Serialization failures. * RAISE EXCEPTION from inside a function; often because of a validation in a BEFORE trigger function. If you tilt your head just right you can see these as constraint violations, but I think it is different enough to deserve specific mention. * Violations of security policy. * Loss of connection to a client.
I'm sure I didn't cover them all, but the wide variety of causes should be recognized when considering a change like adding a new severity level. The fact is, these all are (or at least *should be*) coded with a SQLSTATE to classify the nature of the problem. Adding one more severity level forces us to examine every class of error and determine whether it should be promoted to "severe". Perhaps a better solution would be to allow some filtering of error SQLSTATE values to determine what action is taken? Changes would be more localized, and it would provide greater flexibility. The comments earlier in the thread about this helping translation don't make sense to me. In what way would a new severity level help with that? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
