Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hJIeK-0000HP-4f for pgsql-hackers@arkaria.postgresql.org; Wed, 24 Apr 2019 14:13:24 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hJIeI-00023Z-Pn for pgsql-hackers@arkaria.postgresql.org; Wed, 24 Apr 2019 14:13:22 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hJIeI-0001yP-Dm for pgsql-hackers@lists.postgresql.org; Wed, 24 Apr 2019 14:13:22 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hJIeG-0005YU-1e for pgsql-hackers@lists.postgresql.org; Wed, 24 Apr 2019 14:13:21 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id x3OED9Q4010968; Wed, 24 Apr 2019 10:13:09 -0400 From: Tom Lane To: Kyotaro HORIGUCHI cc: andres@anarazel.de, michael@paquier.xyz, kuntalghosh.2007@gmail.com, pgsql-hackers@lists.postgresql.org Subject: Re: Regression test PANICs with master-standby setup on same machine In-reply-to: <20190424.170228.203880527.horiguchi.kyotaro@lab.ntt.co.jp> References: <20190423170503.uw5jxrujqlozg23l@alap3.anarazel.de> <20190424.131845.116224815.horiguchi.kyotaro@lab.ntt.co.jp> <20190424.132304.40676137.horiguchi.kyotaro@lab.ntt.co.jp> <20190424.170228.203880527.horiguchi.kyotaro@lab.ntt.co.jp> Comments: In-reply-to Kyotaro HORIGUCHI message dated "Wed, 24 Apr 2019 17:02:28 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10966.1556115189.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Apr 2019 10:13:09 -0400 Message-ID: <10967.1556115189@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Kyotaro HORIGUCHI writes: > At Wed, 24 Apr 2019 13:23:04 +0900 (Tokyo Standard Time), Kyotaro HORIGU= CHI wrote in <20190424.132304.40676137.h= origuchi.kyotaro@lab.ntt.co.jp> >> We need to adjust relative path between PGDATA-based and >> pg_tblspc based. The attached first patch does that. > This is new version. Adjusted pg_basebackup's behavior to allow > relative mappings. But.. I can't say that I like 0001 at all. It adds a bunch of complication and new failure modes (e.g., having to panic on chdir failure) in order to do what exactly? I've not been following the thread closely, but the original problem is surely just a dont-do-that misconfiguration. I also suspect that this is assuming way too much about the semantics of getcwd --- some filesystem configurations may have funny situations like multiple paths to the same place. 0004 also seems like it's adding at least as many failure modes as it removes. Moreover, isn't it just postponing the failure a little? Later WAL might well try to touch the directory you skipped creation of. We can't realistically decide that all WAL-application errors are ignorable, but that seems like the direction this would have us go in. regards, tom lane