On 04/11/2017 03:58 PM, Andres Freund wrote: > On 2017-04-11 15:52:34 -0400, Tom Lane wrote: >> Andrew Dunstan <andrew.duns...@2ndquadrant.com> writes: >>>> The other thing that might be useful here is to push on parallelizing >>>> buildfarm runs. >>> One reason I haven't supported "make -j nn" everywhere (it is supported >>> for making core, contrib and test_modules) is that the output tends to >>> get rather jumbled, and I didn't want to impose that extra burden in >>> people trying to decipher the results. >> Agreed, that would be a mess. > Doesn't make's -Otarget largely solve this? >
Possibly, but I have just gone to a not inconsiderable amount of trouble to disaggregate the TAP tests so we get not only the output but all the logs for each step separately. Say there's a problem in pg_rewind. Compare this <https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=nightjar&dt=2017-04-11%2017%3A54%3A34&stg=pg_rewind-installcheck> with having to pick apart this: <https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=crake&dt=2017-04-08%2010%3A37%3A38&stg=bin-check> So I don't really want the output from these run in parallel to be run all together, even if they aren't jumbled. Now it might make sense for other pieces to be run like that. I will have a look. But the ones that are taking the most time are ones that seem least suitable. Afterthought: It might be possible to make it a runtime option. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers