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 1nWNJ2-0007kY-Ne for pgsql-hackers@arkaria.postgresql.org; Mon, 21 Mar 2022 19:03:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nWNJ1-0000B6-Cb for pgsql-hackers@arkaria.postgresql.org; Mon, 21 Mar 2022 19:03:03 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nWNJ1-0000Ax-4B for pgsql-hackers@lists.postgresql.org; Mon, 21 Mar 2022 19:03:03 +0000 Received: from new2-smtp.messagingengine.com ([66.111.4.224]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nWNIy-0001pz-93 for pgsql-hackers@postgresql.org; Mon, 21 Mar 2022 19:03:02 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.nyi.internal (Postfix) with ESMTP id 953625801C2; Mon, 21 Mar 2022 15:02:58 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Mon, 21 Mar 2022 15:02:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date: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; bh=i8K4LKFywRJvwUo/0okDLwVG08UT46b/1TzjQU1dQd0=; b=gbhXB6aC LBwvLxFvtl90/8YamHX71DIwt5j2+7avzGNofpj6HiSQcJyGcDm+HuLG16thaedD DR/2lZk/FvIF9n/KV+ygd9m81U87z5ounElquZuWC0dq4Q5vFZ37OkoOR5nBCWJ6 5qewpA/vnnoKy7yNOHejrVYsug6oP6l/ZagrVHdSvUfks+0G1bvaC1luYAzjNyoE OExVc0Zq8NuY1vpYG2iVwJqyBH1CIswqdekkscO2UP5ma+AJWSNUQ6SoWzUhOvy2 gDKqzqBzdvXO7AuLsMNnk+EoeBEin9YGCREqAn+t9CEaa3AciojwpcqTMwShCJBE 3+0rQArwnawPDA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudegfedguddvudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enogfvvgigthfqnhhlhidqqdfuphgrmhgsohhtqdgkgedvvddqjeduqdgsihhsucdlfedt tddmnecujfgurhepfffhvffukfggtggugfgjsehtkeertddttdejnecuhfhrohhmpeetlh hvrghrohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdho rhhgqeenucggtffrrghtthgvrhhnpedujeevjeffjeevuddutedvkeeiueeitddvieelfe ekveejudefgeeuvdejhfeuleenucffohhmrghinhepvghnthgvrhhprhhishgvuggsrdgt ohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprg hlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 21 Mar 2022 15:02:57 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 4B8FB2A0648; Mon, 21 Mar 2022 16:03:07 -0300 (-03) Date: Mon, 21 Mar 2022 20:03:07 +0100 From: Alvaro Herrera To: Robert Haas Cc: Kyotaro Horiguchi , Michael Paquier , Julien Rouhaud , "pgsql-hackers@postgresql.org" Subject: Re: standby recovery fails (tablespace related) (tentative patch and discussion) Message-ID: <202203211903.ni5vfpmyelk7@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2022-Mar-14, Robert Haas wrote: > 2. Why not instead change the code so that the operation can succeed, > by creating the prerequisite parent directories? Do we not have enough > information for that? I'm not saying that we definitely should do it > that way rather than this way, but I think we do take that approach in > some cases. It seems we can choose freely between these two implementations -- I mean I don't see any upsides or downsides to either one. The current one has the advantage that it never makes the datadir "dirty", to use Kyotaro's term. It verifies that the creation/drop form a pair. A possible downside is that if there's a bug, we could end up with a spurious PANIC at the end of recovery, and no way to recover. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/