On 06/08/2015 11:19 PM, Amit Kapila wrote:
> On Tue, Jun 9, 2015 at 12:27 AM, Andrew Dunstan <andrew@dunslane.net
> <mailto:andrew@dunslane.net>> wrote:
>
>
> On 06/08/2015 11:16 AM, Amit Kapila wrote:
>
>
> I have to retry that operation, but for me unlink hasn't deleted
> the file on Windows, may be I am not doing properly, but in
> anycase why we want to throw error for such a case, why
> can't we just ignore and create a symlink with the same name.
>
>
> 1. You realize that in Windows postgres, unlink is actually
> pgunlink(), right? See port.h. If your experiments weren't using
> that then they weren't testing the same thing.
>
>
> Yes, I know that and was using the same version, but the
> small problem in my test was that the file name that is used
> for unlink was not same as that of actual file in directory, sorry
> for the noise.
>
> 2. If the unlink fails and the file is still there (i.e. pretty
> much everything except the ENOENT case) then creation of the
> symlink is bound to fail anyway.
>
> I realize our existing code just more or less assumes that that
> it's a symlink. I think we've probably been a bit careless
> there.
>
>
> I agree with you that deleting unrelated file with the same
> name as
> symlink is not the right thing to do, but not sure throwing
> error for
> such a case is better either.
>
>
>
>
> What else would you suggest?
>
>
> I think Robert and Alvaro also seems to be inclined towards throwing
> error for such a case, so let us do that way, but one small point is that
> don't you think that similar code in destroy_tablespace_directories()
> under
> label "remove_symlink:" should use similar logic?
Yes, probably.
cheers
andrew
