At Fri, 4 Mar 2022 15:44:22 +0900, Michael Paquier <mich...@paquier.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