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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: [PATCHES] COPY view
Следующее
От: Hannu Krosing
Дата:
Сообщение: Re: Tricky bugs in concurrent index build