Re: pg_upgrade fails with in-place tablespace[

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Rui Zhao <xiyuan(dot)zr(at)alibaba-inc(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_upgrade fails with in-place tablespace[
Date: 2023-09-01 04:58:31
Message-ID: ZPFvd3TvMSFZjIjL@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Aug 19, 2023 at 08:11:28PM +0800, Rui Zhao wrote:
> Please refer to the TAP test I have included for a better understanding
> of my suggestion.

Sure, but it seems to me that my original question is not really
answered: what's your use case for being able to support in-place
tablespaces in pg_upgrade? The original use case being such
tablespaces is to ease the introduction of tests with primaries and
standbys, which is not something that really applies to pg_upgrade,
no? Perhaps there is meaning in having more TAP tests with
tablespaces and a combination of primary/standbys, still having
in-place tablespaces does not really make much sense to me because, as
these are in the data folder, we don't use them to test the path
re-creation logic.

I think that we should just add a routine in check.c that scans
pg_tablespace, reporting all the non-absolute paths found with their
associated tablespace names.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2023-09-01 05:20:11 Re: persist logical slots to disk during shutdown checkpoint
Previous Message Amit Langote 2023-09-01 04:52:15 Re: remaining sql/json patches