Re: pgwin32_open returning EINVAL

Alvaro Herrera wrote:
> Tom Lane wrote:
>> Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
>>> Tom Lane wrote:
>>>> (2) Do we have any live cases where we must know this?
>>> Yes. This thread shows the problem:
>>> http://archives.postgresql.org/pgsql-es-ayuda/2007-11/msg00354.php
>>> Basically he is getting this error:
>>> 2007-11-16 14:54:16 ERROR: could not open relation 1663/16403/16487: Invalid argument
>> Well, since EINVAL is the default result from _dosmaperr, and none of
>> the cases it represents are "expected", why don't we just remove all of
>> the explicit mappings to EINVAL from doserrors[]? Then we will get the
>> LOG message you need, and we won't have to increase the chattiness level
>> for anything else.
>
> Well, the problematic routine is not already using _dosmaperr currently.
> It is doing it's own mapping and neglecting to report anything. In
> fact, after all the problems that appeared after Magnus proposed to use
> _dosmaperr, I'm inclined to go with my original suggestion: don't use
> _dosmaperr at all and instead add an ereport(LOG) with the Windows error
> code.

That'll just cause the same problem in a different location, no? We'd
still be logging too often?

If we want to avoid duplicate code, we could go around to your idea of
being able to specify the elog level, by creating a _dosmaperr_internal
that takes that as parameter, and then have _dosmaperr call it with
DEBUG5 as argument... But that's only if we think it's ok for
pgwin32_open() to log that much - I thought we didn't like that?

> The routine I'm talking about (pgwin32_open) has this:
>
> switch (err)
> {
> /* EMFILE, ENFILE should not occur from CreateFile. */
> case ERROR_PATH_NOT_FOUND:
> case ERROR_FILE_NOT_FOUND:
> errno = ENOENT;
> break;
> case ERROR_FILE_EXISTS:
> errno = EEXIST;
> break;
> case ERROR_ACCESS_DENIED:
> errno = EACCES;
> break;
> default:
> errno = EINVAL;
> }
>
> So _anything_ could be EINVAL. Including the several cases that
> _dosmaperr treat as EACCES. So I'm afraid that for this experiment to
> be successful, we would have to remove not only the EINVAL cases from
> doserrors[], but also any other code that appears more than once on it.
> Otherwise the output could be ambiguous.
>

Could be, but may not be :P

//Magnus