Обсуждение: Re: [SQL] PostgreSQL on AIX

Поиск
Список
Период
Сортировка

Re: [SQL] PostgreSQL on AIX

От
"Zeugswetter Andreas SB SD"
Дата:
> Anyway, I am pretty sure that PostgreSQL is not the culprit here.  As it
> happens this project is back on the table for me so it is interesting that
> your email popped up now.  I just compiled the latest version of PostgreSQL
> on my AIX system and it generated lots of errors and then completed and
> installed fine.  Makes me sort of nervous.  We'll see how it goes.  Anyone
> have any horror/success stories about PostgreSQL on AIX for me?

The "errors" are mostly duplicate symbol warnings, that are part of generating
a shared lib on AIX (in a mostly gcc and xlc independent way), and can be safely
ignored.

The imho most needed effort for AIX would be to switch the TAS stuff from
cs() to fetch_and_or() or a PowerPC assembler or the test_and_set() that is
undocumented/intended for kernel, see discussions from last year.

The fetch_and_or() is a lot faster on multi processor systems but a little
slower on single processor. But cs() is documented as depricated, so ...

I might get round to doing this.

Andreas


Re: [SQL] PostgreSQL on AIX

От
Bruce Momjian
Дата:
Zeugswetter Andreas SB SD wrote:
> 
> > Anyway, I am pretty sure that PostgreSQL is not the culprit here.  As it 
> > happens this project is back on the table for me so it is interesting that 
> > your email popped up now.  I just compiled the latest version of PostgreSQL 
> > on my AIX system and it generated lots of errors and then completed and 
> > installed fine.  Makes me sort of nervous.  We'll see how it goes.  Anyone 
> > have any horror/success stories about PostgreSQL on AIX for me?
> 
> The "errors" are mostly duplicate symbol warnings, that are part of generating
> a shared lib on AIX (in a mostly gcc and xlc independent way), and can be safely
> ignored.
> 
> The imho most needed effort for AIX would be to switch the TAS stuff from
> cs() to fetch_and_or() or a PowerPC assembler or the test_and_set() that is 
> undocumented/intended for kernel, see discussions from last year.

Yes, TODO has:
* Evaluate AIX cs() spinlock macro for performance optimizations (Tatsuo)

> The fetch_and_or() is a lot faster on multi processor systems but a little
> slower on single processor. But cs() is documented as depricated, so ...

Should I update the TODO item?

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026