Re: pg_tablespace_location() failure with allow_in_place_tablespaces

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_tablespace_location() failure with allow_in_place_tablespaces
Date: 2022-03-24 03:41:30
Message-ID: CA+hUKGLzLK4PUPx0_AwXEWXOYAejU=7XpxnYE55Y+e7hB2N3FA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 8, 2022 at 12:58 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> Junction points are directories, no? Are you sure that this works
> correctly on WIN32? It seems to me that we'd better use readlink()
> only for entries in pg_tlbspc/ that are PGFILETYPE_LNK on non-WIN32
> and pgwin32_is_junction() on WIN32.

Hmm. So the code we finished up with in the tree looks like this:

#ifdef WIN32
if (!pgwin32_is_junction(fullpath))
continue;
#else
if (get_dirent_type(fullpath, de, false, ERROR) != PGFILETYPE_LNK)
continue;
#endif

As mentioned, I was unhappy with the lack of error checking for that
interface, and I've started a new thread about that, but then I
started wondering if we missed a trick here: get_dirent_type() contain
code that wants to return PGFILETYPE_LNK for reparse points. Clearly
it's not working, based on results reported in this thread. Is that
explained by your comment above, "junction points _are_ directories",
and we're testing the attribute flags in the wrong order here?

if ((fd.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) != 0)
d->ret.d_type = DT_DIR;
/* For reparse points dwReserved0 field will contain the ReparseTag */
else if ((fd.dwFileAttributes & FILE_ATTRIBUTE_REPARSE_POINT) != 0 &&
(fd.dwReserved0 == IO_REPARSE_TAG_MOUNT_POINT))
d->ret.d_type = DT_LNK;
else
d->ret.d_type = DT_REG;

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2022-03-24 04:34:58 Re: postgres_fdw: commit remote (sub)transactions in parallel during pre-commit
Previous Message shiy.fnst@fujitsu.com 2022-03-24 03:33:23 RE: logical replication empty transactions