On 2025-Apr-03, Andres Freund wrote:
> I've increased the timeout even further, but I can't say that I am happy about
> the slowest test getting even slower. Adding test time in the serially slowest
> test is way worse than adding the same time in a concurrent test.
Yeah. We discussed strategies to shorten the runtime, but the agreement
upthread was that we'd look for more elaborate ways to do that
afterwards. As I mentioned, I can see adding something like
PG_TEST_EXCLUDE that we could use to suppress this test on slow hosts.
Would that work for you?
(We also discussed the fact that this was part of 002_pg_upgrade.pl
instead of being elsewhere. The reason is that this depends on the
regression tests having run, and this is the only TAP test that does
that. Well, this one and 027_stream_regress.pl which is even slower.)
> I suspect that the test will go a bit faster if log_statement weren't forced
> on, printing that many log lines, with context, does make valgrind slower,
> IME. But Cluster.pm forces it to on, and I suspect that putting a global
> log_statement=false into TEMP_CONFIG would have it's own disadvantages.
I'm sure we can make this change as well somehow, overridding the
setting just 002_pg_upgrade.pl, as attached. I don't think it's
relevant for this particular test. The log files go from 21 MB to
2.4 MB. It's not nothing ...
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"Selbst das größte Genie würde nicht weit kommen, wenn es
alles seinem eigenen Innern verdanken wollte." (Johann Wolfgang von Goethe)
Ni aún el genio más grande llegaría muy lejos si
quisiera sacarlo todo de su propio interior.
