On 09/10/2012 02:44 PM, Tom Lane wrote:
I wrote:
And the answer is ... it's a gmake bug. Apparently introduced in 3.82.
http://savannah.gnu.org/bugs/?30653
https://bugzilla.redhat.com/show_bug.cgi?id=835424
So I think .NOTPARALLEL is just masking the true problem, but
nonetheless it's a proble
I wrote:
> And the answer is ... it's a gmake bug. Apparently introduced in 3.82.
> http://savannah.gnu.org/bugs/?30653
> https://bugzilla.redhat.com/show_bug.cgi?id=835424
> So I think .NOTPARALLEL is just masking the true problem, but
> nonetheless it's a problem. And given that the bug report
On 09/09/2012 05:00 PM, Tom Lane wrote:
Peter Eisentraut writes:
But then the answer could be, if you want to use parallel make, use a
version that's not broken.
That's not a terribly practical answer for people who use the "make"
supplied by their OS vendor, which is approximately 99.9% of p
Peter Eisentraut writes:
> But then the answer could be, if you want to use parallel make, use a
> version that's not broken.
That's not a terribly practical answer for people who use the "make"
supplied by their OS vendor, which is approximately 99.9% of people.
It's even less practical for pack
Peter Eisentraut writes:
> On Sun, 2012-09-09 at 14:05 -0400, Tom Lane wrote:
>> So I think .NOTPARALLEL is just masking the true problem, but
>> nonetheless it's a problem. And given that the bug report on savannah
>> has been ignored for two years, we should not hold our breath for a fix
>> to
On Sun, 2012-09-09 at 14:57 -0400, Tom Lane wrote:
> Andrew Dunstan writes:
> > On 09/09/2012 02:05 PM, Tom Lane wrote:
> >> And the answer is ... it's a gmake bug.
>
> > Thanks for pursuing this. Whether or not it masks the underlying
> > problem, it's still something we should do, no? In fact,
On Sun, 2012-09-09 at 14:05 -0400, Tom Lane wrote:
> And the answer is ... it's a gmake bug. Apparently introduced in 3.82.
>
> http://savannah.gnu.org/bugs/?30653
> https://bugzilla.redhat.com/show_bug.cgi?id=835424
>
> So I think .NOTPARALLEL is just masking the true problem, but
> nonetheless
Andrew Dunstan writes:
> On 09/09/2012 02:05 PM, Tom Lane wrote:
>> And the answer is ... it's a gmake bug.
> Thanks for pursuing this. Whether or not it masks the underlying
> problem, it's still something we should do, no? In fact, it seems to me
> like this makes it even less worth trying to
On 09/09/2012 02:05 PM, Tom Lane wrote:
And the answer is ... it's a gmake bug. Apparently introduced in 3.82.
http://savannah.gnu.org/bugs/?30653
https://bugzilla.redhat.com/show_bug.cgi?id=835424
So I think .NOTPARALLEL is just masking the true problem, but
nonetheless it's a problem. And
And the answer is ... it's a gmake bug. Apparently introduced in 3.82.
http://savannah.gnu.org/bugs/?30653
https://bugzilla.redhat.com/show_bug.cgi?id=835424
So I think .NOTPARALLEL is just masking the true problem, but
nonetheless it's a problem. And given that the bug report on savannah
has b
Andrew Dunstan writes:
> On 09/09/2012 11:31 AM, Tom Lane wrote:
>> I assume we need this for all active branches, if the buildfarm is
>> going to be stressing it?
> I can restrict it to only modern branches. Didn't we supposedly improve
> support for this during the 9.1 cycle? That seems like a
On 09/09/2012 11:31 AM, Tom Lane wrote:
Yeah. I am going to add a config parameter to the buildfarm to allow
parallelism for the "make" and "make contrib" stages, but I'm not going
to release it until this is fixed.
Well, why don't we stick .NOTPARALLEL in there for the moment, and then
if Pete
Andrew Dunstan writes:
> On 09/09/2012 03:29 AM, Tom Lane wrote:
>> Peter Eisentraut writes:
>>> On Sat, 2012-09-08 at 19:54 -0400, Tom Lane wrote:
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
.
On 09/09/2012 03:29 AM, Tom Lane wrote:
Peter Eisentraut writes:
On Sat, 2012-09-08 at 19:54 -0400, Tom Lane wrote:
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,
I'd hate tha
Peter Eisentraut writes:
> On Sat, 2012-09-08 at 19:54 -0400, Tom Lane wrote:
>> 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,
> I'd hate that, because the ecpg build is one
On Sat, 2012-09-08 at 19:54 -0400, Tom Lane wrote:
> 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,
I'd hate that, because the ecpg build is one of the slowest parts of the
buil
On 09/08/2012 07:54 PM, Tom Lane wrote:
Andrew Dunstan 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
Andrew Dunstan 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-l
On 09/08/2012 04:52 PM, Andrew Dunstan wrote:
On 09/08/2012 04:46 PM, Tom Lane wrote:
Andrew Dunstan writes:
Scratch that theory, that was just a transient. If anything it looks
like it is related to system load. When almost nothing was running on
the machine it worked fine. When I started u
On 09/08/2012 04:46 PM, Tom Lane wrote:
Andrew Dunstan writes:
Scratch that theory, that was just a transient. If anything it looks
like it is related to system load. When almost nothing was running on
the machine it worked fine. When I started up a Browser and an MUA the
problem occurred. Thi
On 09/08/2012 04:54 PM, Tom Lane wrote:
Andrew Dunstan writes:
And it's the stock Fedora build of make.
Which Fedora branch exactly?
The package version I was trying to reproduce with here is
make-3.82-8.fc16.x86_64.
Same:
$ rpm -q make
make-3.82-8.fc16.x86_64
cheers
andrew
--
Andrew Dunstan writes:
> And it's the stock Fedora build of make.
Which Fedora branch exactly?
The package version I was trying to reproduce with here is
make-3.82-8.fc16.x86_64.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
T
Andrew Dunstan writes:
> Scratch that theory, that was just a transient. If anything it looks
> like it is related to system load. When almost nothing was running on
> the machine it worked fine. When I started up a Browser and an MUA the
> problem occurred. This VM has 4 CPUs and 4Gb of memory
On 09/08/2012 11:06 AM, Tom Lane wrote:
Andrew Dunstan writes:
This seems totally stupid, but it happens when the path to the current
directory includes a cross-device symlink. If I cd following the link,
then this effect doesn't happen. Weird.
Huh. So maybe a gmake bug, or maybe there's som
Andrew Dunstan writes:
> This seems totally stupid, but it happens when the path to the current
> directory includes a cross-device symlink. If I cd following the link,
> then this effect doesn't happen. Weird.
Huh. So maybe a gmake bug, or maybe there's something wrong with our
make rules for
On 09/07/2012 10:46 PM, Andrew Dunstan wrote:
On 09/07/2012 09:55 PM, Andrew Dunstan wrote:
On 09/07/2012 08:43 PM, Tom Lane wrote:
Andrew Dunstan writes:
Well, it looks like it's always failing on ecpg, with preproc.h not
being made in the right order. Here is the last bit of a make log
s
On 09/07/2012 09:55 PM, Andrew Dunstan wrote:
On 09/07/2012 08:43 PM, Tom Lane wrote:
Andrew Dunstan writes:
Well, it looks like it's always failing on ecpg, with preproc.h not
being made in the right order. Here is the last bit of a make log
starting from when it starts on ecpg. This is pre
On 09/07/2012 08:43 PM, Tom Lane wrote:
Andrew Dunstan writes:
Well, it looks like it's always failing on ecpg, with preproc.h not
being made in the right order. Here is the last bit of a make log
starting from when it starts on ecpg. This is pretty repeatable.
Hmph. I can't reproduce it at
Andrew Dunstan writes:
> Well, it looks like it's always failing on ecpg, with preproc.h not
> being made in the right order. Here is the last bit of a make log
> starting from when it starts on ecpg. This is pretty repeatable.
Hmph. I can't reproduce it at all on my Fedora 16 box. What versi
On 09/04/2012 08:51 PM, Andrew Dunstan wrote:
On 09/04/2012 08:37 PM, Tom Lane wrote:
Andrew Dunstan writes:
Frankly, I have had enough 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 thr
On 09/04/2012 08:37 PM, Tom Lane wrote:
Andrew Dunstan writes:
Frankly, I have had enough 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
Andrew Dunstan writes:
> Frankly, I have had enough 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 would advance us
On Sep 4, 2012 6:06 PM, "Andrew Dunstan" wrote:
>
>
> Frankly, I have had enough 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 t
On 09/04/2012 05:49 PM, Peter Eisentraut wrote:
On 9/1/12 12:12 PM, Robert Creager wrote:
I change the build-farm.conf file to have the following make line:
make => 'make -j 8', # or gmake if required. can include path if
necessary.
2 pass, 4 fail. Is this a build configuration you want
Excerpts from Peter Eisentraut's message of mar sep 04 18:49:46 -0300 2012:
> On 9/1/12 12:12 PM, Robert Creager wrote:
> >
> > I change the build-farm.conf file to have the following make line:
> >
> > make => 'make -j 8', # or gmake if required. can include path if
> > necessary.
> >
> > 2
On 9/1/12 12:12 PM, Robert Creager wrote:
>
> I change the build-farm.conf file to have the following make line:
>
> make => 'make -j 8', # or gmake if required. can include path if
> necessary.
>
> 2 pass, 4 fail. Is this a build configuration you want to pursue?
Sure that would be useful
Excerpts from Robert Creager's message of sáb sep 01 12:12:51 -0400 2012:
>
> I change the build-farm.conf file to have the following make line:
>
> make => 'make -j 8', # or gmake if required. can include path if
> necessary.
>
> 2 pass, 4 fail. Is this a build configuration you want to p
I change the build-farm.conf file to have the following make line:
make => 'make -j 8', # or gmake if required. can include path if necessary.
2 pass, 4 fail. Is this a build configuration you want to pursue? I can
either create a new machine, or change one of my existing machines. Makes
38 matches
Mail list logo
