Amit Kapila wrote:
> On Sat, Nov 15, 2014 at 12:03 AM, Alvaro Herrera <alvherre@2ndquadrant.com>
> wrote:
> >
> > Amit Kapila wrote:
> > 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 think the fact that we use symlinks is an implementation detail;
aren't them actually junction points, not symlinks, in some Windows
cases? The The pg_tablespace catalog uses (or used to use)
"spclocation" for this, not "spcsymlink".
> > 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 the first message of this thread[1], Noah said:
: A "pg_basebackup -Fp" running on the same system as the target cluster will
: fail in the presence of tablespaces; it would backup each tablespace to its
: original path, and those paths are in use locally for the very originals we're
: copying.
> 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.
I must be misunderstanding either you or Noah.
[1] http://www.postgresql.org/message-id/20130801161519.GA334956@tornado.leadboat.com
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
