Re: pg_tablespace_location() failure with allow_in_place_tablespaces

At Tue, 8 Mar 2022 10:39:06 +1300, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote in
> On Tue, Mar 8, 2022 at 12:58 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> > On Fri, Mar 04, 2022 at 11:26:43PM +1300, Thomas Munro wrote:
> > > + /* Skip in-place tablespaces (testing use only) */
> > > + if (get_dirent_type(fullpath, de, false, ERROR) == PGFILETYPE_DIR)
> > > + continue;
> >
> > I saw the warning when testing base backups with in-place tablespaces
> > and it did not annoy me much, but, yes, that can be confusing.
> >
> > 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.
>
> Thanks, you're right. Test on a Win10 VM. Here's a new version.

Thanks! It works for me on CentOS8 and Windows11.

FYI, on Windows11, pg_basebackup didn't work correctly without the
patch. So this looks like fixing an undiscovered bug as well.

===
> pg_basebackup -D copy
WARNING: could not read symbolic link "pg_tblspc/16384": Invalid argument
pg_basebackup: error: tar member has empty name

> dir copy
Volume in drive C has no label.
Volume serial number: 10C6-4BA6

Directory of c:\..\copy

2022/03/08 09:53 <DIR> .
2022/03/08 09:53 <DIR> ..
2022/03/08 09:53 0 nbase.tar
2022/03/08 09:53 <DIR> pg_wal
1 File(s) 0 bytes
3 Dir(s) 171,920,613,376 bytes free

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center