Re: pgwin32_open returning EINVAL

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.

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.

--
Alvaro Herrera http://www.PlanetPostgreSQL.org/
"El Maquinismo fue proscrito so pena de cosquilleo hasta la muerte"
(Ijon Tichy en Viajes, Stanislaw Lem)