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
