Re: fix tablespace handling in pg_combinebackup

From: Andres Freund <andres(at)anarazel(dot)de>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: fix tablespace handling in pg_combinebackup
Date: 2024-04-17 21:50:21
Message-ID: 20240417215021.enskzosiptctoibs@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2024-04-17 16:16:55 -0400, Robert Haas wrote:
> In the "Differential code coverage between 16 and HEAD" thread, Andres
> pointed out that there wasn't test case coverage for
> pg_combinebackup's code to handle files in tablespaces. I looked at
> adding that, and as nobody could possibly have predicted, found a bug.

Ha ;)

> @@ -787,8 +787,13 @@ Does not start the node after initializing it.
>
> By default, the backup is assumed to be plain format. To restore from
> a tar-format backup, pass the name of the tar program to use in the
> -keyword parameter tar_program. Note that tablespace tar files aren't
> -handled here.
> +keyword parameter tar_program.
> +
> +If there are tablespace present in the backup, include tablespace_map as
> +a keyword parameter whose values is a hash. When tar_program is used, the
> +hash keys are tablespace OIDs; otherwise, they are the tablespace pathnames
> +used in the backup. In either case, the values are the tablespace pathnames
> +that should be used for the target cluster.

Where would one get these oids?

Could some of this be simplified by using allow_in_place_tablespaces instead?
Looks like it'd simplify at least the extended test somewhat?

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2024-04-17 23:00:02 Re: pgsql: meson: Add initial version of meson based build system
Previous Message Andres Freund 2024-04-17 21:39:53 plenty code is confused about function level static