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)
|
Список | 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 по дате отправления: