Re: pg_basebackup fails with long tablespace paths

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: pg_basebackup fails with long tablespace paths
Date: 2014-10-20 20:51:43
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: 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?


/* 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 >
> 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.

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Marko Tiikkaja 2014-10-20 22:32:06 Re: pgcrypto: PGP signatures
Previous Message David G Johnston 2014-10-20 20:49:19 Re: Add regression tests for autocommit-off mode for psql and fix some omissions