Re: pgwin32_open returning EINVAL

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: pgwin32_open returning EINVAL
Дата
Msg-id 20071220152857.GC26753@svr2.hagander.net
обсуждение исходный текст
Ответ на Re: pgwin32_open returning EINVAL  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: pgwin32_open returning EINVAL  (Magnus Hagander <magnus@hagander.net>)
Список pgsql-hackers
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.


//Magnus


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pgwin32_open returning EINVAL
Следующее
От: "Trevor Talbot"
Дата:
Сообщение: Re: pgwin32_open returning EINVAL