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