2009/8/5 Magnus Hagander <magnus@hagander.net>:
> 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.
>
>
I agree with some new error attribs, but about this, I don't know. Can
you show some use case?
SQLCODE could carry enough information about user or system exception.
There are reserved space for custom codes. Maybe for administration
should be interesting, if error is system error or application error -
but this should be described by SQLCODE well too.
Pavel
> Thoughts?
>
> --
> Magnus Hagander
> Me: http://www.hagander.net/
> Work: http://www.redpill-linpro.com/
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
