Re: APR 1.0 released - Mailing list pgsql-hackers

From Reini Urban
Subject Re: APR 1.0 released
Date
Msg-id 413EE1E0.4080801@x-ray.at
Whole thread Raw
In response to Re: APR 1.0 released  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: APR 1.0 released  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
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.

> ---------------------------------------------------------------------------
> Reini Urban wrote:
>>Bruce Momjian schrieb:
>>
>>>I looked at the APR code to get some ideas for the Win32 port.  Some of
>>>the ideas were good, but in other places like rename they didn't do very
>>>well we were better off doing it ourselves and getting it right.
>>>
>>>I remember looking at their code to fix the rename/unlink while the file
>>>is open problem, and they didn't seem to have a fix for that so we
>>>developed our own method that works like Unix.
>>
>>sorry, but your rename doesn't work on cygwin. maybe it works with mingw.
>>
>>cygwin has it's own and working way of doing rename's.
>>maybe you should have looked at the cygwin sources instead.
>>(src/winsup/cygwin/syscalls.cc)
>>
>>first doing a WinAPI MoveFileEx and then after a failure trying the 
>>cygwin version, which will also try its own MoveFile loop, will not 
>>work. they are conflicting.
>>
>>same with unlink, but at least the mingw and cygwin unlink versions 
>>don't conflict here. here you don't stack two conflicting loops together.
>>nevertheless cygwin's unlink is much better than pgunlink in case of 
>>locking problems. it does its own sort of delayed removal then.
>>
>>IMHO port/dirmod.c is a dirty and half-baked hack, which works for mingw 
>>only.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/


pgsql-hackers by date:

Previous
From: David Garamond
Date:
Subject: Re: FYI: Fujitsu
Next
From: Tom Lane
Date:
Subject: Re: Making AFTER triggers act properly in PL functions