Re: seahorse again failing
От | Magnus Hagander |
---|---|
Тема | Re: seahorse again failing |
Дата | |
Msg-id | 6BCB9D8A16AC4241919521715F4D8BCEA35595@algol.sollentuna.se обсуждение исходный текст |
Ответ на | Re: seahorse again failing (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: seahorse again failing
|
Список | pgsql-hackers |
> > Tom Lane wrote: > >> It would be interesting to know the actual underlying Windows > error > >> code > >> --- I see that win32error.c maps several different codes to > EACCES. > > > It may be a good idea to put a elog(LOG) with the error code in > the > > failure path of AllocateFile. > > That seems like a plan to me. I had been thinking of making > win32error.c itself log the conversions, but that would not provide > any context information. AllocateFile could log the file name > along with the code, which should be enough info to associate a > particular log entry with the actual failure. > > Note you should probably save and restore errno around the elog > call, just to be safe. > > Could someone with access to Windows code and test this? Do you mean something as simple as this? compiles, passes regression tests, logs this on startup of a fresh cluster: LOG: win32 open error on 'global/pgstat.stat': 2 (very simple - it's a file-not-found, which is expected..) //Magnus
Вложения
В списке pgsql-hackers по дате отправления: