Re: [GENERAL] pg_upgrade --link on Windows - Mailing list pgsql-general

From George Neuner
Subject Re: [GENERAL] pg_upgrade --link on Windows
Date
Msg-id 4efljcdj859mutoek8olohnjknuoaqo3m4@4ax.com
Whole thread Raw
In response to [GENERAL] pg_upgrade --link on Windows  ("Arnaud L." <arnaud.listes@codata.eu>)
List pgsql-general
On Fri, 9 Jun 2017 10:07:24 -0400, Bruce Momjian <bruce@momjian.us>
wrote:

>On Fri, Jun  9, 2017 at 12:00:56PM +0200, Arnaud L. wrote:
>> Hi
>>
>> The pg_upgrade documentation for PostgreSQL 9.6 states that --link will use
>> junction points on Windows.
>> Shouldn't it rather user hard-links ?
>> If I'm not mistaken, with junction points (i.e. soft-links to directories),
>> the old data dir cannot be removed.
>> With hard-links to file, we can get rid of the old data dir once we are sure
>> that the upgrade is fine.
>
>I was told junction points on Windows were hard links and no one has
>ever complained about not being able to remove them.


NTFS junctions are a distinct type of symbolic link which is meant for
filesystem mount points.  In NTFS "normal" symlinks are restricted to
targets within the same filesystem.

You can use a junction anywhere you want a symlink, but not the
reverse.  The downside is that pathname parsing is slower with
junctions than with symlinks because of the possibility that the path
may cross into a different filesystem.


The documentation is not very clear, IMO.

https://msdn.microsoft.com/en-us/library/windows/desktop/aa365006(v=vs.85).aspx
https://msdn.microsoft.com/en-us/library/windows/desktop/aa363878(v=vs.85).aspx
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365503(v=vs.85).aspx


The mklink utility can create any of these types of links.  Its
documentation does not describe the differences, but is shows that
hard links, symlinks, and junctions all are distinct concepts in
Windows.

https://technet.microsoft.com/en-us/library/cc753194(v=ws.11).aspx


George

pgsql-general by date:

Previous
From: armand pirvu
Date:
Subject: Re: [GENERAL] Vacuum and state_change
Next
From: Adrian Klaver
Date:
Subject: Re: [GENERAL] Vacuum and state_change