Skip site navigation (1) Skip section navigation (2)

Re: pgwin32_open returning EINVAL

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgwin32_open returning EINVAL
Date: 2007-11-29 22:23:51
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
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:
> >
> > 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:

        switch (err)
                /* EMFILE, ENFILE should not occur from CreateFile. */
            case ERROR_PATH_NOT_FOUND:
            case ERROR_FILE_NOT_FOUND:
                errno = ENOENT;
            case ERROR_FILE_EXISTS:
                errno = EEXIST;
            case ERROR_ACCESS_DENIED:
                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                     
"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 HaganderDate: 2007-11-29 22:38:45
Subject: Re: pgwin32_open returning EINVAL
Previous:From: Tom LaneDate: 2007-11-29 22:21:09
Subject: Re: Status report on 8.3 release

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group