From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Reducing the cycle time for CLOBBER_CACHE_ALWAYS buildfarm members |
Date: | 2021-06-20 23:28:29 |
Message-ID: | 467e9f1a-f440-4875-2677-36f52f556f62@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 6/20/21 6:10 PM, Tom Lane wrote:
> (3) Since this only works in v14 and up, older branches would
> have to fall back to -DCLOBBER_CACHE_ALWAYS. Perhaps we could
> improve the buildfarm client script so that buildfarm owners
> just configure "clobber_cache_testing => 1" and then the script
> would do the right branch-dependent thing.
Maybe. Let's see what you come up with.
>
> Of course, we could eliminate the need for branch-dependent
> logic if we cared to back-patch the addition of the
> debug_invalidate_system_caches_always GUC, but that's probably
> a bridge too far.
Yeah, I think so.
>
> It looks to me like this would cut around an hour off of the
> roughly-a-day cycle times of the existing CCA animals. None
> of them run any TAP tests, presumably because that would make
> their cycle time astronomical, but maybe this change will help
> make that practical.
>
It might. I'm fairly sure there are a lot of repetitive cycles wasted in
the TAP tests, quite apart from initdb. We've become rather profligate
in our use of time and resources.
cheers
adrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2021-06-20 23:45:12 | Re: seawasp failing, maybe in glibc allocator |
Previous Message | Alexander Korotkov | 2021-06-20 22:24:18 | Re: unnesting multirange data types |