Re: build farm machine using mixed results - Mailing list pgsql-hackers

From Aidan Van Dyk
Subject Re: build farm machine using mixed results
Date
Msg-id CAC_2qU-8kEd8ZBnnD8tEC2JSnCQnMyq7PsVPPeWA-iiv_j-88w@mail.gmail.com
Whole thread Raw
In response to Re: build farm machine using mixed results  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
<p dir="ltr"><br /> On Sep 4, 2012 6:06 PM, "Andrew Dunstan" <<a
href="mailto:andrew@dunslane.net">andrew@dunslane.net</a>>wrote:<br /> ><br /> ><br /> > Frankly, I have
hadenough failures of parallel make that I think doing this would generate a significant number of non-repeatable
failures(I had one just the other day that took three invocations of make to get right). So I'm not sure doing this
wouldadvance us much, although I'm open to persuasion.<p dir="ltr">Seeing as most PostgreSQL bugs appear with
concurrency,I think we should leave our default config with 1 for max connections.<p dir="ltr"> ;-)<p
dir="ltr">Parallelmake failures are bugs in the dependencies as described in our make files.<p dir="ltr">For the build
phase,I don't recall parallel problems and as a habit I usually use parallel makes.  I would like that to be supported
andI think I've seen fixes applied when we had issues before.  Cutting build times to 1/2 to 1/4 is good.<p
dir="ltr">Checksand tests are harder because often they can't run in parallel. But then we shouldn't have them listed
asindependent prerequisites for targets.   Ideally.  But fixing it might not be worth the cost since an "acceptable"
workaround (rely upon make to serialize the test sequences in the particular order) is pretty painless (so far).  <p
dir="ltr">Ofcourse, having the ability to run the tests 8 at a time (or more) and reduce the time by 80% would be nice
.;-)<divclass="gmail_quote">On Sep 4, 2012 6:06 PM, "Andrew Dunstan" <<a
href="mailto:andrew@dunslane.net">andrew@dunslane.net</a>>wrote:<br type="attribution" /><blockquote
class="gmail_quote"style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br /> On 09/04/2012 05:49 PM,
PeterEisentraut wrote:<br /><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">On 9/1/12 12:12 PM, Robert Creager wrote:<br /><blockquote class="gmail_quote" style="margin:0
00 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I change the build-farm.conf file to have the following make
line:<br/><br />      make => 'make -j 8', # or gmake if required. can include path if<br /> necessary.<br /><br />
2pass, 4 fail.  Is this a build configuration you want to pursue?<br /></blockquote> Sure that would be useful, but
it'spretty clear that the check stages<br /> don't work in parallel.  It think it's because the ports conflict, but<br
/>there could be any number of other problems.<br /><br /> That said, it would be useful, in my mind, to support
parallelchecks.<br /> But unless someone is going to put in the work first, you should<br /> restrict your parallel
runsto the build and install phases.<br /><br /><br /></blockquote><br /><br /> The buildfarm code doesn't contain a
facilityto use a different make incantation for each step. It's pretty much an all or nothing deal. Of course, you can
hack<a href="http://run_build.pl" target="_blank">run_build.pl</a> to make it do that, but I highly discourage that.
Forone thing, it makes upgrading that much more difficult. All the  tweaking is supposed to be done vie the config
file.I guess I could add a setting that allowed for per step make flags.<br /><br /> Frankly, I have had enough
failuresof parallel make that I think doing this would generate a significant number of non-repeatable failures (I had
onejust the other day that took three invocations of make to get right). So I'm not sure doing this would advance us
much,although I'm open to persuasion.<br /><br /> cheers<br /><br /> andrew<br /><br /><br /> -- <br /> Sent via
pgsql-hackersmailing list (<a href="mailto:pgsql-hackers@postgresql.org"
target="_blank">pgsql-hackers@postgresql.org</a>)<br/> To make changes to your subscription:<br /><a
href="http://www.postgresql.org/mailpref/pgsql-hackers"
target="_blank">http://www.postgresql.org/<u></u>mailpref/pgsql-hackers</a><br/><br /></blockquote></div> 

pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: Cascading replication and recovery_target_timeline='latest'
Next
From: Tom Lane
Date:
Subject: Re: Cascading replication and recovery_target_timeline='latest'