Re: cvs head initdb hangs on unixware - Mailing list pgsql-hackers

From Zdenek Kotala
Subject Re: cvs head initdb hangs on unixware
Date
Msg-id 493FFBE9.70403@sun.com
Whole thread Raw
In response to Re: cvs head initdb hangs on unixware  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: cvs head initdb hangs on unixware
Re: cvs head initdb hangs on unixware
Re: cvs head initdb hangs on unixware
Re: cvs head initdb hangs on unixware
List pgsql-hackers
Tom Lane napsal(a):
> ohp@pyrenet.fr writes:
>> On Wed, 10 Dec 2008, Heikki Linnakangas wrote:
>>> BTW, why does this work on warthog buildfarm member? Different compiler 
>>> version?
>>>
>> it's configured with --enable-debug.
>> Maybe run_build.pl should run twice, onece with --enable-debug once 
>> without.
> 
> No, the standard way to deal with such issues is to set up two buildfarm
> members.  This would be a 100% waste of cycles for gcc-based members
> anyway, since gcc generates the same code with or without -g.  However,
> for compilers where it makes a difference, it might well be worth having
> an additional member to test the optimized build.

I think current infrastructures is not good for it. For example I would like to 
compile postgres on one machine with three different compiler and in 32 or 64 
mode. Should I have 6 animals? I think better idea is to have one animal and 
several test sets. Animals defines HW+OS version and test set specify PG 
version, configure switches, compiler and so on.
these are my two cents
    Zdenek


pgsql-hackers by date:

Previous
From: "Pavel Stehule"
Date:
Subject: Re: WIP: default values for function parameters
Next
From: Tom Lane
Date:
Subject: Re: cvs head initdb hangs on unixware