Horton

Re: pg_tablespace_location() failure with allow_in_place_tablespaces

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: thomas.munro@gmail.com, pgsql-hackers@lists.postgresql.org
Date: 2022-03-16T06:42:52Z
Lists: pgsql-hackers

Attachments

On Wed, Mar 16, 2022 at 10:34:15AM +0900, Kyotaro Horiguchi wrote:
> +1. Desn't the doc need to mention that?

Yes, I agree that it makes sense to add a note, even if
allow_in_place_tablespaces is a developer option.  I have added the
following paragraph in the docs:
+        A full path of the symbolic link in <filename>pg_tblspc/</filename>
+        is returned. A relative path to the data directory is returned
+        for tablespaces created with
+        <xref linkend="guc-allow-in-place-tablespaces"/> enabled.

Another thing that was annoying in the first version of the patch is
the useless call to lstat() on Windows, not needed because it is
possible to rely just on pgwin32_is_junction() to check if readlink()
should be called or not.

This leads me to the revised version attached.  What do you think?
--
Michael

Commits

  1. Remove unnecessary Windows-specific basebackup code.

  2. Fix get_dirent_type() for Windows junction points.

  3. doc: Remove mention to in-place tablespaces for pg_tablespace_location()

  4. Fix pg_tablespace_location() with in-place tablespaces

  5. Fix pg_basebackup with in-place tablespaces.