Re: pg_basebackup fails with long tablespace paths

08.11.2014, 04:03, Peter Eisentraut kirjoitti:
> On 11/4/14 3:52 PM, Peter Eisentraut wrote:
>> > Here are patches to address that. First, it reports errors when
>> > attempting to create a tar header that would truncate file or symlink
>> > names. Second, it works around the problem in the tests by creating a
>> > symlink from the short-name tempdir that we had set up for the
>> > Unix-socket directory case.
> I ended up splitting this up differently. I applied to part of the
> second patch that works around the length issue in tablespaces. So the
> tests now pass in 9.4 and up even in working directories with long
> names. This clears up the regression in 9.4.
>
> The remaining, not applied patch is attached. It errors when the file
> name is too long and adds tests for that. This could be applied to 9.5
> and backpatched, if we so choose. It might become obsolete if
> https://commitfest.postgresql.org/action/patch_view?id=1512 is accepted.
> If that patch doesn't get accepted, I might add my patch to a future
> commit fest.

I think we should just use the UStar tar format
(http://en.wikipedia.org/wiki/Tar_%28computing%29#UStar_format) and
allow long file names; all actively used tar implementations should be
able to handle them. I'll try to write a patch for that soonish.

Until UStar format is used we should raise an error if a filename is
being truncated by tar instead of creating invalid archives. Also note
that Posix tar format allows 100 byte file names as the name doesn't
have to be zero terminated, but we may want to stick to 99 bytes in old
type tar anyway as using 100 byte filenames has shown bugs in other tar
implementations, for example
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689582 - and
truncating at 100 bytes instead of 99 doesn't help us too much anyway.

/ Oskari