Amit Kapila wrote: > On Sat, Nov 15, 2014 at 12:03 AM, Alvaro Herrera <alvhe...@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.ga334...@tornado.leadboat.com -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
