Re: cvs head initdb hangs on unixware
От | Zdenek Kotala |
---|---|
Тема | Re: cvs head initdb hangs on unixware |
Дата | |
Msg-id | 493FFBE9.70403@sun.com обсуждение исходный текст |
Ответ на | Re: cvs head initdb hangs on unixware (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
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 |
Список | 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 по дате отправления: