Re: pg_basebackup fails with long tablespace paths

On Tue, Jan 13, 2015 at 4:41 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> 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.

I see. I'm a little concerned that following symlinks may be cheaper
than whatever system we would come up with for caching the
tablespace-name-to-file-name mappings. But that concern might be
unfounded, and apart from it I have no reason to oppose your proposal,
if you want to do the work.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company