Re: fix tablespace handling in pg_combinebackup - Mailing list pgsql-hackers

From Tom Lane
Subject Re: fix tablespace handling in pg_combinebackup
Date
Msg-id 2183955.1713552290@sss.pgh.pa.us
Whole thread Raw
In response to Re: fix tablespace handling in pg_combinebackup  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: fix tablespace handling in pg_combinebackup
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: allow changing autovacuum_max_workers without restarting
Next
From: Robert Haas
Date:
Subject: Re: Support a wildcard in backtrace_functions