pgsql: Put back parallel-safety guards in plpython andsrc/test/regress - Mailing list pgsql-committers

From Tom Lane
Subject pgsql: Put back parallel-safety guards in plpython andsrc/test/regress
Date
Msg-id E1f5zfj-0006lM-FM@gemulon.postgresql.org
Whole thread Raw
List pgsql-committers
Put back parallel-safety guards in plpython and src/test/regress/.

I'd hoped that commit 3b8f6e75f was sufficient to ensure parallel safety
even when a build started in a subdirectory requires rebuilding of
generated headers.  This isn't so, because making submake-generated-headers
a prerequisite of "all" isn't enough to ensure it's completed before
starting on "all"'s other prerequisites.  The explicit dependencies we put
on the recursive make targets ensure safe ordering before we recurse into
child directories, but they don't protect targets to be made in the current
directory.  Hence, put back some ordering dependencies in directories that
we've traditionally expected to be starting points for "standalone" builds,
to wit src/pl/plpython and src/test/regress.  (The former needs this in
order to minimize the work involved in building for both python 2 and
python 3; the latter to support packagings that make the regression tests
available for out-of-build-tree execution.)  Adjust some other dependencies
so that these two cases work correctly even at high -j settings.

I'm not terribly happy with this partial solution, but I don't see a
way to do better without massive makefile restructuring, which we surely
aren't doing at this point in the development cycle.  In any case, it's
little if any worse than what we had in prior releases.

Discussion: https://postgr.es/m/1523353963.8169.26.camel@gunduz.org

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/31f1f0bb4fd642643994d35c35ecb5b929711a99

Modified Files
--------------
src/Makefile.global.in       | 4 ++--
src/pl/plpython/Makefile     | 3 +++
src/test/regress/GNUmakefile | 8 ++++++--
3 files changed, 11 insertions(+), 4 deletions(-)


pgsql-committers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: pgsql: Optimize btree insertions for common case of increasing values
Next
From: Andrew Dunstan
Date:
Subject: pgsql: Adjustments to the btree fastpath optimization.