Re: Q: spinlock on Alpha? (PG7.0.2)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Q: spinlock on Alpha? (PG7.0.2)
Дата
Msg-id 995.970468587@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Q: spinlock on Alpha? (PG7.0.2)  ("Emils Klotins" <emils@grafton.lv>)
Ответы Re: Q: spinlock on Alpha? (PG7.0.2)  (Ryan Kirkpatrick <pgsql@rkirkpat.net>)
Список 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 по дате отправления:

Предыдущее
От: "Emils Klotins"
Дата:
Сообщение: Q: spinlock on Alpha? (PG7.0.2)
Следующее
От: Josh Berkus
Дата:
Сообщение: Concerns about the OID