Re: TAP tests take a long time
Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
From: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
To: Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2017-04-11T21:16:16Z
Lists: pgsql-hackers
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
Commits
-
Speed up hash_index regression test.
- 4a8bc39b08aa 10.0 landed