Re: pg_basebackup fails with long tablespace paths - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: pg_basebackup fails with long tablespace paths
Date
Msg-id CAA4eK1+z_aBFncVwapzjoAVe3SFUektqTjU3uL6TF+GZqpwAhw@mail.gmail.com
Whole thread Raw
In response to Re: pg_basebackup fails with long tablespace paths  (Oskari Saarenmaa <os@ohmu.fi>)
Responses Re: pg_basebackup fails with long tablespace paths  (Oskari Saarenmaa <os@ohmu.fi>)
Re: pg_basebackup fails with long tablespace paths  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
On Tue, Dec 23, 2014 at 4:10 AM, Oskari Saarenmaa <os@ohmu.fi> wrote:
>
> 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.
>

I think even using UStar format won't make it work for Windows where
the standard utilities are not able to understand the symlinks in tar.
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.   

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: replicating DROP commands across servers
Next
From: Peter Eisentraut
Date:
Subject: Re: bin checks taking too long.