Re: increased duration of stats_ext tests with -DCLOBBER_CACHE_ALWAYS
| От | Andrew Dunstan |
|---|---|
| Тема | Re: increased duration of stats_ext tests with -DCLOBBER_CACHE_ALWAYS |
| Дата | |
| Msg-id | c2696257-1865-47c7-99c9-d9857d560f48@dunslane.net обсуждение исходный текст |
| Ответ на | Re: increased duration of stats_ext tests with -DCLOBBER_CACHE_ALWAYS (Tomas Vondra <tomas@vondra.me>) |
| Список | pgsql-hackers |
On 2025-12-06 Sa 7:04 AM, Tomas Vondra wrote: > > 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. > > Nothing of significance to what is run changed between 19.1 and 20. See https://github.com/PGBuildFarm/client-code/compare/REL_19_1...REL_20 cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: