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-11-04 20:52:12
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 10/20/14 4:51 PM, Peter Eisentraut wrote:
> 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);

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.

The first patch can be backpatched to 9.3. The tar code before that is
different and would need manual adjustments.

If someone has a too-long tablespace path, I think they can work around
that after this patch by creating a shorter symlink and updating the
pg_tblspc symlinks to point there.

Attachment Content-Type Size
0001-Error-when-creating-names-too-long-for-tar-format.patch application/x-patch 3.8 KB
0002-pg_basebackup-Adjust-tests-for-long-file-name-issues.patch application/x-patch 3.6 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Petr Jelinek 2014-11-04 21:01:52 Re: Sequence Access Method WIP
Previous Message Alvaro Herrera 2014-11-04 20:21:11 Re: WAL replay bugs