Adding error message "source" - Mailing list pgsql-hackers

From Magnus Hagander
Subject Adding error message "source"
Date
Msg-id 9837222c0908050444v4b4f5a18l424425200debf2ba@mail.gmail.com
Whole thread Raw
Responses Re: Adding error message "source"  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Adding error message "source"  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Re: Adding error message "source"  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
Since Alvaro is talking about error messages in another thread, I
figured I should post this idea now as well.

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.

Sometime in the future I am considering implementing the ability to
filter messages to different targets (files, syslog facilities,
whatever), and this would also be a very interesting field to do such
filtering on. But that's for sometime much further in the future, I
haven't even started thinking about *how* to do that. But it's another
possible use-case for this decoration.


Thoughts?

-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: the case for machine-readable error fields
Next
From: Michael Meskes
Date:
Subject: Re: ECPG dynamic cursor, SQLDA support