Noah Misch <noah@leadboat.com> writes:
> 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
I'd like to see that fixed, +1.
> 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.
My understanding is that the second option here would be useful also
when you want to create a standby with a different file layout than the
master, which in some cases is what you want to do (not HA strictly).
Another defect of pg_basebackup is its lack of shandling of tablespaces
mounted within $PGDATA, which happens often enough at customers sites,
whatever we think about that option. Would your work be extended to
cover that too?
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
