Re: pg_tablespace_location() failure with allow_in_place_tablespaces

At Fri, 4 Mar 2022 15:44:22 +0900, Michael Paquier <michael(at)paquier(dot)xyz> wrote in
> 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.

ERROR: could not read symbolic link "pg_tblspc/16407": Invalid argument

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

+1

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

The function I think is expected to return a absolute path but it
returns a relative path for in-place tablespaces. While it is
apparently incovenient for general use, there might be a case where we
want to know whether the tablespace is in-place or not. So I'm not
sure which is better..

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center