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
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
Peter Eisentraut pete...@gmx.net 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
On 09/09/2012 03:29 AM, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net 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
Andrew Dunstan and...@dunslane.net writes:
On 09/09/2012 03:29 AM, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net 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
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 Peter
Andrew Dunstan and...@dunslane.net 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
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
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
Andrew Dunstan and...@dunslane.net 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
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 it's
On Sun, 2012-09-09 at 14:57 -0400, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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?
Peter Eisentraut pete...@gmx.net 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
Peter Eisentraut pete...@gmx.net 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
On 09/09/2012 05:00 PM, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net 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
Andrew Dunstan and...@dunslane.net 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
On 09/08/2012 11:06 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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,
Andrew Dunstan and...@dunslane.net 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
Andrew Dunstan and...@dunslane.net 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
On 09/08/2012 04:54 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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
On 09/08/2012 04:46 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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
On 09/08/2012 04:52 PM, Andrew Dunstan wrote:
On 09/08/2012 04:46 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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
Andrew Dunstan and...@dunslane.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
On 09/08/2012 07:54 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.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
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
build,
On 09/04/2012 08:51 PM, Andrew Dunstan wrote:
On 09/04/2012 08:37 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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
Andrew Dunstan and...@dunslane.net 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
On 09/07/2012 08:43 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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
On 09/07/2012 09:55 PM, Andrew Dunstan wrote:
On 09/07/2012 08:43 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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 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 and...@dunslane.net 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
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
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 pursue?
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, but
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 pass, 4 fail.
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
On Sep 4, 2012 6:06 PM, Andrew Dunstan and...@dunslane.net 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
Andrew Dunstan and...@dunslane.net 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
On 09/04/2012 08:37 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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
38 matches
Mail list logo
