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 2190700.1713555076@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 Fri, Apr 19, 2024 at 2:44 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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"

> Ah, crap. That sucks. As far as I've been able to find, we have no
> code in the tree that knows how to generate symlinks longer than 99
> characters (see tarCreateHeader). I can search around and see if I can
> find something else out there on the Internet.

wikipedia has some useful info:

https://en.wikipedia.org/wiki/Tar_(computing)#POSIX.1-2001/pax

However, post-feature-freeze is not the time to be messing with
implementing pax.  Should we revert handling of tablespaces in this
program for now?

> But I think in 010_pg_basebackup.pl we actually work harder to avoid
> the problem than I had realized:
> ...
> Maybe I need to clone that workaround here.

That would be a reasonable answer if we deem the problem to be
just "the buildfarm is unhappy".  What I'm wondering about is
whether the feature will be useful to end users with this
pathname length restriction.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Support a wildcard in backtrace_functions
Next
From: Colin Caine
Date:
Subject: Re: Okay to remove mention of mystery @ and ~ operators?