Re: pg_basebackup vs. Windows and tablespaces - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: pg_basebackup vs. Windows and tablespaces
Date
Msg-id CAA4eK1JiN8tMJm6ckcox95axab4TVMKfurshnU7KpW=t7wbCrw@mail.gmail.com
Whole thread Raw
In response to Re: pg_basebackup vs. Windows and tablespaces  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On Tue, Nov 18, 2014 at 7:49 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
>
> Amit Kapila wrote:
> > On Sun, Nov 16, 2014 at 6:15 AM, Alvaro Herrera <alvherre@2ndquadrant.com>
> > wrote:
>
>
> > > > > One use case mentioned upthread is having the clone be created in the
> > > > > same machine as the source server.  Does your proposal help with it?
>
> > That use case got addressed with -T option with which user can relocate
> > tablespace directory (Commit: fb05f3c;  pg_basebackup: Add support for
> > relocating tablespaces)
>
> Okay.  As far as I know, -T only works for plain mode, right?

Yes.

> I wonder
> if we should make -T modify the tablespace catalog, so that the
> resulting file in tar output outputs names mangled per the map; that
> would make -T work in tar mode too.  Does that make sense?

tablepspace catalog (I assume it is new file you are talking about) is
formed on the server where as handling for -T is completely in
pg_basebackup, we might be able to make it work, but I am not
sure if it is worth because the main usecase for -T option is for plain
format.  I think even if there is some use case for -T to work with tar
format, it is a separate project.


With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Petr Jelinek
Date:
Subject: Re: tracking commit timestamps
Next
From: Fujii Masao
Date:
Subject: Re: PostgreSQL doesn't stop propley when --slot option is specified with pg_receivexlog.