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
The routine I'm talking about (pgwin32_open) has this:
/* EMFILE, ENFILE should not occur from CreateFile. */
errno = ENOENT;
errno = EEXIST;
errno = EACCES;
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)
In response to
pgsql-hackers by date
|Next:||From: Magnus Hagander||Date: 2007-11-29 22:38:45|
|Subject: Re: pgwin32_open returning EINVAL|
|Previous:||From: Tom Lane||Date: 2007-11-29 22:21:09|
|Subject: Re: Status report on 8.3 release |