Noah Misch <n...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
