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