Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oCJ2F-0005PM-JZ for pgsql-hackers@arkaria.postgresql.org; Fri, 15 Jul 2022 10:59:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oCJ2C-0005GS-Iz for pgsql-hackers@arkaria.postgresql.org; Fri, 15 Jul 2022 10:59:00 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oCJ2B-0005G8-J5 for pgsql-hackers@lists.postgresql.org; Fri, 15 Jul 2022 10:59:00 +0000 Received: from out2-smtp.messagingengine.com ([66.111.4.26]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oCJ24-000365-CQ for pgsql-hackers@postgresql.org; Fri, 15 Jul 2022 10:58:58 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 4B6455C0132; Fri, 15 Jul 2022 06:58:50 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Fri, 15 Jul 2022 06:58:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:reply-to:sender :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; t=1657882730; x=1657969130; bh=m 0cOZfg/19lI57tIFrd+deop30/KJejW50GlClC+I6I=; b=PjMS5M15psbWEkuBJ T4RmIRidJXghaMiRf8P2VCLSkrloPF2zxWcXdKQeHFgjrhvPm12k8YZVrC7eJoBJ C0auzLP++PUZPvoPrn2JYzsHKvLLjwEPqrVqycWEqspD9/Ie0ald5nY+1ymNLLOl 5p/cieiBsqlYEWydSNrilX8OqLBe6eWO+hz1WVQ1Wd82zIdc/WuR6Cgg2zVEZsWl 3R8d38f6HVr+NTJZjyYgG/u8qqfzZYNWuywUPCnxKNyZkUmLULJTnmNKsUoaSeNU //GAZOlCVZxbKf8u9iTxn1cdFxoGhi5FhrmnUVO3ymE3uw0XrMRjHIeyJdHC28TM j4CMw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudekuddgfeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvvefukfggtggugfgjsehtke ertddttdejnecuhfhrohhmpeetlhhvrghrohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhr vgesrghlvhhhrdhnohdqihhprdhorhhgqeenucggtffrrghtthgvrhhnpedvkedtffduff dtffffheffhfejjefhgfeiueeukeejkeffgfdufffhudffffeuveenucffohhmrghinhep vghnthgvrhhprhhishgvuggsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrg hrrghmpehmrghilhhfrhhomheprghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhr gh X-ME-Proxy: Feedback-ID: ia2694551:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 15 Jul 2022 06:58:49 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id DD1B536E; Fri, 15 Jul 2022 12:58:44 +0200 (CEST) Date: Fri, 15 Jul 2022 12:58:44 +0200 From: Alvaro Herrera To: Kyotaro Horiguchi Cc: dilipbalaut@gmail.com, robertmhaas@gmail.com, michael@paquier.xyz, rjuju123@gmail.com, pgsql-hackers@postgresql.org Subject: Re: standby recovery fails (tablespace related) (tentative patch and discussion) Message-ID: <20220715105844.e5iuer7bav4chdnl@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20220715.163059.337322153376727951.horikyota.ntt@gmail.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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/