From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | pg_tablespace_location() failure with allow_in_place_tablespaces |
Date: | 2022-03-04 06:44:22 |
Message-ID: | YiG1RleON1WBcLnX@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi all,
While playing with tablespaces and recovery in a TAP test, I have
noticed that retrieving the location of a tablespace created with
allow_in_place_tablespaces enabled fails in pg_tablespace_location(),
because readlink() sees a directory in this case.
The use may be limited to any automated testing and
allow_in_place_tablespaces is a developer GUC, still it seems to me
that there is an argument to allow the case rather than tweak any
tests to hardcode a path with the tablespace OID. And any other code
paths are able to handle such tablespaces, be they in recovery or in
tablespace create/drop.
A junction point is a directory on WIN32 as far as I recall, but
pgreadlink() is here to ensure that we get the correct path on
a source found as pgwin32_is_junction(), so we can rely on that. This
stuff has led me to the attached.
Thoughts?
--
Michael
Attachment | Content-Type | Size |
---|---|---|
tbspace-inplace-location.patch | text/x-diff | 4.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2022-03-04 06:55:00 | Re: Optionally automatically disable logical replication subscriptions on error |
Previous Message | Kyotaro Horiguchi | 2022-03-04 06:30:57 | Re: standby recovery fails (tablespace related) (tentative patch and discussion) |