pg_basebackup vs. Windows and tablespaces

A "pg_basebackup -Fp" running on the same system as the target cluster will
fail in the presence of tablespaces; it would backup each tablespace to its
original path, and those paths are in use locally for the very originals we're
copying.  "pg_basebackup -Ft" does not exhibit that hazard, and I typically
recommend it for folks using tablespaces.

On Windows, we populate pg_tblspc with NTFS junction points.  "pg_basebackup
-Fp" reproduces them, and "pg_basebackup -Ft" stores them in the tar archive
as symbolic links.  Trouble arises for -Ft backups: no Windows tar expander
that I've found will recreate the junction points.  While -Fp backups are
basically usable, commands that copy files on Windows are inconsistent about
their support for junction points; duplicating a base backup after the fact is
error-prone.  Windows users of tablespaces are left with limited options: use
"pg_basebackup -Fp" on a different system, or use -Ft but manually recreate
the junction points.  We can do better; I see a few options:

1. Include in the base backup a file listing symbolic links/junction points,
then have archive recovery recreate them.  This file would be managed like the
backup label file; exclusive backups would actually write it to the master
data directory, and non-exclusive backups would incorporate it on the fly.
pg_basebackup could also omit the actual links from its backup.  Nearly any
tar or file copy utility would then suffice.

2. Add a pg_basebackup option like "--destdir" or "--sysroot", meaningful only
with -Fp; tablespace backups will be stored relative to it.  So if the actual
tablespace path is c:/foo, --destdir=c:/backups/today would backup that
tablespace to c:/backups/today/c/foo.  This facilitates same-server use of -Fp
on all platforms.

3. Use path concatenation instead of symbolic links/junction points for
tablespaces.  More invasive, no doubt.  For example, we would need to devise a
way for recovery to get the tablespace path.

I think #1 is a good bet; it's self-contained and fully heals the situation
for Windows users.  By itself, #2 helps less than #1 on Windows.  It may have
independent value.  Other ideas, opinions?

Thanks,
nm

-- 
Noah Misch
EnterpriseDB                                 http://www.enterprisedb.com