From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Adding error message "source" |
Date: | 2009-08-06 12:19:12 |
Message-ID: | 9837222c0908060519p4a26a121le0ca6e8a67115935@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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/
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2009-08-06 13:32:29 | Re: Re: [Pg-migrator-general] Composite types break pg_migrated tables |
Previous Message | Magnus Hagander | 2009-08-06 12:04:50 | Re: Re: [COMMITTERS] pgsql: Reserve the shared memory region during backend startup on |