Bruce Momjian schrieb:
Reini Urban wrote:
Bruce Momjian schrieb:
OK, care to submit a patch. As I remember the fix for rename/unlink also includes how the file is opened with flags. Anyway, we spent a lot of time on this so you will have to go back in the archvies to find it and determine how it can be improved.
Your track record for Cygwin diagnosis isn't 100%. I am going to need complete research before changing anything at this point in beta.
Ok, I'll do an analysis and patch which will have a chance to be accepted.
Keeping pgrename in CYGWIN is probably a good idea.
At least for consistent error reporting (which helped me in finding the problem)
Personally I don't think that any rename()-usleep loop is necessary.
I'll check the archives.
I agree the rename loop seems unnecessary. I kept it in case we hadn't dealt with all the failure places. Should we remove them now or wait for 8.1? Seems we should keep them in and see if we get reports from users of looping forever, and if not we can remove them in 8.1.
we at CYGWIN had similar problems with windows locks on unlink.
if unlink fails with ERROR_SHARING_VIOLATION or ERROR_ACCESS_DENIED, unlinking is deferred, put into a delqueue. we do no busy waiting then.
it's done on exit.
The most common problem is the "delete on close" semantics to handle removing a file which may be open.
rename only fails on open files. we try first MoveFile, if that fails we try MoveFileEx MOVEFILE_REPLACE_EXISTING, but no loop on rename.
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/syscalls.cc?cvsroot=src http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/delqueue.cc?cvsroot=src
-- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
