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 1oC6gb-0007WY-O9 for pgsql-hackers@arkaria.postgresql.org; Thu, 14 Jul 2022 21:47:54 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oC6ga-0006ZQ-Jf for pgsql-hackers@arkaria.postgresql.org; Thu, 14 Jul 2022 21:47:52 +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 1oC6ga-0006ZG-7c for pgsql-hackers@lists.postgresql.org; Thu, 14 Jul 2022 21:47:52 +0000 Received: from wout5-smtp.messagingengine.com ([64.147.123.21]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oC6gW-0007kr-BD for pgsql-hackers@postgresql.org; Thu, 14 Jul 2022 21:47:51 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 3DACE320098E; Thu, 14 Jul 2022 17:47:45 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Thu, 14 Jul 2022 17:47:45 -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=1657835264; x=1657921664; bh=h uVbszS6k2nNwJwVyQ12yHP6QQ2vumA5E6GIITs5Ljk=; b=VoP4senrY7TcPVI4L aUYXsGobW39Z1BTiIddkk2Xdo1+NOnSlMrG8f+xm8UiJ4150EQWD9gYhOFgy7k5P r4JLfniO6k0mM7VwWzPRXAMmNiTaK9T933cSJ2xAJBdcwcO7/Go3QvrPDZbSYN83 kF0zOXiuYAn+91PYi3Ufppcx74QsqxrrAS3Tgjf1jTYg3+2LhbTlb3Y2+L9+h4J6 rhXwKttmIPMdAEGpEAyjfDLMnfzD4btAEgkCT6rOSRko8vpIoj56wk/gfd/H7IAa Oh8IpiP+WM9gLx/m1l4jGkhkf6FiRbgyWTr5xARjPX1cCeDsIHt2W6hQ3nDIEhWY +noVg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudektddgtddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvvefukfggtggugfgjsehmke erredttdejnecuhfhrohhmpeetlhhvrghrohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhr vgesrghlvhhhrdhnohdqihhprdhorhhgqeenucggtffrrghtthgvrhhnpeduleekkefgtd dttedtkefguddvieffleetgeejiefhteehkeevfeettdduvdfhueenucffohhmrghinhep vghnthgvrhhprhhishgvuggsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrg hrrghmpehmrghilhhfrhhomheprghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhr gh X-ME-Proxy: Feedback-ID: ia2694551:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 14 Jul 2022 17:47:44 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 674F236E; Thu, 14 Jul 2022 23:47:40 +0200 (CEST) Date: Thu, 14 Jul 2022 23:47:40 +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: <20220714214740.drhmvdx2aseqgvvb@alvherre.pgsql> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="hwk7mjf7k3wvtowq" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20220713164345.j3n67rc45rpa4vop@alvherre.pgsql> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --hwk7mjf7k3wvtowq Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Here's a couple of fixups. 0001 is the same as before. In 0002 I think CheckTablespaceDirectory ends up easier to read if we split out the test for validity of the link. Looking at that again, I think we don't need to piggyback on ignore_invalid_pages, which is already a stretch, so let's not -- instead we can use allow_in_place_tablespaces if users need a workaround. So that's 0003 (this bit needs more than zero docs, however.) 0004 is straightforward: let's check for bad directories before logging about consistent state. After all this, I'm not sure what to think of dbase_redo. At line 3102, is the directory supposed to exist or not? I'm confused as to what is the expected state at that point. I rewrote this, but now I think my rewrite continues to be confusing, so I'll have to think more about it. Another aspect are the tests. Robert described a scenario where the previously committed version of this patch created trouble. Do we have a test case to cover that problematic case? I think we should strive to cover it, if possible. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "The eagle never lost so much time, as when he submitted to learn of the crow." (William Blake) --hwk7mjf7k3wvtowq Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v25-0001-Fix-replay-of-create-database-records-on-standby.patch"