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 1oK3x4-0007AL-Rx for pgsql-hackers@arkaria.postgresql.org; Fri, 05 Aug 2022 20:29:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oK3x3-0007QN-N7 for pgsql-hackers@arkaria.postgresql.org; Fri, 05 Aug 2022 20:29:45 +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 1oK3x2-0007Mm-Od for pgsql-hackers@lists.postgresql.org; Fri, 05 Aug 2022 20:29:45 +0000 Received: from out2-smtp.messagingengine.com ([66.111.4.26]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oK3wx-0005BC-El for pgsql-hackers@postgresql.org; Fri, 05 Aug 2022 20:29:44 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 842565C014F; Fri, 5 Aug 2022 16:29:33 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Fri, 05 Aug 2022 16:29:33 -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=1659731373; x=1659817773; bh=D pYeFQEfT9KlzoOBP9x8Ye8FOsAveOeX0oy7RTuJ66E=; b=uGaQVfKevwu2JoYcG lBE5X+LPYTlhYR/V8nUDL0Lw9kzNe8oJIIKgbn28ewUNCjkRnUM1/fcdwXXl4QBp m+tXj+r5qaE7FlyG/f0gq9lzjblNhw0GJ1nkUJZlw5KUtKtNCYOgqsq2LPSsv5Xv abbM+P9yLibYyI0DoyQii0XzaBQZmrW1Yyt6Gif3qmZEl1TW5fL45w0KOnQnBNcb O4gzIMaKY8tREKKiW04B8+DDZA26U7HdHJJ/86AUpzbHaZUZRZhoaFoBbtcdFaTX ZyDqld3z12GQoSt9vMtvUMxioAQ2raJCFiNvHHroZujkkf15M0qX/jDlYrfwK+y6 8njzw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrvdefuddgudehvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepfffhvfevuffkgggtugfgjgesth ekredttddtjeenucfhrhhomheptehlvhgrrhhoucfjvghrrhgvrhgruceorghlvhhhvghr rhgvsegrlhhvhhdrnhhoqdhiphdrohhrgheqnecuggftrfgrthhtvghrnhepvdektdffud fftdffffehfffhjeejhffgieeuueekjeekfffgudffhfduffffueevnecuffhomhgrihhn pegvnhhtvghrphhrihhsvggusgdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdho rhhg X-ME-Proxy: Feedback-ID: ia2694551:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 5 Aug 2022 16:29:32 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 5BD3F373; Fri, 5 Aug 2022 22:29:40 +0200 (CEST) Date: Fri, 5 Aug 2022 22:29:40 +0200 From: Alvaro Herrera To: Tom Lane Cc: Kyotaro Horiguchi , thomas.munro@gmail.com, boekewurm+postgres@gmail.com, pgsql-hackers@postgresql.org Subject: Re: standby recovery fails (tablespace related) (tentative patch and discussion) Message-ID: <20220805202940.oneu7mlg67cpo5jd@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <509375.1659199895@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2022-Jul-30, Tom Lane wrote: > BTW, quite aside from stability, is it really necessary for this test to > be so freakin' slow? florican for instance reports > > [12:54:07] t/033_replay_tsp_drops.pl ............ ok 117840 ms ( 0.01 usr 0.00 sys + 8.72 cusr 5.41 csys = 14.14 CPU) > > 027 is so bloated because it runs the core regression tests YA time, > which I'm not very happy about either; but that's no excuse for > every new test to contribute an additional couple of minutes. Definitely not intended. It looks like the reason is just that the DROP DATABASE/TABLESPACE commands are super slow, and this test does a lot of that. I added some instrumentation and the largest fraction of time goes to execute this CREATE DATABASE dropme_db1 WITH TABLESPACE dropme_ts1; CREATE TABLE t (a int) TABLESPACE dropme_ts2; CREATE DATABASE dropme_db2 WITH TABLESPACE dropme_ts2; CREATE DATABASE moveme_db TABLESPACE source_ts; ALTER DATABASE moveme_db SET TABLESPACE target_ts; CREATE DATABASE newdb TEMPLATE template_db; ALTER DATABASE template_db IS_TEMPLATE = false; DROP DATABASE dropme_db1; DROP TABLE t; DROP DATABASE dropme_db2; DROP TABLESPACE dropme_ts2; DROP TABLESPACE source_ts; DROP DATABASE template_db; Maybe this is overkill and we can reduce the test without damaging the coverage. I'll have a look during the weekend. I'll repair the reliability problem too, separately. -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/ "This is a foot just waiting to be shot" (Andrew Dunstan)