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 1lyyBs-0003Cq-Kc for pgsql-hackers@arkaria.postgresql.org; Thu, 01 Jul 2021 15:01:20 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lyyBq-0006aX-PW for pgsql-hackers@arkaria.postgresql.org; Thu, 01 Jul 2021 15:01:18 +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 1lyyBq-0006aP-Hp for pgsql-hackers@lists.postgresql.org; Thu, 01 Jul 2021 15:01:18 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lyyBo-0000Ig-97 for pgsql-hackers@lists.postgresql.org; Thu, 01 Jul 2021 15:01:18 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 161F1BLp693604; Thu, 1 Jul 2021 11:01:11 -0400 From: Tom Lane To: Andrew Dunstan cc: pgsql-hackers@lists.postgresql.org, Peter Eisentraut Subject: Re: Reducing the cycle time for CLOBBER_CACHE_ALWAYS buildfarm members In-reply-to: <3f3f3d9d-fccf-318d-5c16-622778b42645@dunslane.net> References: <1582507.1624227029@sss.pgh.pa.us> <467e9f1a-f440-4875-2677-36f52f556f62@dunslane.net> <1799344.1624396289@sss.pgh.pa.us> <3f3f3d9d-fccf-318d-5c16-622778b42645@dunslane.net> Comments: In-reply-to Andrew Dunstan message dated "Wed, 23 Jun 2021 09:21:02 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <693602.1625151671.1@sss.pgh.pa.us> Date: Thu, 01 Jul 2021 11:01:11 -0400 Message-ID: <693603.1625151671@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Andrew Dunstan writes: > On 6/22/21 5:11 PM, Tom Lane wrote: >> Here's a couple of draft-quality patches --- one for initdb, one >> for the buildfarm --- to implement this idea. These are just >> lightly tested; in particular I've not had the patience to run >> full BF cycles to see how much is actually saved. > Looks OK for the buildfarm patch. I wonder if we just want to run initdb > once with --clobber-cache instead of once per locale? So, where do we want to go with these? I'm inclined to argue that it's okay to sneak the initdb change into v14, on the grounds that it's needed to fully exploit the change from CLOBBER_CACHE_ALWAYS to debug_invalidate_system_caches_always. Without it, there is no way to do CCA testing on the bootstrap process except by reverting to the old hard-wired way of doing things. Having pushed that, we could try out the buildfarm side of the change and verify it's okay. regards, tom lane