Re: Q: spinlock on Alpha? (PG7.0.2) - Mailing list pgsql-sql

From Tom Lane
Subject Re: Q: spinlock on Alpha? (PG7.0.2)
Date
Msg-id 995.970468587@sss.pgh.pa.us
Whole thread Raw
In response to Q: spinlock on Alpha? (PG7.0.2)  ("Emils Klotins" <emils@grafton.lv>)
Responses Re: Q: spinlock on Alpha? (PG7.0.2)
List pgsql-sql
"Emils Klotins" <emils@grafton.lv> writes:
> RedHat Linux 6.2 on Alphaserver DS10 (egcs-1.1.2, glibc-2.1.3, 
> libstdc++-2.9.0).
> Postgresql-7.0.2 source

> Compiles and installs just fine. However, both the regular initdb and 
> parallel regression testing's initdb stage fails with a core file and 
> message:

> FATAL: s_lock (2030d360) at spin.c:116, stuck spinlock. Aborting.
> FATAL: s_lock (2030d360) at spin.c:116, stuck spinlock. Aborting.

I was just fooling with PG on a RedHat Alpha box that DEC kindly
loaned to the project.  It looks like the above problem is caused
by compiler optimization; although src/template/linux_alpha
optimistically sets CFLAGS=-O2, I had to back off to -O1 to avoid
that same spinlock complaint, and I couldn't get 7.0.* to pass
regression tests with anything but -O0.  (And even there, there
were a bunch of failures in the datetime-related tests; it looks
like our abstime datatype breaks rather badly on this platform.)

I haven't had time yet to try current sources on that box, but
I'm optimistic that the new function manager will solve a lot of
portability problems on Alphas.  Still, I don't understand why -O2
breaks spinlocks --- maybe egcs is misoptimizing around the inline
assembly code of tas() ?
        regards, tom lane


pgsql-sql by date:

Previous
From: "Emils Klotins"
Date:
Subject: Q: spinlock on Alpha? (PG7.0.2)
Next
From: Josh Berkus
Date:
Subject: Concerns about the OID