On Mon, Aug 30, 2010 at 3:50 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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:
> 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:
> 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.
<grumble>. 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
--with-gssapi --with-pam --without-readline \
> 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.
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise Postgres Company
In response to
pgsql-hackers by date
|Next:||From: Dave Page||Date: 2010-08-31 10:21:25|
|Subject: Re: huia and moa versus old PG branches|
|Previous:||From: vamsi krishna||Date: 2010-08-31 08:38:57|
|Subject: Estimation of Plan quality|