Re: pg_basebackup fails with long tablespace paths

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: pg_basebackup fails with long tablespace paths
Дата
Msg-id 544575DF.6060004@gmx.net
обсуждение исходный текст
Ответ на pg_basebackup fails with long tablespace paths  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: pg_basebackup fails with long tablespace paths
Список 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?

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.




В списке pgsql-hackers по дате отправления:

Предыдущее
От: David G Johnston
Дата:
Сообщение: Re: Add regression tests for autocommit-off mode for psql and fix some omissions
Следующее
От: Marko Tiikkaja
Дата:
Сообщение: Re: pgcrypto: PGP signatures