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