From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | Zeugswetter Andreas ADI SD <Andreas(dot)Zeugswetter(at)s-itsolutions(dot)at>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pgwin32_open returning EINVAL |
Date: | 2007-12-20 15:26:46 |
Message-ID: | 11461.1198164406@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Magnus Hagander <magnus(at)hagander(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2007-12-20 15:28:57 | Re: pgwin32_open returning EINVAL |
Previous Message | Magnus Hagander | 2007-12-20 15:26:41 | Re: pgwin32_open returning EINVAL |