Re: pgwin32_open returning EINVAL

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgwin32_open returning EINVAL
Date: 2007-12-14 14:45:09
Message-ID: 20071214144509.GO8232@svr2.hagander.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Dec 13, 2007 at 09:55:33AM -0300, Alvaro Herrera wrote:
> Alvaro Herrera wrote:
>
> > 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.
>
> OK, this got tested by the original reporter and the result is this:
>
> 2007-12-12 10:55:49 ERROR: could not open relation 1663/16403/1247: Permission denied
>
> I think this is EACCES, right? So we now need to know which one it is:
>
> ERROR_ACCESS_DENIED
> ERROR_CURRENT_DIRECTORY
> ERROR_LOCK_VIOLATION
> ERROR_SHARING_VIOLATION
> ERROR_NETWORK_ACCESS_DENIED
> ERROR_CANNOT_MAKE
> ERROR_FAIL_I24
> ERROR_DRIVE_LOCKED
> ERROR_SEEK_ON_DEVICE
> ERROR_NOT_LOCKED
> ERROR_LOCK_FAILED
>
> (These are the Win32 codes mapped to EACCES by our _dosmaperr.)
>
> Many of these are nonsensical -- we know this is not a device, nor
> network access. Still there is more than one possibility, and I don't
> know which ones should be really acceptable in this context or not.
> (What's ERROR_FAIL_I24??) SHARING_VIOLATION seems the most likely
> problem; an antivirus perhaps?

If you have an antivirus running on the system, you really should get rid
of taht long before you start looking at the code...

But you still have a point :-)

I take it it's not reproducible enough to run at DEBUG5 until it happens?

> My suggestion continues to be: these codes oughta be logged separately
> from the strerror() message. If there are cases which we know are
> deemed to occur in regular operation, let's suppress only those. None
> of them is one of these EACCES, AFAIR.

Ok. Say we added a third field to the struct named "verbose" which
indicates which values shuold be logged? And then log those separately
("mapped error %i to %i" or similar). The clearest message would be if we
could log it at the point of the caller, but that's not a reasonable change
IMHO (would change every single caller). But this way we could at least get
something traceable. What level would you have that logged?

//Magnus

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2007-12-14 14:54:41 Re: Negative LIMIT and OFFSET?
Previous Message Simon Riggs 2007-12-14 14:41:49 Re: Negative LIMIT and OFFSET?