Re: build farm machine using mixed results - Mailing list pgsql-hackers
From | Aidan Van Dyk |
---|---|
Subject | Re: build farm machine using |
Date | |
Msg-id | CAC_2qU-8kEd8ZBnnD8tEC2JSnCQnMyq7PsVPPeWA-iiv_j-88w@mail.gmail.com Whole thread Raw |
In response to |
Re: build farm machine using |
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: