Re: fix tablespace handling in pg_combinebackup

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

In response to

Responses

Browse pgsql-hackers by date

  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