Re: pgwin32_open returning EINVAL
От | Andrew Dunstan |
---|---|
Тема | Re: pgwin32_open returning EINVAL |
Дата | |
Msg-id | 476413E9.1020706@dunslane.net обсуждение исходный текст |
Ответ на | Re: pgwin32_open returning EINVAL (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: pgwin32_open returning EINVAL
|
Список | pgsql-hackers |
Magnus Hagander wrote: > Alvaro Herrera wrote: > >> Magnus Hagander wrote: >> >>> On Thu, Dec 13, 2007 at 09:55:33AM -0300, Alvaro Herrera wrote: >>> >>>> 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... >>> >> FWIW I noticed by accident that the latest stable version of a >> not-competing database system has fixed a related bug: >> >> http://bugs.mysql.com/bug.php?id=9709 >> (yes, it only took them two and a half years to fix it). >> >> Note that their behavior on finding SHARING_VIOLATION or LOCK_VIOLATION >> is to retry forever until the error goes away, on the theory that the >> antivirus/backup software will soon release the file. >> > > Interesting. Maybe forever is going a bit too far, but retrying for <n> > seconds or so. > > So assuming we'd want to do that, how do we do it. If it's just the > "open" operation that needs it, we can probably just stick the retry in > the port file for that. But do we need to be able to retry on say > read/write as well? > > > Let's start with open and see what happens - we're surely going to need it there anyway. We already have a 30 second retry loop in unlink. cheers andrew
В списке pgsql-hackers по дате отправления: