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: 20071129222351.GQ9567@alvh.no-ip.org (view raw or flat)
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:
> > 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)

In response to

Responses

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-2014 The PostgreSQL Global Development Group