Обсуждение: Re: REPOST: InitDB Failure on install

Поиск
Список
Период
Сортировка

Re: REPOST: InitDB Failure on install

От
"Magnus Hagander"
Дата:
>> In order to be future safe we ight want to do something like
>put a macro
>> in win32.h doing
>> #define Win32ErrorToErrno(i) i
>
>That was what I was gonna suggest, just in case.

Ok. I've investigated this further, and it seems we can *not* get away
this easy. There are conflicting codes, and a lot of them. We can only
get away with it if we *never* need the actual errno values - meanin if
we use *only* Win32 API calls. Which we clearly don't.

What I think we need to do in this case is map the error codes at any
"API emulation function" to always return a valid errno value, and not a
Win32 error code. This can only be done at the actual function, since it
has to be different depending on situation.

From what I can tell, only two places have this problem now. shmget()
and shmat() in backend/port/win32/shmem.c, and
backend/postmaster/syslogger.c where pipeThread() uses %m withoit
setting errno. shmget() already does the mapping, it just fails to
handle the default case.

Therefor, I propose we fix both these by adding ereport() calls in the
emulation routine (as is done in the rest of the win32 specific code),
and just returning EINVAL (or is there another better fallback).

Thoughts on this?

//Magnus

Re: REPOST: InitDB Failure on install

От
Tom Lane
Дата:
"Magnus Hagander" <mha@sollentuna.net> writes:
> What I think we need to do in this case is map the error codes at any
> "API emulation function" to always return a valid errno value, and not a
> Win32 error code. This can only be done at the actual function, since it
> has to be different depending on situation.

How does Microsoft handle this for their existing Posix-compatibility
functions?  One would think there is a mapping function somewhere in
that layer.  Were they polite enough to expose it, by any chance?

            regards, tom lane