Re: Fwd: Add tablespace tap test to pg_rewind
От | Michael Paquier |
---|---|
Тема | Re: Fwd: Add tablespace tap test to pg_rewind |
Дата | |
Msg-id | 20190510115301.GD1498@paquier.xyz обсуждение исходный текст |
Ответ на | Re: Fwd: Add tablespace tap test to pg_rewind (Michael Paquier <michael@paquier.xyz>) |
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: