From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: fix tablespace handling in pg_combinebackup |
Date: | 2024-04-19 18:44:50 |
Message-ID: | 2183955.1713552290@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Apr 18, 2024 at 1:45 PM Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2024-04-19 19:04:27 | Re: Support a wildcard in backtrace_functions |
Previous Message | Robert Haas | 2024-04-19 18:42:13 | Re: allow changing autovacuum_max_workers without restarting |