Add .NOTPARALLEL to contrib/Makefile

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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!

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers