|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 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?
> /* Name 100 */
> sprintf(&h, "%.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.
|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|