Magnus Hagander wrote:
> On Thu, Dec 20, 2007 at 10:26:46AM -0500, Tom Lane wrote:
>> Magnus Hagander <magnus@hagander.net> writes:
>>> On Wed, Dec 19, 2007 at 07:50:29PM -0500, Tom Lane wrote:
>>>> 2. Do we really want this to be WARNING? LOG seems a better idea,
>>>> since it's not warning about anything the client app did wrong.
>>> I put it as warning because I wanted to be sure the admin notices. If your
>>> database is hanging 5+ seconds to open a file, you have a *big* problem,
>>> and you need to fix it. Just putting it as LOG will probably make it much
>>> more likely it's missed.
>> This reasoning is faulty. For logging purposes, LOG is *more* severe
>> (higher priority) than WARNING. I think it's fairly common to set
>> log_min_messages = ERROR, which would mean that warnings disappear.
>> On the client side, unless you're issuing queries by hand with psql,
>> it's entirely likely that all non-error messages go into the bit bucket.
>> You can't count on anyone ever noticing them in a production app.
>>
>> Use LOG. That's what it's there for. (If you want a more formal
>> definition, I'd say it's for messages that a DBA would be interested in
>> but are not directly relevant to a client app.)
>
> Ah, wasn't aware of that at all. Then LOG certainly makes a lot more sense,
> yes. Thanks for clearifying.
I've applied a patch for this to head, to get some proper buildfarming
on it. If it passes the tests that Alvaro's contact will be running
(since they had a reasonably repeatable case), I think we should
backpatch it. But not until then...
//Magnus