On 12/6/25 10:00, Alexander Lakhin wrote:
> Hello Tomas,
>
> 03.12.2025 21:23, Tomas Vondra wrote:
>> On 12/3/25 19:33, Tom Lane wrote:
>>> I wrote:
>>>> Yeah, I can imagine that constantly flushing the cached plan for
>>>> that plpgsql function would be bad. Let me see if I can reformulate
>>>> that test without using a plpgsql function --- right offhand, it's
>>>> not obvious why a built-in function wouldn't serve the purpose
>>>> just as well.
>>> I pushed a change for this. On my Mac laptop, it brings the time
>>> for stats_ext with -DCLOBBER_CACHE_ALWAYS down to ~8 minutes, from
>>> I-didn't-have-the-patience-to-wait-but-it-would-have-been-hours.
>>>
>> Thanks!
>
> That change decreased the test duration on master:
> [1] ok 159 + stats_ext 964154 ms
> vs
> [2] ok 157 + stats_ext 16557572 ms
>
> but the test run still failed (and also fails on other branches, where the
> duration is moderate), probably because of the overall timeout changed
> somehow.
>
> The last good run on avocet, REL_15_STABLE [3] took 12:49:15, however all
> the failed runs timed out in 4 hours (14400 seconds):
> timedout [7e54eac] (03:59:27)
> timedout [7792bdc] (03:59:53)
> The difference between the last good run and the first bad one I see is:
> 'script_version' => 'REL_19_1',
> vs
> 'script_version' => 'REL_20',
> though I can't see timeout-related changes in [4], probably something was
> changed in the environment during the upgrade...
>
Yeah, I noticed that too. But I have no idea what could have changed or
why - the only thing I updated is the buildfarm client :-(
I initially thought it might be due to setting
use_installcheck_parallel => 1
but it still fails after reverting that change. I still have the
build-farm client v19.1 around, so I can try switching back to that.
regards
--
Tomas Vondra
