On Wed, Aug 5, 2009 at 16:11, Heikki Linnakangas<heikki.linnakan...@enterprisedb.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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
