From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Shaoqi Bai <sbai(at)pivotal(dot)io> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Fwd: Add tablespace tap test to pg_rewind |
Date: | 2019-05-10 11:53:01 |
Message-ID: | 20190510115301.GD1498@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Rouhaud | 2019-05-10 12:03:06 | Re: vacuumdb and new VACUUM options |
Previous Message | DHRUVI VADALIA | 2019-05-10 11:42:35 | Regarding GSoD |