Andrew Dunstan writes:
> On 7/3/21 6:59 PM, Tom Lane wrote:
>> 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
On 7/3/21 6:59 PM, Tom Lane wrote:
> I wrote:
>> Andrew Dunstan 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
I wrote:
> Andrew Dunstan 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
Andrew Dunstan writes:
> On 7/1/21 11:01 AM, Tom Lane wrote:
>> 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
On 7/1/21 11:01 AM, Tom Lane wrote:
> 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
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
Andrew Dunstan writes:
> Looks OK for the buildfarm patch. I wonder if we just want to run initdb
> once with --clobber-cache instead of once per locale?
I thought about that, but I'm not sure it's appropriate for the buildfarm
client to be making that decision. I do not think any of the CCA
On 6/22/21 5:11 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> 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
Andrew Dunstan writes:
> 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
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
>
I had an idea for another way to attack $SUBJECT, now that we have
the ability to adjust debug_invalidate_system_caches_always at
runtime. Namely, that a lot of time goes into repeated initdb
runs (especially if the TAP tests are enabled); but surely we
learn little from CCA initdb runs after the
11 matches
Mail list logo
