Re: pgwin32_open returning EINVAL - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pgwin32_open returning EINVAL
Date
Msg-id 11461.1198164406@sss.pgh.pa.us
Whole thread Raw
In response to Re: pgwin32_open returning EINVAL  (Magnus Hagander <magnus@hagander.net>)
Responses Re: pgwin32_open returning EINVAL  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
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.)
        regards, tom lane


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: pgwin32_open returning EINVAL
Next
From: Magnus Hagander
Date:
Subject: Re: pgwin32_open returning EINVAL