Thread: Re: [pgsql-hackers-win32] win32 open patch for held unlink

> Claudio, how does this handle renames if the file is open by someone
> else?  Does this remove the need to loop over the rename?

To be honest, I don't know that it does. [Will report back later.]

Two points though:

a) This could doesn't alleviate the needs for dirmod.c, as far as I'm aware.
That seems to be there for a different reason, namely that there appears to
be some timing issue between creating a file and issuing an unlink/rename.

b) Do we have a case where rename's can block because of the file being held
open by another process? I haven't tripped over this yet...

Cheers,
Claudio



---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>

Claudio Natoli wrote:
>
>
> > Claudio, how does this handle renames if the file is open by someone
> > else?  Does this remove the need to loop over the rename?
>
> To be honest, I don't know that it does. [Will report back later.]
>
> Two points though:
>
> a) This could doesn't alleviate the needs for dirmod.c, as far as I'm aware.
> That seems to be there for a different reason, namely that there appears to
> be some timing issue between creating a file and issuing an unlink/rename.
>
> b) Do we have a case where rename's can block because of the file being held
> open by another process? I haven't tripped over this yet...

Agreed, we still need dirmod.c in case someone has opened it using a
non-unix mode.  My only question was whether this new mode makes rename
possible on a target file opened by another backend.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073