Thank you for your response. It is evident that there is a need
for this features in our system.
Firstly, our customers express their desire to utilize tablespaces
for table management, without necessarily being concerned about
the directory location of these tablespaces.
Secondly, currently PG only supports absolute-path tablespaces, but
in-place tablespaces are very likely to become popular in the future.
Therefore, it is essential to incorporate support for in-place
tablespaces in the pg_upgrade feature. I intend to implement
this functionality in our system to accommodate our customers'
requirements.
It would be highly appreciated if the official PG could also
incorporate support for this feature.
--
Best regards,
Rui Zhao
------------------------------------------------------------------
From:Michael Paquier <mich...@paquier.xyz>
Sent At:2023 Sep. 1 (Fri.) 12:58
To:Mark <xiyuan...@alibaba-inc.com>
Cc:pgsql-hackers <pgsql-hackers@lists.postgresql.org>
Subject:Re: pg_upgrade fails with in-place tablespace[
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
