Re: pg_basebackup fails with long tablespace paths

On 12/27/14 8:02 PM, Robert Haas wrote:
> On Wed, Dec 24, 2014 at 8:12 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>> On 12/22/14 10:00 PM, Amit Kapila wrote:
>>> There is already a patch [1] in this CF which will handle both cases, so
>>> I am
>>> not sure if it is very good idea to go with a new tar format to handle this
>>> issue.
>>
>> I think it would still make sense to have proper symlinks in the
>> basebackup if possible, for clarity.
>
> I guess I would have assumed it would be more clear to omit the
> symlinks if we're expecting the server to put them in. Otherwise, the
> server has to remove the existing symlinks and create new ones, which
> introduces various possibilities for failure and confusion.

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. Under the new scheme, the existing symlinks would be
overwritten (or not?). If that is actually correct, then the proposed
fix doesn't really replicate the required functionality on Windows.

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.