Re: Adding error message "source"

On Wed, Aug 5, 2009 at 16:11, Heikki
Linnakangas<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> Magnus Hagander wrote:
>> 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.

No, but under the idea I had most *would* be internal. Not until we
get around to change them, but always.

> 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.

Yes.

> 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.

That's exactly the one I want to differentiate between.

> Would you like to propose a concrete list sources that we would have?
> The implementation effort depends a lot on the categorization.

Well, the only one I have a direct usecase for is the one that is "I
want logs that are created because of typos in a psql client, or
because an application does bad things (sends broken queries, bad
escaping, NULL in not-NULL field etc) to not clutter up the log when I
look for information about checkpoints and log archiving".

I don't really have a case for making it more fine-grained like that,
but I figured someone else might have :-)

Having SQLSTATE in log_line_prefix is certainly a good thing, but I
don't see how I can easily use that to filter for this. Perhaps I'm
wrong at that? Maybe I can do something with a very long chain of
different greps on the different classes, but that seems to almost
guarantee that i'll miss something... And we seem to set for example
ERRCODE_WARNING as a default for everything that's a warning and
doesn't specify an explicit SQLSTATE - I bet that includes both
warnings that are "caused" by the client and that are "caused" by the
system.

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