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-12-13 12:55:33
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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:


(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?

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.

Alvaro Herrera
Maybe there's lots of data loss but the records of data loss are also lost.
(Lincoln Yeoh)

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Stark 2007-12-13 13:13:33 New style of hash join proposal
Previous Message Guillaume Smet 2007-12-13 12:36:37 Re: [GENERAL] Slow PITR restore