From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Locale support is now on by default |
Date: | 2002-04-04 04:30:15 |
Message-ID: | 20794.1017894615@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Bruce Momjian writes:
>> If you would prefer LOG down near INFO in the server message levels,
>> please post the idea and let's get some more comments from folks.
> LOG should be below WARNING, in any case. Perhaps between NOTICE and
> WARNING, but I'm not so sure about that.
I think the ordering Bruce developed is appropriate for logging.
There are good reasons to think that per-query ERRORs are less
interesting than LOG events for admin logging purposes.
The real problem here is that in the initdb context, we are really
dealing with an *interactive* situation, where LOG events ought to
be treated in the client-oriented scale --- but the backend does
not know this, it thinks it is emitting messages to the system log.
I'm thinking that the mistake is in hard-wiring one scale of message
interest to control the frontend output and another one to the "log"
(stderr/syslog) output. Perhaps we should have a notion of "interactive"
message priorities vs "logging" message priorities, and allow either
scale to be used to control which messages are dispatched to any
message destination.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-04-04 04:45:57 | Re: Locale support is now on by default |
Previous Message | Hiroshi Inoue | 2002-04-04 04:27:41 | Re: timeout implementation issues |