On Thu, May 09, 2019 at 02:36:48PM +0900, Michael Paquier wrote: > Yes, I can see that. The issue is that even if we do a backup with > --tablespace-mapping then we still need a tweak to allow the copy of > symlinks. I am not sure that this is completely what we are looking > for either, as it means that any test setting a primary with a > tablespace and two standbys initialized from the same base backup > would fail. That's not really portable.
So for now I am marking the patch as returned with feedback. I can see a simple way to put us through that by having an equivalent of --tablespace-mapping for the file-level backup routine which passes it down to RecursiveCopy.pm as well as PostgresNode::init_from_backup. At the end of the day, we would need to be able to point the path to different locations for: - the primary - any backup tables - any standbys which are restored from the previous backups. And on top of that there is of course the argument of pg_rewind which would need an option similar to pg_basebackup's --tablespace-mapping so as a target instance does not finish by using the same tablespace path as the source where there is a tablespace of difference during the operation. And it does not prevent an overlap if a tablespace needs to be created when the target instance replays WAL up to the consistent point of the source. So that's a lot of work which may be hard to justify. -- Michael
signature.asc
Description: PGP signature
