Re: Fwd: Add tablespace tap test to pg_rewind

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

In response to

Browse pgsql-hackers by date

  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