|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
/* Name 100 */
sprintf(&h, "%.99s", filename);
And then do we need to prevent the creation of tablespaces that can't be
> 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.
|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|