Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1f44m6-0005lP-R5 for pgsql-hackers@arkaria.postgresql.org; Thu, 05 Apr 2018 13:17:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1f44m4-0000LY-UD for pgsql-hackers@arkaria.postgresql.org; Thu, 05 Apr 2018 13:17:56 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1f44m3-0000LI-LI for pgsql-hackers@lists.postgresql.org; Thu, 05 Apr 2018 13:17:56 +0000 Received: from new1-smtp.messagingengine.com ([66.111.4.221]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1f44m0-0005jO-Aw for pgsql-hackers@postgresql.org; Thu, 05 Apr 2018 13:17:54 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.nyi.internal (Postfix) with ESMTP id 9F7B29B2; Thu, 5 Apr 2018 09:17:50 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 05 Apr 2018 09:17:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=dv/fuiTgeUlDo9k2k 51zUgRgo7BD8xmqrvZvRLdWOwc=; b=Qq1OtQyplTcYCdstc+wD0aDNGXQwba5OU +JhaG4UV/uZmk0+UWUBbbqLZ0QEF1aJCj8mmrQsP5azJotFL0EZ/rpgXxmHeGY6T GNqRp4SSLvlkgWCzUsaQvkNU8Bj3W01bYOvNxuj1Bg5y4M4yvSysqzaqQINbzXo0 eli4GiZGAjahiyz8p2zZqDG06KFKrsnsMVrJclfjc/y8zOQQihdwcDtXEAAoc55/ 8Wq0gnuRyQCixVUgFPIs3el4DvnuaXUzgjYD/un0GBNYPcjj5FzD/jqFh1ozmySz g7i/tSEirXdSrwjRTptOCahG4Qf9ZM93iNb9djZubQX3H/o+2dw1g== X-ME-Sender: Received: from alvin.alvh.no-ip.org (unknown [179.56.29.253]) by mail.messagingengine.com (Postfix) with ESMTPA id E92E610251; Thu, 5 Apr 2018 09:17:49 -0400 (EDT) Received: by alvin.alvh.no-ip.org (Postfix, from userid 1000) id 23C4F71B; Thu, 5 Apr 2018 10:17:48 -0300 (-03) Date: Thu, 5 Apr 2018 10:17:48 -0300 From: Alvaro Herrera To: Michael Banck Cc: Magnus Hagander , Tom Lane , Andres Freund , David Steele , PostgreSQL-development Subject: Re: pgsql: Validate page level checksums in base backups Message-ID: <20180405131748.3zrjzedxmhkr445v@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180405124113.GH20852@nighthawk.caipicrew.dd-dns.de> User-Agent: NeoMutt/20170306-137-4415bd-dirty (1.8.0) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Michael Banck wrote: > Hi, > > Do we have a precedent somewhere for how we do this, or does our test > > framework already have a way to do it? How are all the actual data > > directories etc cleaned up? > > They (and the base backups) are getting purged on success of the whole > testsuite. So to be clear - we are not leaving behind 1 GB of disk space > on success, but we use 1 GB of disk space during the test. Yeah, but it means you force the OS to keep 1 GB of useless dung in cache. I would hope that creating 40 MB, deleting those, then creating further 40 MB (lather, rinse, repeat) would not overall evict 1 GB from my OS cache. Unless the OS keeps the unlinked files in cache, which would be stupid. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services