|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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 http://www.flickr.com/photos/alvherre/
Maybe there's lots of data loss but the records of data loss are also lost.
|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|