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...
[1]
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=avocet&dt=2025-12-05%2013%3A21%3A32 [2]
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=avocet&dt=2025-11-24%2016%3A21%3A44 [3[
https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=avocet&br=REL_15_STABLE [4]
https://github.com/PGBuildFarm/client-code/releases/tag/REL_20 Best regards,
Alexander
