Re: Re: [COMMITTERS] pgsql: On Windows, when a file is deleted and another process still has
От | Tom Lane |
---|---|
Тема | Re: Re: [COMMITTERS] pgsql: On Windows, when a file is deleted and another process still has |
Дата | |
Msg-id | 20412.1252680696@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: On Windows, when a file is deleted and another process still has (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Список | pgsql-hackers |
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes: > Here's a patch implementing that, and changing pgrename() to check for > ERROR_SHARING_VIOLATION and ERROR_LOCK_VIOLATION like pgwin32_open() > does, instead of ERROR_ACCESS_DENIED. This looks sane in a quick once-over, though I haven't tested it. One tiny stylistic suggestion: if (err != ERROR_SHARING_VIOLATION && err != ERROR_LOCK_VIOLATION)#else if (errno != EACCES)#endif return -1; if (++loops > 300) /* time out after 30 sec */ return -1; This is overly cute and will probably confuse both pgindent and ordinary editors. It's worth one extra line to keep each part of the #if syntactically independent, ie if (err != ERROR_SHARING_VIOLATION && err != ERROR_LOCK_VIOLATION) return -1;#else if(errno != EACCES) return -1;#endif if (++loops > 300) /* time out after 30 sec */ return-1; > I wonder if we should reduce the timeout in pgrename(). It's 30 s at the > moment, but apparently it hasn't been working correctly, failing > immediately instead if the file is locked. I have a vague recollection that there was a specific reason for having such a long timeout --- you might want to check the archives to see the discussion before that code got committed. However, if nothing turns up, I wouldn't object to reducing it to 5 or 10 sec. regards, tom lane
В списке pgsql-hackers по дате отправления: