Re: pg_basebackup fails with long tablespace paths

On Fri, Nov 7, 2014 at 9:03 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> 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 commit this, where by "this" I mean your patch to
error-check the length of filenames and symlinks instead of truncating
them. I don't know what will become of Amit's patch, but I think this
is a good idea anyway. We should perhaps even consider back-patching
it, because silently eating people's data is generally not cool. It's
possible that there are people out there who know that their filenames
and links are being truncated and don't care, and those people would
be unhappy to see this back-patched. However, it's also possible that
there are people who don't know that this is happening and do care,
and those people would be happy about a back-patch. I don't know
which group is larger. At the least, I think we should apply it to
master; because whatever we end up doing about Amit's patch, adding
error checks for conditions where we're chewing up somebody's
filenames and spitting out what's left over has got to be a good
thing.

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