Re: 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

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

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:
> 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.

<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
--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

On Tue, Aug 31, 2010 at 10:28 AM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
> On Mon, Aug 30, 2010 at 3:50 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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

Dave Page <dpage(at)pgadmin(dot)org> writes:
>> On Mon, Aug 30, 2010 at 3:50 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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

Dave Page <dpage(at)pgadmin(dot)org> writes:
> On Mon, Aug 30, 2010 at 3:50 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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

On Tue, Aug 31, 2010 at 2:51 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Dave Page <dpage(at)pgadmin(dot)org> writes:
>>> On Mon, Aug 30, 2010 at 3:50 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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

On Tue, Aug 31, 2010 at 3:03 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Dave Page <dpage(at)pgadmin(dot)org> writes:
>> On Mon, Aug 30, 2010 at 3:50 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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