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-08-01 00:57:37
Message-ID: ZMhYgcNzMMD1FLHz@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jonathan S. Katz 2023-08-01 01:18:37 PostgreSQL 16 Beta 3 release date
Previous Message Zhang Mingli 2023-08-01 00:46:15 Re: [feature]COPY FROM enable FORCE_NULL/FORCE_NOT_NULL on all columns