Re: Reducing the cycle time for CLOBBER_CACHE_ALWAYS buildfarm members

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Subject: Re: Reducing the cycle time for CLOBBER_CACHE_ALWAYS buildfarm members
Date: 2021-07-01 17:03:00
Message-ID: ed2e8c7f-dbfc-29a5-1c89-2dd2bd5075ea@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 7/1/21 11:01 AM, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> 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.
>
>

Seems reasonable. I don't have a CCA animal any more, but I guess I
could set up a test.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-07-01 17:17:42 Re: Reducing the cycle time for CLOBBER_CACHE_ALWAYS buildfarm members
Previous Message Álvaro Herrera 2021-07-01 17:01:19 Re: Partitioned index can be not dumped