Re: pg_basebackup fails with long tablespace paths

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.