Re: Buildfarm coverage (was Re: [HACKERS] OK, ready for RC1 or Beta6)
On Fri, Dec 03, 2004 at 09:37:42PM +0100, Peter Eisentraut wrote: > > Once RC1 is out and the build farm has picked it up, we should start > filling out our little table with the build farm results and then look > for ways to fill the holes. Does the build farm turn on all the > compiler options? It really should. I'm looking for > > /configure --prefix=SOMEWHERE --enable-thread-safety --with-tcl \ > --with-perl --with-python --with-krb5 --with-pam -with-openssl I actually run panda (x86_64/amd64) with those options together with --enable-nls and --enable-integer-datetimes. I based my options on the debian postgresql package. Kurt ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: Buildfarm coverage (was Re: [HACKERS] OK, ready for RC1 or Beta6)
Travis P <[EMAIL PROTECTED]> writes: > You'll probably find multi-OS-testing (various versions of AIX, Linux, > MacOS X on PPC and/or PowerPC) much more important than differentiating > particular pieces of hardware in the PPC or RS6000 category, assuming > both 32-bit and 64-bit is covered and also that SMP tests are made. Agreed. > Does 'make check' test SMP? Yes; not very hard, but it will usually catch bad problems, especially over the long haul of many retries. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: Buildfarm coverage (was Re: [HACKERS] OK, ready for RC1 or Beta6)
On Dec 3, 2004, at 2:33 PM, Kenneth Marshall wrote: On Fri, Dec 03, 2004 at 03:20:48PM -0500, Tom Lane wrote: PPC tested pretty often by moi RS6000 isn't this same as PPC? This is the IBM Power4 and now Power5 architecture which is different from the PowerPC. Yeah, it's confusing. I believe that Power3 (also known as PowerPC 630), Power4, and Power5 satisfy the requirements of being both Power architecture and PowerPC architecture processors. Not all PowerPC processors are Power processors. I believe that all modern Power processors are PowerPC processors (the Power2 "P2SC" was the last non-PowerPC Power processor, IIRC). IBM's Power architecture has architectural features for Server systems (with a capital S there) that PowerPC for workstations (Apple) and embedded (Moto/IBM) shouldn't be required to have, and is also IBM's own solely-owned branding. Hence the differentiation. That's what I've pieced together anyway. You'll probably find multi-OS-testing (various versions of AIX, Linux, MacOS X on PPC and/or PowerPC) much more important than differentiating particular pieces of hardware in the PPC or RS6000 category, assuming both 32-bit and 64-bit is covered and also that SMP tests are made. Does 'make check' test SMP? -Travis ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: Buildfarm coverage (was Re: [HACKERS] OK, ready for RC1 or Beta6)
"Jim Buttafuoco" <[EMAIL PROTECTED]> writes: > I have setup the following running debian linux. MIPS, MIPSEL, ALPHA, > PARISC, M68K, ARM, SPARC, I386. I have the build farm running local > and I have just started to get the systems registered. Excellent, that's very good news. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: Buildfarm coverage (was Re: [HACKERS] OK, ready for RC1 or Beta6)
Andrew Dunstan <[EMAIL PROTECTED]> writes: > The configuration is chosen in the config file for each member, rather > than being dictated centrally. This is good. Now what we need is a little cooperation among the buildfarm team to make sure that the collective set of cases tested covers all the interesting combinations of configure flags, as per my followup ... > A single member can run more than one branch, and per-branch config can > be set up. A single machine can run more than one farm member (e.g. to > use different compilers). Yeah, on platforms where there's a non-gcc vendor compiler, testing with the vendor compiler is very interesting. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: Buildfarm coverage (was Re: [HACKERS] OK, ready for RC1 or Beta6)
Peter Eisentraut wrote: Tom Lane wrote: Where the buildfarm falls down a bit is on the cross-product coverage. But I think you're not going to get the cross product without a call for port reports; there aren't that many people who are going to offer dedicated time on every random platform there is. Once RC1 is out and the build farm has picked it up, we should start filling out our little table with the build farm results and then look for ways to fill the holes. Does the build farm turn on all the compiler options? It really should. I'm looking for /configure --prefix=SOMEWHERE --enable-thread-safety --with-tcl \ --with-perl --with-python --with-krb5 --with-pam -with-openssl make make install make check I know you're busy, but please take a few moments to check out how it works. The configuration is chosen in the config file for each member, rather than being dictated centrally. Every report (success and failure) shows the config settings. The only setting that buildfarm needs to set itself is --prefix which is chosen relative to another config file setting. Everything else is up to the farm member sysadmin to choose appropriately. A single member can run more than one branch, and per-branch config can be set up. A single machine can run more than one farm member (e.g. to use different compilers). In addition to the steps above, we do the following: initdb pg_ctl start make installcheck make contrib make contrib::installcheck pg_ctl stop The worth of these extra steps has already been shown - a number of bugs of unknown age and provenance have been fixed, especially in contrib. It is possible to run the buildfarm yourself without even being registered on www.pgbuildfarm.org - the script has a --nosend option which means it doesn't try to upload its results to the server. I encourage anyone interested in running buildfarm to try this option first. cheers andrew ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: Buildfarm coverage (was Re: [HACKERS] OK, ready for RC1 or Beta6)
Tom/all, I have setup the following running debian linux. MIPS, MIPSEL, ALPHA, PARISC, M68K, ARM, SPARC, I386. I have the build farm running local and I have just started to get the systems registered. I am also willing to aquire other hardware/ operating systems in an effort to give something back to the Postgresql community Jim -- Original Message --- From: Tom Lane <[EMAIL PROTECTED]> To: "Joshua D. Drake" <[EMAIL PROTECTED]> Cc: PostgreSQL-development <[EMAIL PROTECTED]> Sent: Fri, 03 Dec 2004 15:20:48 -0500 Subject: Buildfarm coverage (was Re: [HACKERS] OK, ready for RC1 or Beta6) > "Joshua D. Drake" <[EMAIL PROTECTED]> writes: > > 1. Buildfarm doesn't yet have that many platforms on it. > > It's not as bad as all that. Our current list of supported platforms > (ie, things that got tested last time) is > > AIX > Free/Open/NetBSDcovered by buildfarm > HPUXused daily by moi > IRIX > Linux covered by buildfarm > OS Xtested pretty often by moi > Solaris covered by buildfarm > Tru64 > UnixWare > Windows/Cygwin covered by buildfarm > > With respect to hardware it's > > x86 covered by buildfarm > ia64 > x86_64 covered by buildfarm > ARM > Alpha > MIPScovered by buildfarm > m68k > PA-RISC used daily by moi > PPC tested pretty often by moi > RS6000 isn't this same as PPC? > S/390 > Sparc covered by buildfarm > > Considering that we have both 32- and 64-bit, little- and big-endian > hardware in there, most of the basic hardware gotchas are covered; > the only thing I think is at much risk is the spinlock assembler code, > which we change seldom. > > Where the buildfarm falls down a bit is on the cross-product coverage. > But I think you're not going to get the cross product without a call for > port reports; there aren't that many people who are going to offer > dedicated time on every random platform there is. > > It would be nice to get an Alpha into the buildfarm, and PPC too. > > regards, tom lane > > ---(end of broadcast)--- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to [EMAIL PROTECTED] so that your > message can get through to the mailing list cleanly --- End of Original Message --- ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: Buildfarm coverage (was Re: [HACKERS] OK, ready for RC1 or Beta6)
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Does the build farm turn on all the > compiler options? It really should. I'm looking for > /configure --prefix=SOMEWHERE --enable-thread-safety --with-tcl \ > --with-perl --with-python --with-krb5 --with-pam -with-openssl I was just thinking about what the buildfarm should do with configure options. IMHO it would be most useful if we could have it testing a variety of different combinations. For instance, that stupid mistake I made last night would only have been detected by testing the combination --with-openssl and *not* --enable-thread-safety. We obviously are not going to have enough machines to test every possible combination, let alone every combination on every platform, but maybe we could make sure that interesting option combinations appear at least once among the set of buildfarm machines. I think it would be useful to cover all 16 permutations of --enable-thread-safety --with-krb5 --with-pam -with-openssl if possible, since those potentially interact in libpq. The --with-tcl --with-perl --with-python switches are probably pretty independent of these, but we should have one or two buildfarm machines trying each language if possible. Other switches that should be getting used by some but not all machines: --enable-integer-datetimes --enable-nls --without-readline(just to make sure it builds) --without-zlib(ditto) Finally, while I think most of the platforms should use --enable-debug and --enable-cassert to aid in tracking down problems, there should be one machine building without these, just to catch silly mistakes. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: Buildfarm coverage (was Re: [HACKERS] OK, ready for RC1 or Beta6)
On Fri, Dec 03, 2004 at 03:20:48PM -0500, Tom Lane wrote: > "Joshua D. Drake" <[EMAIL PROTECTED]> writes: > > 1. Buildfarm doesn't yet have that many platforms on it. > > It's not as bad as all that. Our current list of supported platforms > (ie, things that got tested last time) is > > AIX > Free/Open/NetBSDcovered by buildfarm > HPUXused daily by moi > IRIX > Linux covered by buildfarm > OS Xtested pretty often by moi > Solaris covered by buildfarm > Tru64 > UnixWare > Windows/Cygwin covered by buildfarm > > With respect to hardware it's > > x86 covered by buildfarm > ia64 > x86_64 covered by buildfarm > ARM > Alpha > MIPScovered by buildfarm > m68k > PA-RISC used daily by moi > PPC tested pretty often by moi > RS6000 isn't this same as PPC? This is the IBM Power4 and now Power5 architecture which is different from the PowerPC. Ken ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: Buildfarm coverage (was Re: [HACKERS] OK, ready for RC1 or Beta6)
Tom Lane wrote: > Where the buildfarm falls down a bit is on the cross-product > coverage. But I think you're not going to get the cross product > without a call for port reports; there aren't that many people who > are going to offer dedicated time on every random platform there is. Once RC1 is out and the build farm has picked it up, we should start filling out our little table with the build farm results and then look for ways to fill the holes. Does the build farm turn on all the compiler options? It really should. I'm looking for /configure --prefix=SOMEWHERE --enable-thread-safety --with-tcl \ --with-perl --with-python --with-krb5 --with-pam -with-openssl make make install make check -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Buildfarm coverage (was Re: [HACKERS] OK, ready for RC1 or Beta6)
"Joshua D. Drake" <[EMAIL PROTECTED]> writes: > 1. Buildfarm doesn't yet have that many platforms on it. It's not as bad as all that. Our current list of supported platforms (ie, things that got tested last time) is AIX Free/Open/NetBSDcovered by buildfarm HPUXused daily by moi IRIX Linux covered by buildfarm OS Xtested pretty often by moi Solaris covered by buildfarm Tru64 UnixWare Windows/Cygwin covered by buildfarm With respect to hardware it's x86 covered by buildfarm ia64 x86_64 covered by buildfarm ARM Alpha MIPScovered by buildfarm m68k PA-RISC used daily by moi PPC tested pretty often by moi RS6000 isn't this same as PPC? S/390 Sparc covered by buildfarm Considering that we have both 32- and 64-bit, little- and big-endian hardware in there, most of the basic hardware gotchas are covered; the only thing I think is at much risk is the spinlock assembler code, which we change seldom. Where the buildfarm falls down a bit is on the cross-product coverage. But I think you're not going to get the cross product without a call for port reports; there aren't that many people who are going to offer dedicated time on every random platform there is. It would be nice to get an Alpha into the buildfarm, and PPC too. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
