Re: pg_tablespace_location() failure with allow_in_place_tablespaces - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: pg_tablespace_location() failure with allow_in_place_tablespaces
Date
Msg-id YjGG7KypP4ZY1pnG@paquier.xyz
Whole thread Raw
In response to Re: pg_tablespace_location() failure with allow_in_place_tablespaces  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses Re: pg_tablespace_location() failure with allow_in_place_tablespaces  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-hackers
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

Attachment

pgsql-hackers by date:

Previous
From: "osumi.takamichi@fujitsu.com"
Date:
Subject: RE: Skipping logical replication transactions on subscriber side
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: [PATCH] Accept IP addresses in server certificate SANs