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 CAA4eK1+QZ02J3Rca_AsYJqBAUfL5COEcg6EyxR4-hTdK3tuU7A@mail.gmail.com
Whole thread Raw
In response to Re: pg_basebackup vs. Windows and tablespaces  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: pg_basebackup vs. Windows and tablespaces  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On Sat, Nov 15, 2014 at 12:03 AM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
>
> Amit Kapila wrote:
>
> > 2. Symlink file format:
> > <oid> <linkpath>
> > 16387 E:\PostgreSQL\tbs
> >
> > Symlink file will contain entries for all the tablspaces
> > under pg_tblspc directory.  I have kept the file name as
> > symlink_label (suggestion are welcome if you want some
> > different name for this file).
>
> I think symlink_label isn't a very good name.  This file is not a label
> in the sense that backup_label is; it seems more a "catalog" to me.  And
> it's not, in essence, about symlinks either, but rather about
> tablespaces.  I would name it following the term "tablespace catalog" or
> some variation thereof.
>

This file is going to provide the symlink path for each tablespace, so
it not be bad to have that in file name.  I agree with you that it's more
about tablespaces.  So how about:

tablespace_symlink 
symlink_tablespace
tablespace_info

> I know we don't expect that users would have to look at the file or edit
> it in normal cases, but it seems better to make it be human-readable.  I
> would think that the file needs to have tablespace names too, then, not
> just OIDs.  Maybe we don't use the tablespace name for anything other
> than "documentation" purposes if someone decides to look at the file, so
> perhaps it should look like a comment:
>
> <oid>   <link path>     ; <tablespace name>
>
> We already do this in pg_restore -l output IIRC.
>

Okay, I will take care of doing this in next version of patch if no one
objects to this idea or more people are in favour of doing so.

> 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?
>

Sorry, but I am not getting which proposal exactly you are referring here,
Could you explain in more detail?

In general, if user took the backup (in tar format) using pg_basebackup, this
patch will be able to restore such a backup even on the same server. 

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

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: WAL format and API changes (9.5)
Next
From: Amit Kapila
Date:
Subject: Re: pg_basebackup vs. Windows and tablespaces