On 04/11/2017 03:58 PM, Andres Freund wrote:
> On 2017-04-11 15:52:34 -0400, Tom Lane wrote:
>> Andrew Dunstan <andrew.dunstan@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