From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Robert Creager <robert(at)logicalchaos(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: build farm machine using <make -j 8> mixed results |
Date: | 2012-09-09 00:35:02 |
Message-ID: | 504BE436.6090805@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 09/08/2012 07:54 PM, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> I have just repeated this on an absolutely fresh up to date F17 machine,
>> with no symlink stuff in play.
>> Steps to recreate:
>> CC="ccache gcc" ../postgres/configure --enable-depend --enable-debug
>> --enable-cassert --with-perl --with-python --with-tcl --with-libxml
>> --with-libxslt -with-openssl --with-gssapi --with-pam --with-ldap
>> make -j 4
> Huh ... that recipe works (er, fails) for me too, at least some of the
> time. I wonder what exactly is the key difference between the working
> and failing cases?
>
> Anyway, what I notice is that I get different types of failures, but
> they are all under ecpg/. What I think we need to do is insert
> .NOTPARALLEL in ecpg/Makefile, because there are several reasons not
> to run its sub-makes in parallel:
>
> * preproc/Makefile casually does this:
>
> ../ecpglib/typename.o: ../ecpglib/typename.c
> $(MAKE) -C $(dir $@) $(notdir $@)
>
> which is very likely to screw up any make proceeding in parallel in
> ecpglib.
>
> * compatlib and ecpglib will equally casually invoke "make all" in
> other subdirectories; ditto.
>
> And that's not even counting the bison-output problem you were seeing.
> I'm not entirely sure what's causing that, but I'm suspicious that the
> ultimate cause is the extra rules for the "all...recurse" targets in
> ecpg/Makefile, which look like they could result in additional instances
> of multiple make processes running in the same subdirectory.
>
> After adding the .NOTPARALLEL marker, I don't see these failures
> anymore.
>
>
Well, I'm glad it's not just me. :-)
This fix works for me too.
I guess it should be applied back to 9.1, when it looks like we started
using .NOTPARALLEL
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2012-09-09 01:20:30 | Re: Python version dependency in plpython regression tests |
Previous Message | Tom Lane | 2012-09-08 23:54:01 | Re: build farm machine using <make -j 8> mixed results |