Re: pg_basebackup fails with long tablespace paths

Поиск
Список
Период
Сортировка
От Oskari Saarenmaa
Тема Re: pg_basebackup fails with long tablespace paths
Дата
Msg-id 549928E8.5010602@ohmu.fi
обсуждение исходный текст
Ответ на Re: pg_basebackup fails with long tablespace paths  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
23.12.2014, 05:00, Amit Kapila kirjoitti:
> On Tue, Dec 23, 2014 at 4:10 AM, Oskari Saarenmaa wrote:
>> 08.11.2014, 04:03, Peter Eisentraut kirjoitti:
>> > It errors when the file
>> > name is too long and adds tests for that.  This could be applied to 9.5
>> > and backpatched, if we so choose.  It might become obsolete if
>> > https://commitfest.postgresql.org/action/patch_view?id=1512 is accepted.
>> >  If that patch doesn't get accepted, I might add my patch to a future
>> > commit fest.
>>
>> I think we should just use the UStar tar format
>> (http://en.wikipedia.org/wiki/Tar_%28computing%29#UStar_format) and
>> allow long file names; all actively used tar implementations should be
>> able to handle them.  I'll try to write a patch for that soonish.
>>
> 
> I think even using UStar format won't make it work for Windows where
> the standard utilities are not able to understand the symlinks in tar.
> There is already a patch [1] in this CF which will handle both cases, so
> I am
> not sure if it is very good idea to go with a new tar format to handle this
> issue.   
> 
> [1] : https://commitfest.postgresql.org/action/patch_view?id=1512 

That patch makes sense for 9.5, but I don't think it's going to be
backpatched to previous releases?  I think we should also apply Peter's
patch to master and backbranches to avoid creating invalid tar files
anywhere.  And optionally implement and backpatch long filename support
in tar even if 9.5 no longer creates tar files with long names.

/ Oskari




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

Предыдущее
От: Noah Misch
Дата:
Сообщение: Re: Initdb-cs_CZ.WIN-1250 buildfarm failures
Следующее
От: Oskari Saarenmaa
Дата:
Сообщение: Re: REINDEX CONCURRENTLY 2.0