Re: pgwin32_open returning EINVAL
От | Magnus Hagander |
---|---|
Тема | Re: pgwin32_open returning EINVAL |
Дата | |
Msg-id | 476AD0AE.6080600@hagander.net обсуждение исходный текст |
Ответ на | Re: pgwin32_open returning EINVAL (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: pgwin32_open returning EINVAL
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: