> I don't think that your solution is the correct move. Having
> pg_tablespace_location() return the physical location of the
> tablespace is very useful because that's the location where the
> physical files are, and client applications don't need to know the
> logic behind the way a path is built.
I understand your concern. I suggest defining the standard behavior of the in-place tablespace to match that of the pg_default and pg_global tablespaces. The location of the pg_default and pg_global tablespaces is not a concern because they have default paths. Similarly, the location of the in-place tablespace is not a concern because they are all pg_tblspc/<oid>.
Another reason is that, up until now, we have been creating in-place tablespaces using the following command:
CREATE TABLESPACE space_test LOCATION ''
However, when using pg_dump to back up this in-place tablespace, it is dumped with a different path:
CREATE TABLESPACE space_test LOCATION 'pg_tblspc/<oid>'
This can be confusing because it does not match the initial path that we created. Additionally, pg_restore cannot restore this in-place tablespace because the CREATE TABLESPACE command only supports an empty path for creating in-place tablespaces.
> That may not work on Windows where the driver letter is appended at
> the beginning of the path, no? There is is_absolute_path() to do this
> job in a more portable way.
You are correct. I have made the necessary modifications to ensure compatibility with in-place tablespaces. Please find the updated code attached.
--
Best regards,
Rui Zhao
------------------------------------------------------------------
From:Michael Paquier <michael(at)paquier(dot)xyz>
Sent At:2023 Aug. 1 (Tue.) 08:57
To:Mark <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
On Sat, Jul 29, 2023 at 11:10:22PM +0800, Rui Zhao wrote:
> 2) Only check the tablespace with an absolute path in pg_upgrade.
> There are also other solutions, such as supporting the creation of
> relative-path tablespace in function CreateTableSpace. But do we
> really need relative-path tablespace? I think in-place tablespace
> is enough by now. My solution may be more lightweight and
> harmless.
+ /* The path of the in-place tablespace is always pg_tblspc/<oid>. */
if (!S_ISLNK(st.st_mode))
- PG_RETURN_TEXT_P(cstring_to_text(sourcepath));
+ PG_RETURN_TEXT_P(cstring_to_text(""));
I don't think that your solution is the correct move. Having
pg_tablespace_location() return the physical location of the
tablespace is very useful because that's the location where the
physical files are, and client applications don't need to know the
logic behind the way a path is built.
- " spcname != 'pg_global'");
+ " spcname != 'pg_global' AND "
+ " pg_catalog.pg_tablespace_location(oid) ~ '^/'");
That may not work on Windows where the driver letter is appended at
the beginning of the path, no? There is is_absolute_path() to do this
job in a more portable way.
--
Michael