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

From Peter Eisentraut
Subject Re: pg_basebackup fails with long tablespace paths
Date
Msg-id 544575DF.6060004@gmx.net
Whole thread Raw
In response to pg_basebackup fails with long tablespace paths  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_basebackup fails with long tablespace paths
List pgsql-hackers
On 10/20/14 2:59 PM, Tom Lane wrote:
> What do we want to do about this?  I think a minimum expectation would be
> for pg_basebackup to notice and complain when it's trying to create an
> unworkably long symlink entry, but it would be far better if we found a
> way to cope instead.

Isn't it the backend that should error out before sending truncated
files names?

src/port/tar.c:
   /* Name 100 */   sprintf(&h[0], "%.99s", filename);

And then do we need to prevent the creation of tablespaces that can't be
backed up?

> One thing we could possibly do without reinventing "tar" is to avoid >
using
> absolute path names if a PGDATA-relative one would do.

Maybe we could hack up the tar format to store the symlink target as the
file body, like cpio does.  Of course then we'd lose the property of
this actually being tar.




pgsql-hackers by date:

Previous
From: David G Johnston
Date:
Subject: Re: Add regression tests for autocommit-off mode for psql and fix some omissions
Next
From: Marko Tiikkaja
Date:
Subject: Re: pgcrypto: PGP signatures