Re: [HACKERS] huia and moa versus old PG branches
On Tue, Aug 31, 2010 at 3:03 PM, Tom Lane wrote: > Dave Page writes: >> On Mon, Aug 30, 2010 at 3:50 AM, Tom Lane wrote: >>> moa, which is claimed on the buildfarm dashboard to be using gcc but is >>> actually using cc, hits the spinlock problem in 8.0 and 8.1 and the >>> BYTE_ORDER problem in 8.2. > >> Per above, moa is configured with --disable-spinlocks for 8.1/8.0. Is >> something else broken in the configure code - or am I missing the >> point of --disable-spinlocks? > > Hum ... you are right, there is something else broken there. It looks > like, on platforms where we have an out-of-line assembler file, we > attempt to assemble it whether or not --disable-spinlocks is selected > (because configure sets TAS anyway). > > This is clearly something we should fix, but I've got mixed feelings > about whether to back-patch it all the way, in view of the fact that > nobody complained before. If you would like to keep running moa with > --disable-spinlocks in the old branches, I'll do it. Personally I have no interest in Solaris - I'm just providing animals because I can. I'll do whatever makes most sense for the project. > However, it looks > like what you did amounts to --disable-spinlocks in *all* branches, > which is definitely not what we want to test. If you can fix the > buildfarm configuration so that that switch is really applied > selectively to just pre-8.2 branches, then I think it'd be good to make > that happen. If you can't, I think it'd be best to just drop the switch > and forget about pre-8.2 on moa. I did this already, based on other similar code in the default config file. My perl-fu is weak though - maybe screwed something up? # Add --disable-spinlocks on 8.1 and below if ($branch le 'REL8_1') { push(@{$conf{config_opts}},"--disable-spinlocks") } -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] huia and moa versus old PG branches
On Tue, Aug 31, 2010 at 2:51 PM, Tom Lane wrote: > Dave Page writes: >>> On Mon, Aug 30, 2010 at 3:50 AM, Tom Lane wrote: Also, although moa is actually green for 8.3, it's showing an initdb failure in 8.4 and up ("cache lookup failed for type 0" while processing system_views.sql). I'm betting this is some sort of over-aggressive-optimization problem, but it's hard to tell much from the buildfarm logs. Could you look into that and find out exactly where it's failing? > >> Looks like -xO4 caused this. -xO3 seems to be OK in a test. > > Hmm. I wonder whether -xO4 invokes something comparable to strict > aliasing optimizations. Does Sun Studio have anything corresponding to > -fno-strict-aliasing ? A quick Google gives: -xalias_level[=l] http://docs.sun.com/app/docs/doc/819-5265/bjaso?a=view -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] huia and moa versus old PG branches
Dave Page writes: > On Mon, Aug 30, 2010 at 3:50 AM, Tom Lane wrote: >> moa, which is claimed on the buildfarm dashboard to be using gcc but is >> actually using cc, hits the spinlock problem in 8.0 and 8.1 and the >> BYTE_ORDER problem in 8.2. > Per above, moa is configured with --disable-spinlocks for 8.1/8.0. Is > something else broken in the configure code - or am I missing the > point of --disable-spinlocks? Hum ... you are right, there is something else broken there. It looks like, on platforms where we have an out-of-line assembler file, we attempt to assemble it whether or not --disable-spinlocks is selected (because configure sets TAS anyway). This is clearly something we should fix, but I've got mixed feelings about whether to back-patch it all the way, in view of the fact that nobody complained before. If you would like to keep running moa with --disable-spinlocks in the old branches, I'll do it. However, it looks like what you did amounts to --disable-spinlocks in *all* branches, which is definitely not what we want to test. If you can fix the buildfarm configuration so that that switch is really applied selectively to just pre-8.2 branches, then I think it'd be good to make that happen. If you can't, I think it'd be best to just drop the switch and forget about pre-8.2 on moa. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] huia and moa versus old PG branches
Dave Page writes: >> On Mon, Aug 30, 2010 at 3:50 AM, Tom Lane wrote: >>> Also, although moa is actually green for 8.3, it's showing an initdb >>> failure in 8.4 and up ("cache lookup failed for type 0" while processing >>> system_views.sql). I'm betting this is some sort of >>> over-aggressive-optimization problem, but it's hard to tell much from >>> the buildfarm logs. Could you look into that and find out exactly where >>> it's failing? > Looks like -xO4 caused this. -xO3 seems to be OK in a test. Hmm. I wonder whether -xO4 invokes something comparable to strict aliasing optimizations. Does Sun Studio have anything corresponding to -fno-strict-aliasing ? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] huia and moa versus old PG branches
On Tue, Aug 31, 2010 at 10:28 AM, Dave Page wrote: > On Mon, Aug 30, 2010 at 3:50 AM, Tom Lane wrote: >> Also, although moa is actually green for 8.3, it's showing an initdb >> failure in 8.4 and up ("cache lookup failed for type 0" while processing >> system_views.sql). I'm betting this is some sort of >> over-aggressive-optimization problem, but it's hard to tell much from >> the buildfarm logs. Could you look into that and find out exactly where >> it's failing? > > Yup. Thanks for the hint - I wasn't sure where to start with that one. Looks like -xO4 caused this. -xO3 seems to be OK in a test. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] huia and moa versus old PG branches
On Mon, Aug 30, 2010 at 3:50 AM, Tom Lane wrote: > The new buildfarm machines huia and moa aren't doing terribly well > with the older PG branches. This isn't really those machines' fault; > what I find after a bit of digging is that we just didn't have good > support for 64-bit Solaris until relatively recently. In particular: Yeah, sorry - been working on that but keep getting distracted. > * There was no 64-bit spinlock assembler code that worked with Sun's > compiler until 8.2. The first attempt to support it was here: > http://archives.postgresql.org/pgsql-committers/2005-12/msg00507.php > although that got whacked around quite a bit before 8.2 final. Right - that's why I'm using --disable-spinlocks for 8.0/8.1 on moa. Unfortunately, that doesn't seem to work either. > * gcc builds didn't fully work in 64-bit Solaris either until 8.3: > http://archives.postgresql.org/pgsql-committers/2007-01/msg00154.php > Before that patch, contrib didn't build because pgcrypto needs > BYTE_ORDER to be defined. OK. > huia, which is claimed on the buildfarm dashboard to be using Sun Studio > but is actually using gcc, thus fails at the contrib make stage before 8.3. . We had an issue with the keys which got switched around when these were setup - clearly it wasn't the keys, but the names. Andrew, can you swap the descriptions over please? > moa, which is claimed on the buildfarm dashboard to be using gcc but is > actually using cc, hits the spinlock problem in 8.0 and 8.1 and the > BYTE_ORDER problem in 8.2. Per above, moa is configured with --disable-spinlocks for 8.1/8.0. Is something else broken in the configure code - or am I missing the point of --disable-spinlocks? This file was created by PostgreSQL configure 8.0.25, which was generated by GNU Autoconf 2.53. Invocation command line was $ ./configure --enable-cassert --enable-debug --enable-nls --enable-integer-datetimes \ --with-gssapi --with-pam --without-readline \ --enable-thread-safety --disable-spinlocks --prefix=/export/home/dpage/pgbuildfarm/moa/REL8_0_STABLE/inst \ --with-pgport=5688 > That BYTE_ORDER patch is pretty small and safe, so I think it would be > reasonable to back-patch it into 8.2 so that we have a uniform story > that 64-bit Solaris is supported in 8.2 and up. The spinlock changes > were significantly more invasive, so my feeling is we should not try to > back-patch them, but just turn off moa for pre-8.2 branches. OK, I'll disable moa for pre-8.2. > Also, although moa is actually green for 8.3, it's showing an initdb > failure in 8.4 and up ("cache lookup failed for type 0" while processing > system_views.sql). I'm betting this is some sort of > over-aggressive-optimization problem, but it's hard to tell much from > the buildfarm logs. Could you look into that and find out exactly where > it's failing? Yup. Thanks for the hint - I wasn't sure where to start with that one. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] huia and moa versus old PG branches
I wrote: > what I find after a bit of digging is that we just didn't have good > support for 64-bit Solaris until relatively recently. In particular: BTW, just for the record: it's Solaris on 64-bit Intel that's at issue. 64-bit Sparc support goes way back, as evidenced by the fact that protosciurus and castoroides are green back to 8.0. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] huia and moa versus old PG branches
The new buildfarm machines huia and moa aren't doing terribly well with the older PG branches. This isn't really those machines' fault; what I find after a bit of digging is that we just didn't have good support for 64-bit Solaris until relatively recently. In particular: * There was no 64-bit spinlock assembler code that worked with Sun's compiler until 8.2. The first attempt to support it was here: http://archives.postgresql.org/pgsql-committers/2005-12/msg00507.php although that got whacked around quite a bit before 8.2 final. * gcc builds didn't fully work in 64-bit Solaris either until 8.3: http://archives.postgresql.org/pgsql-committers/2007-01/msg00154.php Before that patch, contrib didn't build because pgcrypto needs BYTE_ORDER to be defined. huia, which is claimed on the buildfarm dashboard to be using Sun Studio but is actually using gcc, thus fails at the contrib make stage before 8.3. moa, which is claimed on the buildfarm dashboard to be using gcc but is actually using cc, hits the spinlock problem in 8.0 and 8.1 and the BYTE_ORDER problem in 8.2. That BYTE_ORDER patch is pretty small and safe, so I think it would be reasonable to back-patch it into 8.2 so that we have a uniform story that 64-bit Solaris is supported in 8.2 and up. The spinlock changes were significantly more invasive, so my feeling is we should not try to back-patch them, but just turn off moa for pre-8.2 branches. Also, although moa is actually green for 8.3, it's showing an initdb failure in 8.4 and up ("cache lookup failed for type 0" while processing system_views.sql). I'm betting this is some sort of over-aggressive-optimization problem, but it's hard to tell much from the buildfarm logs. Could you look into that and find out exactly where it's failing? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers