Magnus Hagander wrote:
> Something that keeps annoying me a lot when trying to look through
> what comes out of PostgreSQL logs is that errors generated by the user
> (syntax errors in queries, warnings due to incorrect string escaping,
> statements terminated due to timeout etc etc) are intermixed
> completely with warnings and errors from internal server functions
> like checkpoints and log archiving. This makes it much more harder
> than it should be to find the important messages.
>
> I'd like to add another field to messages called "source" (not wedded
> to the name). Initially, this could just be "user" and "internal", but
> I can see a use-case in the future for it to differ between for
> example "archiver" and "bgwriter" (it's certainly not unheard of that
> one would want to look at all output from the archiver, but ignore all
> other output). This could then be written as a field in
> log_line_prefix, and obviously included as it's own column in CVS
> output, to allow for further processing outside the database.
>
> As for the source, I think we'd just "decorate" the error messages
> with errsource(ERRSOURCE_USER) or something like that at places where
> needed, and have it default to "internal" - so we don't have to touch
> each and every error message in the backend.
Are you suggesting that all messages would have source of "internal",
until we get around to change them? That doesn't seem nice. There is a
*lot* of messages that are not internal. I think we should classify all
messages correctly, or not at all.
Decorating every ereport() seems like a daunting effort, both up-front
and to maintain. And it could not easily differentiate between e.g
"write failed" error coming from bgwriter and a backend.
Could we deduce the category through some other means? Messages related
to bgwriter or archiver, for example, would be differentiate by looking
at what the current process is.
Differentiating between "write failed because disk is full" and "syntax
error because you typoed a query" would be harder. Maybe we could
classify all messages coming from md.c and smgr.c into a "storage"
category, but you'd likely need a lot of exceptions to that rule.
Would you like to propose a concrete list sources that we would have?
The implementation effort depends a lot on the categorization.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
