From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, ohp(at)pyrenet(dot)fr, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers list <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: cvs head initdb hangs on unixware |
Date: | 2008-12-10 21:40:47 |
Message-ID: | 4940375F.1070803@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Zdenek Kotala wrote:
> Tom Lane napsal(a):
>> ohp(at)pyrenet(dot)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.
>
>
Well, you're asking for a significant redesign for which I at least
don't have time. What is so hard about having six animals on one
machine. A number of people have such setups, including me.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2008-12-10 21:43:03 | Re: WIP: default values for function parameters |
Previous Message | Jeff Davis | 2008-12-10 21:35:33 | Re: PostgreSQL 8.3.4 reproducible crash |