Re: pg_tablespace_location() failure with allow_in_place_tablespaces

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: pg_tablespace_location() failure with allow_in_place_tablespaces
Дата
Msg-id YjGG7KypP4ZY1pnG@paquier.xyz
обсуждение исходный текст
Ответ на Re: pg_tablespace_location() failure with allow_in_place_tablespaces  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Ответы Re: pg_tablespace_location() failure with allow_in_place_tablespaces  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: "osumi.takamichi@fujitsu.com"
Дата:
Сообщение: RE: Skipping logical replication transactions on subscriber side
Следующее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: [PATCH] Accept IP addresses in server certificate SANs