Re: increased duration of stats_ext tests with -DCLOBBER_CACHE_ALWAYS
Andrew Dunstan <andrew@dunslane.net>
From: Andrew Dunstan <andrew@dunslane.net>
To: Tomas Vondra <tomas@vondra.me>, Alexander Lakhin <exclusion@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
Tom Lane <tgl@sss.pgh.pa.us>
Date: 2025-12-06T16:09:39Z
Lists: 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