Re: standby recovery fails (tablespace related) (tentative patch and discussion)

On 2022-Jul-15, Kyotaro Horiguchi wrote:

> 0002:
> +is_path_tslink(const char *path)
> 
> What the "ts" of tslink stands for? If it stands for tablespace, the
> function is not specific for table spaces. We already have 
> 
> +                    errmsg("could not stat file \"%s\": %m", path));
> 
> I'm not sure we need such correctness, but what is failing there is
> lstat.  I found similar codes in two places in backend and one place
> in frontend. So couldn't it be moved to /common and have a more
> generic name?

I wondered whether it'd be better to check whether get_dirent_type
returns PGFILETYPE_LNK.  However, that doesn't deal with junction points
at all, which seems pretty odd ... I mean, isn't it rather useful as an
abstraction if it doesn't abstract away the one platform-dependent point
we have in the area?

However, looking closer I noticed that on Windows we use our own
readdir() implementation, which AFAICT includes everything to handle
reparse points as symlinks correctly in get_dirent_type.  Which means
that do_pg_start_backup is wasting its time with the "#ifdef WIN32" bits
to handle junction points separately.  We could just do this

diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index b809a2152c..4966213fde 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -8302,13 +8302,8 @@ do_pg_backup_start(const char *backupidstr, bool fast, TimeLineID *starttli_p,
              * we sometimes use allow_in_place_tablespaces to create
              * directories directly under pg_tblspc, which would fail below.
              */
-#ifdef WIN32
-            if (!pgwin32_is_junction(fullpath))
-                continue;
-#else
             if (get_dirent_type(fullpath, de, false, ERROR) != PGFILETYPE_LNK)
                 continue;
-#endif
 
 #if defined(HAVE_READLINK) || defined(WIN32)
             rllen = readlink(fullpath, linkpath, sizeof(linkpath));


And everything should continue to work.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/