Tom Lane wrote:
> Alvaro Herrera <alvherre@alvh.no-ip.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;
caseERROR_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)
