Horton

Thread

Commits

  1. Add --clobber-cache option to initdb, for CCA testing.

  1. Reducing the cycle time for CLOBBER_CACHE_ALWAYS buildfarm members

    Tom Lane <tgl@sss.pgh.pa.us> — 2021-06-20T22:10:29Z

    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 first one.  We could
trim this fat by:

(1) Instead of applying CLOBBER_CACHE_ALWAYS as a compile option,
add "debug_invalidate_system_caches_always = 1" to the buildfarm's
"extra_config" options, which are added to postgresql.conf after
initdb.  Thus, initdb will run without that option but all the
actual test cases will have it.

(2) To close the testing gap that now we have *no* CCA coverage
of initdb runs, adjust either the buildfarm's initdb-only steps
or initdb's 001_initdb.pl TAP script to set
"debug_invalidate_system_caches_always = 1" in one of the runs.
I think we can make that happen so far as the bootstrap backend is
concerned by including "-c debug_invalidate_system_caches_always=1"
on its command line; but of course initdb itself has no way to be
told to do that.  I think we could invent a "-c NAME=VALUE" switch
for initdb to tell it to pass down that switch to its child
backends.  Then there'd have to be some way to tell the calling
tests whether to do that.

(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.

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.

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.

Thoughts?
			regards, tom lane

  2. Re: Reducing the cycle time for CLOBBER_CACHE_ALWAYS buildfarm members

    Andrew Dunstan <andrew@dunslane.net> — 2021-06-20T23:28:29Z

    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

  3. Re: Reducing the cycle time for CLOBBER_CACHE_ALWAYS buildfarm members

    Tom Lane <tgl@sss.pgh.pa.us> — 2021-06-22T21:11:29Z

    Andrew Dunstan <andrew@dunslane.net> 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 => 1" and then the script
>> would do the right branch-dependent thing.

> Maybe. Let's see what you come up with.

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.

			regards, tom lane

  4. Re: Reducing the cycle time for CLOBBER_CACHE_ALWAYS buildfarm members

    Andrew Dunstan <andrew@dunslane.net> — 2021-06-23T13:21:02Z

    On 6/22/21 5:11 PM, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> 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 => 1" and then the script
>>> would do the right branch-dependent thing.
>> Maybe. Let's see what you come up with.
> 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?


cheers


andrew

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

  5. Re: Reducing the cycle time for CLOBBER_CACHE_ALWAYS buildfarm members

    Tom Lane <tgl@sss.pgh.pa.us> — 2021-06-23T13:32:19Z

    Andrew Dunstan <andrew@dunslane.net> 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 animals
run more than one locale anyway, so it's likely moot.

			regards, tom lane

  6. Re: Reducing the cycle time for CLOBBER_CACHE_ALWAYS buildfarm members

    Tom Lane <tgl@sss.pgh.pa.us> — 2021-07-01T15:01:11Z

    Andrew Dunstan <andrew@dunslane.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.

			regards, tom lane

  7. Re: Reducing the cycle time for CLOBBER_CACHE_ALWAYS buildfarm members

    Andrew Dunstan <andrew@dunslane.net> — 2021-07-01T17:03:00Z

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

  8. Re: Reducing the cycle time for CLOBBER_CACHE_ALWAYS buildfarm members

    Tom Lane <tgl@sss.pgh.pa.us> — 2021-07-01T17:17:42Z

    Andrew Dunstan <andrew@dunslane.net> 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 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.

I can run a test here --- I'll commandeer sifaka for awhile,
since that's the fastest animal I have.

			regards, tom lane

  9. Re: Reducing the cycle time for CLOBBER_CACHE_ALWAYS buildfarm members

    Tom Lane <tgl@sss.pgh.pa.us> — 2021-07-03T22:59:49Z

    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.

			regards, tom lane

  10. Re: Reducing the cycle time for CLOBBER_CACHE_ALWAYS buildfarm members

    Andrew Dunstan <andrew@dunslane.net> — 2021-07-04T10:49:13Z

    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

  11. Re: Reducing the cycle time for CLOBBER_CACHE_ALWAYS buildfarm members

    Tom Lane <tgl@sss.pgh.pa.us> — 2021-07-04T14:54:50Z

    Andrew Dunstan <andrew@dunslane.net> 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 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?

No objections here.

			regards, tom lane