Re: pgwin32_open returning EINVAL
От | Magnus Hagander |
---|---|
Тема | Re: pgwin32_open returning EINVAL |
Дата | |
Msg-id | 474F24F9.7000706@hagander.net обсуждение исходный текст |
Ответ на | Re: pgwin32_open returning EINVAL (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pgwin32_open returning EINVAL
|
Список | pgsql-hackers |
Tom Lane wrote: > Alvaro Herrera <alvherre@alvh.no-ip.org> writes: >> I think a reasonable compromise is to turn the ereport() in _dosmaperr >> to DEBUG1 instead. That way it won't clutter any log by default, and in >> the cases where we're actually interested in tracking the problematic >> situation, we don't need to get huge amounts of log traffic coming from >> other parts of the system. > > I'm still not convinced what you think the problematic situation is. > It's already the case (and reasonable, I think) that _dosmaperr issues a > LOG message if it sees a GetLastError code it doesn't recognize; that > addresses the problem that this thread started with. Why do we need to > make the success case chattier? I believe Alvaros point is that several different GetLastError codes map to the same errno code, making it impossible to see the difference between those errors. //Magnus
В списке pgsql-hackers по дате отправления: