Re: fix tablespace handling in pg_combinebackup

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: fix tablespace handling in pg_combinebackup
Дата
Msg-id 2183955.1713552290@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: fix tablespace handling in pg_combinebackup  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: fix tablespace handling in pg_combinebackup  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Apr 18, 2024 at 1:45 PM Andres Freund <andres@anarazel.de> wrote:
>> Just to be clear: I don't want the above to block merging your test. If you
>> think you want to do it the way you did, please do.

> I think I will go ahead and do that soon, then.

This patch failed to survive contact with the buildfarm.  It looks
like the animals that are unhappy are choking like this:

pg_basebackup: error: backup failed: ERROR:  symbolic link target too long for tar format: file name "pg_tblspc/16415",
target"/home/bf/bf-build/olingo/HEAD/pgsql.build/testrun/pg_combinebackup/002_compare_backups/data/tmp_test_bV72/ts" 

So whether it works depends on how long the path to the animal's build
root is.

This is not good at all, because if the buildfarm is hitting this
limit then actual users are likely to hit it as well.  But doesn't
POSIX define some way to get longer symlink paths into tar format?
(If not POSIX, I bet there's a widely-accepted GNU extension.)

            regards, tom lane



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: allow changing autovacuum_max_workers without restarting
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Support a wildcard in backtrace_functions