Re: pg_upgrade fails with in-place tablespace - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: pg_upgrade fails with in-place tablespace
Date
Msg-id ZMhYgcNzMMD1FLHz@paquier.xyz
Whole thread Raw
In response to pg_upgrade fails with in-place tablespace  ("Rui Zhao" <xiyuan.zr@alibaba-inc.com>)
Responses Re: pg_upgrade fails with in-place tablespace
List pgsql-hackers
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

Attachment

pgsql-hackers by date:

Previous
From: Zhang Mingli
Date:
Subject: Re: [feature]COPY FROM enable FORCE_NULL/FORCE_NOT_NULL on all columns
Next
From: "Jonathan S. Katz"
Date:
Subject: PostgreSQL 16 Beta 3 release date