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
On 04/19/2011 11:53 AM, Kevin Grittner wrote:
Andrew Dunstanand...@dunslane.net wrote:
I think the best thing might be to add a new step which runs the
isolation check or installcheck. It would only need a small amount
of perl code adde3d to the client to accomplish, and nothing on
the
Andrew Dunstan and...@dunslane.net wrote:
http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=crakedt=2011-04-20%2010%3A17%3A02stg=isolation-check
On a cursory scan, that looks like a successful run of the right
test suite. Was there anything in particular I should be checking
there?
On 04/20/2011 09:54 AM, Kevin Grittner wrote:
Andrew Dunstanand...@dunslane.net wrote:
http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=crakedt=2011-04-20%2010%3A17%3A02stg=isolation-check
On a cursory scan, that looks like a successful run of the right
test suite. Was there
I'm not sure what the right thing is to do here.
Heikki added a new testing methodology under src/test/isolation
which allows intermingling a series of statements on multiple
connections in desired permutations. (By default each test defined
for it runs all permutations of how the statement
On 04/19/2011 11:16 AM, Kevin Grittner wrote:
I'm not sure what the right thing is to do here.
Heikki added a new testing methodology under src/test/isolation
which allows intermingling a series of statements on multiple
connections in desired permutations. (By default each test defined
for
Andrew Dunstan and...@dunslane.net wrote:
I think the best thing might be to add a new step which runs the
isolation check or installcheck. It would only need a small amount
of perl code adde3d to the client to accomplish, and nothing on
the server side.
Since I'm unskilled at perl and
Excerpts from Kevin Grittner's message of mar abr 19 12:53:07 -0300 2011:
Since I'm unskilled at perl and have never looked at the buildfarm
scripts, could someone with the appropriate skills and knowledge add
this for me? In bash, when I'm in the normal base directory for a
build from
It took a little longer than expected, due to a slightly clagged network
between the old and new servers, but the database migration is complete
and the server is back up and running.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
I mentioned earlier that buildfarm member jaguar (that's the one that
builds with CLOBBER_CACHE_ALWAYS) was showing suspicious intermittent
failures.
Tom, this brings up another question: is there any
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
I mentioned earlier that buildfarm member jaguar (that's the one that
builds with CLOBBER_CACHE_ALWAYS) was showing suspicious intermittent
failures.
Tom, this brings up another question: is there any flag, environment,
forced resource
dugong (icc on ia64) has been failing the contrib installcheck consistently
since 6 days ago with errors like:
ERROR: could not fsync segment 0 of relation 1663/40960/41403: No such file or
directory
I checked a cvs diff between the two timestamps and that's precisely when the
self-adjusting
Gregory Stark [EMAIL PROTECTED] writes:
dugong (icc on ia64) has been failing the contrib installcheck consistently
since 6 days ago with errors like:
ERROR: could not fsync segment 0 of relation 1663/40960/41403: No such file
or directory
I checked a cvs diff between the two timestamps
Gregory Stark [EMAIL PROTECTED] writes:
dugong (icc on ia64) has been failing the contrib installcheck consistently
since 6 days ago with errors like:
ERROR: could not fsync segment 0 of relation 1663/40960/41403: No such file
or directory
Yeah, I already asked Sergey about this but I guess
Gregory Stark [EMAIL PROTECTED] writes:
And given the consistency and the fact that the other icc machines
didn't show the same problems it sounds like it's something about that
machine, not a software problem.
Well, we haven't *got* any other icc-on-ia64 machines AFAICS, so it
could easily be
On Tue, 2 Oct 2007, Gregory Stark wrote:
(we don't seem to have a recent icc ia32 build farm member).
Sorry about that, my buildfarm member (mongoose) is down with hardware
problems, and probably will be for the forseeable future. For some
reason, it suddenly decided to stop recognizing its
Hi,
we have two build farm members failing to make since I committed teh
ecpg changes: echidna and herring.
It looks like they are still using an old preproc.c although they
checked out the new preproc.y. I have no idea how this is supposed to
work so could someone please enlighten me?
Michael
Michael Meskes wrote:
Hi,
we have two build farm members failing to make since I committed teh
ecpg changes: echidna and herring.
It looks like they are still using an old preproc.c although they
checked out the new preproc.y. I have no idea how this is supposed to
work so could someone
Darcy Buskermolen wrote:
This sort of thing is usually a
symptom of somebody having run a build in the repo directly, a thing
that buildfarm owners have been repeatedly advised not to do.
This is something I do not recall doing, however it's possible. though this
does make me ask why
On Thursday 16 August 2007 04:29:41 Andrew Dunstan wrote:
Michael Meskes wrote:
Hi,
we have two build farm members failing to make since I committed teh
ecpg changes: echidna and herring.
It looks like they are still using an old preproc.c although they
checked out the new
Andrew Dunstan wrote:
Darcy Buskermolen wrote:
This sort of thing is usually a
symptom of somebody having run a build in the repo directly, a thing
that buildfarm owners have been repeatedly advised not to do.
This is something I do not recall doing, however it's possible. though
Alvaro Herrera wrote:
Andrew Dunstan wrote:
Darcy Buskermolen wrote:
This sort of thing is usually a
symptom of somebody having run a build in the repo directly, a thing
that buildfarm owners have been repeatedly advised not to do.
This is something I do not recall
On Thu, Aug 16, 2007 at 08:24:14AM -0700, Darcy Buskermolen wrote:
This is something I do not recall doing, however it's possible. though this
does make me ask why are the build dependencies in the Makefile are not
properly setup to tell that the .y needs to be rebuilt (which I would assume
Michael Meskes wrote:
The backend has:
$(srcdir)/gram.c: $(srcdir)/parse.h ;
$(srcdir)/parse.h: gram.y
So except for the different naming it's the same. However, we haven't
had that problem with the backend so far, or did we?
What do I fail to see?
We have had problems in the past.
Andrew Dunstan wrote:
Michael Meskes wrote:
The backend has:
$(srcdir)/gram.c: $(srcdir)/parse.h ;
$(srcdir)/parse.h: gram.y
So except for the different naming it's the same. However, we haven't
had that problem with the backend so far, or did we?
What do I fail to see?
We have had
Alvaro Herrera wrote:
How do you create the copy of the repo to build? One idea would be to
explicitely skip files that appear on .cvsignore (and maybe croak about
them).
We are supposed to croak - see
Hi all,
I'm the administrator of that machine and PLCheck is failing.
Is there anything I can do to fix it ?
Regards
Gaetano Mendola
---(end of broadcast)---
TIP 6: explain analyze is your friend
Gaetano Mendola [EMAIL PROTECTED] writes:
I'm the administrator of that machine and PLCheck is failing.
Is there anything I can do to fix it ?
What version of Python have you got on that thing? It seems to be
emitting still another spelling of the encoding error message :-(
Tom Lane wrote:
Gaetano Mendola [EMAIL PROTECTED] writes:
I'm the administrator of that machine and PLCheck is failing.
Is there anything I can do to fix it ?
What version of Python have you got on that thing? It seems to be
emitting still another spelling of the encoding error message :-(
On Mon, Oct 03, 2005 at 05:19:43PM +0200, Gaetano Mendola wrote:
Tom Lane wrote:
Gaetano Mendola [EMAIL PROTECTED] writes:
I'm the administrator of that machine and PLCheck is failing.
Is there anything I can do to fix it ?
What version of Python have you got on that thing? It seems
Michael Fuhr [EMAIL PROTECTED] writes:
On Mon, Oct 03, 2005 at 05:19:43PM +0200, Gaetano Mendola wrote:
What version of Python have you got on that thing? It seems to be
emitting still another spelling of the encoding error message :-(
$ python -V
Python 2.2.3
The attached variant file
It appears to be getting the wrong address for tsearch()
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x011b
0x9009a7c8 in tsearch ()
However if I set a break point for tsearch, I get
br tsearch
Breakpoint 5 at 0xe08c64: file
Dave Cramer [EMAIL PROTECTED] writes:
It appears to be getting the wrong address for tsearch()
I applied a patch for that earlier today. It seems that in OS X 10.4
the compiler generates a function with the same name as the shared
library, ie tsearch() for libtsearch ... and it doesn't tell you
Just a thought. You could also run the regression test automatically after a
successful build?
Andrew Dunstan [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Jean-Michel POURE wrote:
Le Vendredi 21 Novembre 2003 19:47, Tom Lane a écrit :
I think the main value of a build farm
Peter Eisentraut wrote:
Bruce Momjian writes:
FYI, the HP testdrive farm, http://www.testdrive.hp.com, has shared
directories for most of the machines, meaning you can CVS update once
and telnet in to compile for each platform.
Except that you can't open connections to the outside from
Bruce Momjian wrote:
FYI, the HP testdrive farm, http://www.testdrive.hp.com, has shared
directories for most of the machines, meaning you can CVS update once
and telnet in to compile for each platform.
As Peter pointed out, these machines are firewalled. But presumably one could upload a
Andrew Dunstan wrote:
Bruce Momjian wrote:
FYI, the HP testdrive farm, http://www.testdrive.hp.com, has shared
directories for most of the machines, meaning you can CVS update once
and telnet in to compile for each platform.
As Peter pointed out, these machines are firewalled. But
Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
FYI, the HP testdrive farm, http://www.testdrive.hp.com, has shared
directories for most of the machines, meaning you can CVS update once
and telnet in to compile for each platform.
As Peter pointed out, these
Le Vendredi 21 Novembre 2003 19:47, Tom Lane a crit :
I think the main value of a build farm is that we'd get nearly immediate
feedback about the majority of simple porting problems. Your previous
arguments that it wouldn't smoke everything out are certainly valid ---
but we wouldn't abandon
Jean-Michel POURE wrote:
Le Vendredi 21 Novembre 2003 19:47, Tom Lane a crit :
I think the main value of a build farm is that we'd get nearly immediate
feedback about the majority of simple porting problems. Your previous
arguments that it wouldn't smoke everything out are certainly valid
Andrew Dunstan wrote:
Jean-Michel POURE wrote:
Le Vendredi 21 Novembre 2003 19:47, Tom Lane a crit :
I think the main value of a build farm is that we'd get nearly
immediate
feedback about the majority of simple porting problems. Your previous
arguments that it wouldn't smoke everything
Le Lundi 24 Novembre 2003 16:38, Andreas Pflug a crit :
And a tiny correction: The farm member for win32 is my machine, and it's
operated manually :-)
Some GNU/Linux farm animals are living in my garage running on very old 50
euros machines ... Ancient farming :-)
By the way, we would love if
FYI, the HP testdrive farm, http://www.testdrive.hp.com, has shared
directories for most of the machines, meaning you can CVS update once
and telnet in to compile for each platform.
---
Andrew Dunstan wrote:
Tom Lane
On Wed, Nov 19, 2003 at 04:34:27PM +0100, Peter Eisentraut wrote:
Hence the open-source community approach. Closed-source development teams
can do all the above, with great effort. But by throwing out the code and
have real people test them on real systems with real applications, you can
do
Would it be reasonable to promote users testing daily snapshots with
popular applications? I'm guessing there's not many applications that
have automated test frameworks, but any that do would theoretically
provide another good test of PGSQL changes.
May I quote Joel on Software here?
Bruce Momjian writes:
FYI, the HP testdrive farm, http://www.testdrive.hp.com, has shared
directories for most of the machines, meaning you can CVS update once
and telnet in to compile for each platform.
Except that you can't open connections to the outside from these machines.
--
Peter
Peter Eisentraut [EMAIL PROTECTED] writes:
Andrew Dunstan writes:
Maybe it wouldn't be of great value to PostgreSQL. And maybe it would. I
have an open mind about it. I don't think incompleteness is an argument
against it, though.
If you want to do it, by all means go for it. I'm sure it
Tom Lane wrote:
I think the main value of a build farm is that we'd get nearly immediate
feedback about the majority of simple porting problems. Your previous
arguments that it wouldn't smoke everything out are certainly valid ---
but we wouldn't abandon the regression tests just because they
Peter Eisentraut wrote:
Andrew Dunstan writes:
Essentially what I have is something like this pseudocode:
cvs update
Be sure check past branches as well.
check if there really was an update and if not exit
OK.
configure; get config.log
Ideally, you'd try all
Andrew Dunstan writes:
If there's general interest I'll try to cook something up. (This kind of
stuff is right up my alley). I'd prefer some automated display of
results, though. A simple CGI script should be all that's required for
that.
The real problem will be to find enough machines so
Peter Eisentraut wrote:
Andrew Dunstan writes:
If there's general interest I'll try to cook something up. (This kind of
stuff is right up my alley). I'd prefer some automated display of
results, though. A simple CGI script should be all that's required for
that.
The real problem will
Andrew Dunstan writes:
Useful is probably subjective. That list would at least be a good
place to start, though. What combinations of variables do you think we
would need?
First of all, I don't necessarily think that a large list of CPU/operation
system combinations is going to help much.
Peter Eisentraut wrote:
Andrew Dunstan writes:
Useful is probably subjective. That list would at least be a good
place to start, though. What combinations of variables do you think we
would need?
First of all, I don't necessarily think that a large list of CPU/operation
system
Andrew Dunstan writes:
Maybe it wouldn't be of great value to PostgreSQL. And maybe it would. I
have an open mind about it. I don't think incompleteness is an argument
against it, though.
If you want to do it, by all means go for it. I'm sure it would give
everyone a fuzzy feeling to see the
Peter Eisentraut wrote:
The Samba build daemon suite is pretty good. We have a couple of those
hosts in our office in fact. (I think they're building PostgreSQL
regularly as well.) A tip: You might find that adopting the source code
of the Samba suite to PostgreSQL is harder than writing a new
Andrew Dunstan writes:
Essentially what I have is something like this pseudocode:
cvs update
Be sure check past branches as well.
check if there really was an update and if not exit
OK.
configure; get config.log
Ideally, you'd try all possible option combinations for configure.
Marc G. Fournier wrote:
On Tue, 18 Nov 2003, Andrew Dunstan wrote:
Maybe some sort of automated distributed build farm would be a good
idea. Check out http://build.samba.org/about.html to see how samba does
it (much lighter than the Mozilla tinderbox approach).
We wouldn't need to be as
On Tue, 2003-11-18 at 14:36, Andrew Dunstan wrote:
Marc G. Fournier wrote:
On Tue, 18 Nov 2003, Andrew Dunstan wrote:
Maybe some sort of automated distributed build farm would be a good
idea. Check out http://build.samba.org/about.html to see how samba does
it (much lighter than the
Robert Treat wrote:
Check the archives on this, as its been hashed out already once at least
... I think the big issue/problem is that nobody seems able (or wants) to
come up with a script that could be setup in cron on machines to do this
... something simple that would dump the output to
96 matches
Mail list logo
