Re: Reducing the cycle time for CLOBBER_CACHE_ALWAYS buildfarm members - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Reducing the cycle time for CLOBBER_CACHE_ALWAYS buildfarm members
Date
Msg-id b106a38c-6459-e3b5-7d9c-09097de1468b@dunslane.net
Whole thread Raw
In response to Re: Reducing the cycle time for CLOBBER_CACHE_ALWAYS buildfarm members  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Reducing the cycle time for CLOBBER_CACHE_ALWAYS buildfarm members  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 7/3/21 6:59 PM, Tom Lane wrote:
> I wrote:
>> Andrew Dunstan <andrew@dunslane.net> writes:
>>> Seems reasonable. I don't have a CCA animal any more, but I guess I
>>> could set up a test.
>> I can run a test here --- I'll commandeer sifaka for awhile,
>> since that's the fastest animal I have.
> Done, and here's the results:
>
> Traditional way (-DCLOBBER_CACHE_ALWAYS): 32:53:24
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=sifaka&dt=2021-07-01%2018%3A06%3A09
>
> New way: 16:15:43
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=sifaka&dt=2021-07-03%2004%3A02%3A16
>
> That's running sifaka's full test schedule including TAP tests,
> which ordinarily takes it a shade under 10 minutes.  The savings
> on a non-TAP run would be a lot less, of course, thanks to
> fewer initdb invocations.
>
> Although I lacked the patience to run a full back-branch cycle
> with -DCLOBBER_CACHE_ALWAYS, I did verify that the patch
> correctly injects that #define when running an old branch.
> So I think it's ready to go into the buildfarm, modulo any
> cosmetic work you might want to do.
>
>             




Yeah, I'm looking at it now. A couple of things: I think we should
probably call the setting 'use_clobber_cache_always' since that's what
it does. And I think we should probably put in a sanity check to make it
incompatible with any -DCLOBBER_CACHE_* define in CPPFLAGS.


Thoughts?


There is one item  I want to complete before putting out a new client
release - making provision for a change in the name of the default git
branch - the aim is that with the new release in place that will be
completely seamless whenever it happens and whatever name is chosen. I
hope to have that done in a week or so., so the new release would be out
in about two weeks, if all goes well.


cheers


andrew


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




pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Update maintenance_work_mem/autovacuum_work_mem to reflect the 1GB limitation with VACUUM
Next
From: Dean Rasheed
Date:
Subject: Re: rand48 replacement