Hi, On 2019-05-20 13:46:55 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On 2019-05-21 01:43:35 +0900, Fujii Masao wrote: > >> Thanks for the commit! And sorry, make check-world took very long time > >> and has just finished right now in my env... I'd like to confirm that > >> make check-world reports no error just in case. > > > make -j16 -s && make -Otarget -j10 -s check-world && echo success || echo > > fail > > > makes that much more bearable, by running the slow TAP tests in > > parallel. Doesn't work < 10 though.
Kinda wonder whether we should backpatch the necessary changes to make -j .. check work back to 9.4. > Yeah, parallelization makes all the difference in the world, assuming > you have a multi-core machine. You can parallelize within TAP suites > too. I use > > make -s check-world -j4 PROVE_FLAGS='-j4 --quiet --nocolor --nocount' > > on an 8-core machine, and get typical runtimes under 2m30s. FWIW, I found that parallelizing on the top-level to get better performance than within prove. The system load is more predicatable. > If there were a way to get prove to be absolutely quiet (its --quiet is > a joke unfortunately), I'd lobby for a switch to make pg_regress quiet > too. The amount of useless noise this recipe generates is annoying, > and tends to make it hard to find where the actual error is when > there is one. Indeed. Couldn't we just invent that on our end? I.e. in our prove invocation, just redirect the output? The most annoying noise imo is the pg_upgrade test. The set -x and the fact that it resets MAKEFLAGS makes that pretty annoying. Greetings, Andres Freund
