Re: pg_basebackup fails with long tablespace paths

On 1/7/15 3:19 PM, Robert Haas wrote:
> On Tue, Jan 6, 2015 at 4:33 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>> Currently, when you unpack a tarred basebackup with tablespaces, the
>> symlinks will tell you whether you have unpacked the tablespace tars at
>> the right place. Otherwise, how do you know? Secondly, you also have
>> the option of putting the tablespaces somewhere else by changing the
>> symlinks.
>
> That's a good argument for making the tablespace-map file
> human-readable and human-editable, but I don't think it's an argument
> for duplicating its contents inaccurately in the filesystem.
>
>> One way to address this would be to do away with the symlinks altogether
>> and have pg_tblspc/12345 be a text file that contains the tablespace
>> location. Kind of symlinks implemented in user space.
>
> Well, that's just spreading the tablespace-map file out into several
> files, and maybe keeping it around after we've restored from backup.

I think the key point I'm approaching is that the information should
only ever be in one place, all the time. This is not dissimilar from
why we took the tablespace location out of the system catalogs. Users
might have all kinds of workflows for how they back up, restore, and
move their tablespaces. This works pretty well right now, because the
authoritative configuration information is always in plain view. The
proposal is essentially that we add another location for this
information, because the existing location is incompatible with some
operating system tools. And, when considered by a user, that second
location might or might not collide with or overwrite the first location
at some mysterious times.

So I think the preferable fix is not to add a second location, but to
make the first location compatible with said operating system tools,
possibly in the way I propose above.