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
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 |