Обсуждение: Add .NOTPARALLEL to contrib/Makefile
Hi, Currently running "make -j16 all check" in contrib/ results in a mess because all pg_regress invocations fight over the same port. Adding a simple .NOTPARALLEL: check-%-recurse into contrib/Makefile fixes that. Do we want that? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
Andres Freund <andres@2ndquadrant.com> writes: > Currently running "make -j16 all check" in contrib/ results in a mess because > all pg_regress invocations fight over the same port. Adding a simple > .NOTPARALLEL: check-%-recurse > into contrib/Makefile fixes that. Do we want that? Dunno, but if we do, it should be applied to installcheck as well. (In that case the fight is over the contrib_regression database.) A larger point is that you shouldn't really fix this only for contrib. What about tests run in src/pl, or contrib vs the main regression tests vs src/pl vs test/isolationtester, etc etc. regards, tom lane
On 2014-08-25 20:16:50 -0400, Tom Lane wrote: > Andres Freund <andres@2ndquadrant.com> writes: > > Currently running "make -j16 all check" in contrib/ results in a mess because > > all pg_regress invocations fight over the same port. Adding a simple > > .NOTPARALLEL: check-%-recurse > > into contrib/Makefile fixes that. Do we want that? > > Dunno, but if we do, it should be applied to installcheck as well. > (In that case the fight is over the contrib_regression database.) Right. Although you can mostly fight it there using USE_MODULE_DB. The attached patch that replaces all hardcoded occurrences of 'contrib_regression' with current_database(). Allowing a make -j32 -s installcheck in contrib to succeed in less than 4 seconds... That's not particularly pretty, especially in the CREATE SERVER calls (via DO ... EXECUTE), but imo worth it given the timesavings. What's your thought on that one? > A larger point is that you shouldn't really fix this only for contrib. > What about tests run in src/pl, or contrib vs the main regression tests > vs src/pl vs test/isolationtester, etc etc. Unfortunately I don't think you can make .NOTPARALLEL work across more than one directory when using recursive make :(. At least I don't know how. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Вложения
On Tue, 2014-08-26 at 02:05 +0200, Andres Freund wrote: > Currently running "make -j16 all check" in contrib/ results in a mess > because > all pg_regress invocations fight over the same port. Adding a simple > .NOTPARALLEL: check-%-recurse > into contrib/Makefile fixes that. Do we want that? But that causes also the "all" to be run in not-parallel, because the meaning of .NOTPARALLEL is: If `.NOTPARALLEL' is mentioned as a target, then this invocation of `make' will be run serially, even if the `-j'option is given. It does not mean, as you appear to imagine, to run only the listed prerequisites in not-parallel. That would be nice!
On 2014-08-26 23:56:10 -0400, Peter Eisentraut wrote: > On Tue, 2014-08-26 at 02:05 +0200, Andres Freund wrote: > > Currently running "make -j16 all check" in contrib/ results in a mess > > because > > all pg_regress invocations fight over the same port. Adding a simple > > .NOTPARALLEL: check-%-recurse > > into contrib/Makefile fixes that. Do we want that? > > But that causes also the "all" to be run in not-parallel, because the > meaning of .NOTPARALLEL is: > > If `.NOTPARALLEL' is mentioned as a target, then this invocation of > `make' will be run serially, even if the `-j' option is given. Argh. There goes that. > It does not mean, as you appear to imagine, to run only the listed > prerequisites in not-parallel. That would be nice! Yea. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services