Re: fix tablespace handling in pg_combinebackup

On Fri, Apr 19, 2024 at 4:18 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Fri, Apr 19, 2024 at 3:31 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> 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.
>
> > Possibly you're getting a little too enthusiastic about these revert
> > requests, because I'd say it's at least a decade too late to get rid
> > of pg_basebackup.
>
> I misunderstood the context then. I thought you had just added
> support for tablespaces in this area. If pg_basebackup has been
> choking on overly-long tablespace symlinks this whole time, then
> the lack of field complaints suggests it's not such a common
> case after all.

No, the commit that caused all this was a 1-line code change. It was a
pretty stupid mistake which I would have avoided if I'd had proper
test case coverage for it, but I didn't do that originally. I think my
underlying reason for not doing the work was that I feared it would be
hard to test in a way that was stable. But, the existence of a bug
obviously proved that the test cases were needed. As expected,
however, that was hard to do without breaking things.

If you look at the error message you sent me, you can see that while
it's a pg_combinebackup test that is failing, the actual failing
program is pg_basebackup.

--
Robert Haas
EDB: http://www.enterprisedb.com