Re: win32 _dosmaperr()
От | Merlin Moncure |
---|---|
Тема | Re: win32 _dosmaperr() |
Дата | |
Msg-id | 6EE64EF3AB31D5448D0007DD34EEB3415C2D7E@Herge.rcsinc.local обсуждение исходный текст |
Ответ на | win32 _dosmaperr() ("Qingqing Zhou" <zhouqq@cs.toronto.edu>) |
Список | pgsql-hackers |
Qingqing wrote: > There were several reports of "unable to read/write" on Pg8.0.x win32 > port: > > http://archives.postgresql.org/pgsql-bugs/2005-02/msg00181.php > > I encounter this several times and finally I catch the GetLastError() > number. It is > > 32, ERROR_SHARING_VIOLATION > The process cannot access the file because it is being used by another > process. > > But PG server error message is "invalid parameter" which makes this error > difficult to understand and track. After examing win32 CRT's _dosmaperr() > implementation, I found they failed to transalte ERROR_SHARING_VIOLATION, > so > the default errno is set to EINVAL. To solve it, we can do our own > _dosmaperr(GetLastError()) again if read/write failed. Unfortunately our > _dosmaperr() failed to do so either, so here is a patch of error.c. Also, > I > raised the error level to NOTICE for better bug report. If this is > acceptable, I will patch FileRead()/FileWrite() etc. > > However, I am very sure why this could happen. That is, who uses the data > file in a non-sharing mode? There are many possibilities, a common > concensus > is [Anti-]virus software. Yes, I do have one installed. If we can confirm > this, then we could at least print a hint message. I had similar problems since the early days of the win32 port, random restarts of the stats collector and other unexplainable things. This only ever happened under heavy loads (1000+/sec sustained query processing) with statement level stats on. This played havoc with my user diagnostic tools because it randomly restarted the stats collector so I've had to keep row level stats off. Merlin
В списке pgsql-hackers по дате отправления: