Pgsql 7.3/7.4/8.0 on IA64 HP-UX 11i?

[Ed L.]

Has anyone successfully built 7.3.4, 7.4.3, or 8.0.0beta1 on
IA64 with HP-UX 11i v2 (11.23)? I'm not having any success,
running into 'make' failures. Googling old posts suggests
this might be due to missing test-and-set code for ia64?
I saw a disputed/repudiated ViSolve patch, but nothing else.
Is this still broken?

Here's my attempt on 8.0.0beta1:

$uname -a
HP-UX r1 B.11.23 U ia64 ...
$cc -V
(Bundled) cc: HP aC++/ANSI C B3910B A.05.50 [May 15 2003]
$make
....<snip>...
cc -Ae +O2 -I../../../../src/include -D_XOPEN_SOURCE_ EXTENDED -c -o xlog.o xlog.c
(Bundled) cc: warning 922: "-Ae" is unsupported in the bundled compiler, ignored.
(Bundled) cc: warning 922: "+O2" is unsupported in the bundled compiler, ignored.
Error 119: "../../../../src/include/storage/s_lock.h", line 654 # #error PostgreSQL does not have
native spinlock support on this platform. To continue the compilation, rerun configure using
--disable-spinlocks. However, performance will be poor. Please report this to
pg********@post gresql.org.
#error PostgreSQL does not have native spinlock support on this p
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^
Error 22: "../../../../src/include/storage/s_lock.h", line 711 # Syntax error.
extern int tas(volatile slock_t *lock); /* in port/.../tas.s, or
^
....<snip>...


---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddres sHere" to ma*******@postg resql.org)

[Ed L.]

On Monday August 16 2004 5:24, Ed L. wrote:

$make
...<snip>...
cc -Ae +O2 -I../../../../src/include -D_XOPEN_SOURCE_ EXTENDED -c -o
xlog.o xlog.c (Bundled) cc: warning 922: "-Ae" is unsupported in the
bundled compiler, ignored. (Bundled) cc: warning 922: "+O2" is
unsupported in the bundled compiler, ignored. Error 119:
"../../../../src/include/storage/s_lock.h", line 654 # #error PostgreSQL
does not have native spinlock support on this platform. To continue the
compilation, rerun configure using --disable-spinlocks. However,
performance will be poor. Please report this to
pg********@post gresql.org.
#error PostgreSQL does not have native spinlock support on this p
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^
Error 22: "../../../../src/include/storage/s_lock.h", line 711 # Syntax
error. extern int tas(volatile slock_t *lock); /* in
port/.../tas.s, or ^
...<snip>...

And I do see the --disable-spinlocks option, but was hoping for the build
with the "good" performance!

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddres sHere" to ma*******@postg resql.org)

[Tom Lane]

"Ed L." <pg***@bluepolk a.net> writes:

cc -Ae +O2 -I../../../../src/include -D_XOPEN_SOURCE_ EXTENDED -c -o xlog.o xlog.c
(Bundled) cc: warning 922: "-Ae" is unsupported in the bundled compiler, ignored.
(Bundled) cc: warning 922: "+O2" is unsupported in the bundled compiler, ignored.

You should hardly be worrying about spinlock performance when you are
using that toy non-optimizing compiler. Get a real compiler --- either
gcc or HP's extra-money compiler ...

Aside from being free, gcc has the advantage that the spinlock code
should work out-of-the-box. I don't think anyone's built a solution
for HP's compiler on IA64 yet.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddres sHere" to ma*******@postg resql.org)

[Bruce Momjian]

Ed L. wrote:

On Monday August 16 2004 5:24, Ed L. wrote:

$make
...<snip>...
cc -Ae +O2 -I../../../../src/include -D_XOPEN_SOURCE_ EXTENDED -c -o
xlog.o xlog.c (Bundled) cc: warning 922: "-Ae" is unsupported in the
bundled compiler, ignored. (Bundled) cc: warning 922: "+O2" is
unsupported in the bundled compiler, ignored. Error 119:
"../../../../src/include/storage/s_lock.h", line 654 # #error PostgreSQL
does not have native spinlock support on this platform. To continue the
compilation, rerun configure using --disable-spinlocks. However,
performance will be poor. Please report this to
pg********@post gresql.org.
#error PostgreSQL does not have native spinlock support on this p
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^
Error 22: "../../../../src/include/storage/s_lock.h", line 711 # Syntax
error. extern int tas(volatile slock_t *lock); /* in
port/.../tas.s, or ^
...<snip>...

And I do see the --disable-spinlocks option, but was hoping for the build
with the "good" performance!

Yep, it is the missing ia64 spinlock code. We have a gcc version but
obviously not one for your compiler, HP native cc. We need someone to
supply us one. If you can find an assembler guy, have them look at our
gcc version and see they can send us a patch.

--
Bruce Momjian | http://candle.pha.pa.us
pg***@candle.ph a.pa.us | [phone]
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

[Ed L.]

On Monday August 16 2004 5:44, Tom Lane wrote:

"Ed L." <pg***@bluepolk a.net> writes:

cc -Ae +O2 -I../../../../src/include -D_XOPEN_SOURCE_ EXTENDED -c -o
xlog.o xlog.c (Bundled) cc: warning 922: "-Ae" is unsupported in the
bundled compiler, ignored. (Bundled) cc: warning 922: "+O2" is
unsupported in the bundled compiler, ignored.

You should hardly be worrying about spinlock performance when you are
using that toy non-optimizing compiler. Get a real compiler --- either
gcc or HP's extra-money compiler ...

Aside from being free, gcc has the advantage that the spinlock code
should work out-of-the-box. I don't think anyone's built a solution
for HP's compiler on IA64 yet.

Thanks for the tip. I installed the following depots, exported CC=gcc, and
8.0.0beta1 built fine, no warnings or errors, and loads from 7.3.4 dump
just fine.

make-3.80-sd-11.22.depot.gz, bison-1.875-sd-11.22.depot.gz,
flex-2.5.4a-sd-11.00.depot.gz, gcc-3.3.2-sd-11.22.depot.gz

$psql -c "select version()"
version
-----------------------------------------------------------------------------
PostgreSQL 8.0.0beta1 on ia64-hp-hpux11.23, compiled by GCC gcc (GCC) 3.3.2
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

[Tom Lane]

"Ed L." <pg***@bluepolk a.net> writes:

Is gcc supposed to work for 7.3.4 on IA64 HP-UX 11.23 as well?

No, 7.4 is our first release that has any idea that HPUX can run on any
hardware but HPPA. If you're desperate you could try backporting this
7.4 fix:

2003-08-01 15:12 tgl

* configure, configure.in, src/backend/port/hpux/tas.c.template,
src/backend/port/tas/hpux.s, src/backend/port/tas/hpux_hppa.s,
src/include/port/hpux.h, src/include/storage/s_lock.h: Since HPUX
now exists for Itanium, we should decouple the assumption that
OS=hpux is the same as CPU=hppa. First steps at doing this. With
these patches, we still work on hppa with either gcc or HP's cc.
We might work on hpux/itanium with gcc, but I can't test it.
Definitely will not work on hpux/itanium with non-gcc compiler, for
lack of spinlock code.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[Ed L.]

On Tuesday August 17 2004 10:08, Tom Lane wrote:

"Ed L." <pg***@bluepolk a.net> writes:

Is gcc supposed to work for 7.3.4 on IA64 HP-UX 11.23 as well?

No, 7.4 is our first release that has any idea that HPUX can run on any
hardware but HPPA. If you're desperate you could try backporting this
7.4 fix:

OK, thx, I may give that a brief try before reconsidering upgrade.

On a related topic, while looking into oddities of an HP-UX iexpress bundle
install of pgsql that had ".../lib/hpux32" and ".../lib/hpux64"
directories, we noticed the following:

$ file `which psql`
/opt/pgsql/postgresql-8.0.0beta1/bin/psql: ELF-32 executable object file
- IA64

This is the same for *many* of the executables in /bin. Does this mean it
is a 32-bit executable? Does it also, therefore, mean that is not taking
advantage of the 64-bit hardware? If so, is there something special I need
to pass to pgsql's configure to get it to build 64-bit executables to fully
exploit this expensive hardware?

TIA.
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddres sHere" to ma*******@postg resql.org)

[Tom Lane]

"Ed L." <pg***@bluepolk a.net> writes:

$ file `which psql`
/opt/pgsql/postgresql-8.0.0beta1/bin/psql: ELF-32 executable object file
- IA64 This is the same for *many* of the executables in /bin. Does this mean it
is a 32-bit executable?
Looks like it to me.
Does it also, therefore, mean that is not taking
advantage of the 64-bit hardware? If so, is there something special I need
to pass to pgsql's configure to get it to build 64-bit executables to fully
exploit this expensive hardware?

I wouldn't panic. 99% of the value of a 64-bit box for database work
is that you can handle more than 4Gb worth of RAM for disk cache. Since
in Postgres's worldview most of the disk caching is supposed to be done
by the kernel, it really matters not whether the Postgres executables
think they are 32-bit or 64-bit. All you need is a 64-bit kernel.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[Ed L.]

On Tuesday August 17 2004 10:38, Tom Lane wrote:

"Ed L." <pg***@bluepolk a.net> writes:

$ file `which psql`
/opt/pgsql/postgresql-8.0.0beta1/bin/psql: ELF-32 executable object
file - IA64

This is the same for *many* of the executables in /bin. Does this mean
it is a 32-bit executable?

Looks like it to me.

Does it also, therefore, mean that is not taking
advantage of the 64-bit hardware? If so, is there something special I
need to pass to pgsql's configure to get it to build 64-bit executables
to fully exploit this expensive hardware?

I wouldn't panic. 99% of the value of a 64-bit box for database work
is that you can handle more than 4Gb worth of RAM for disk cache. Since
in Postgres's worldview most of the disk caching is supposed to be done
by the kernel, it really matters not whether the Postgres executables
think they are 32-bit or 64-bit. All you need is a 64-bit kernel.

The HPUX gurus on http://forums1.itrc.hp.com testify that kernel caches
above approximately 600MB are counter-productive to performance. But we
have 16GB of RAM we definitely want to utilize for caching. Therefore,
we've set the kernel cache to 500MB and now wish to dramatically increase
the size of the PostgreSQL DB cache to take advantage of this RAM, possibly
as large as 8GB for a single cluster.

The Pgsql build scripts are building 32-bit pgsql executables by default,
and thus I'm concerned I'm not going to take advantage of the available RAM
for DB caching.

How do I build 64-bit pgsql executables?
Any concerns about an 8GB shmmax setting?
Other thoughts?

Ed
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Ed L.]

On Tuesday September 28 2004 1:18, Tom Lane wrote:

"Ed L." <pg***@bluepolk a.net> writes:

I wouldn't panic. 99% of the value of a 64-bit box for database work
is that you can handle more than 4Gb worth of RAM for disk cache.
Since in Postgres's worldview most of the disk caching is supposed to
be done by the kernel, it really matters not whether the Postgres
executables think they are 32-bit or 64-bit. All you need is a 64-bit
kernel.

The HPUX gurus on http://forums1.itrc.hp.com testify that kernel caches
above approximately 600MB are counter-productive to performance.

Why? And why would you think that whatever effect is limiting the
performance would not also apply to Postgres?

Well, I'm hardly the guru here, but if I understood correctly, the
degradation is due to competition between vhand and the kernel buffer
cache, resulting in applications being unable to get needed memory back
from the kernel buffer cache in a timely fashion. Assuming it's
competition between the kernel buffer cache and vhand, it seems logical to
think that removing the buffer cache from the competition would allow pgsql
a free hand to manage its own, large cache free.

Here's a discussion link:

http://forums1.itrc.hp.com/service/f...hreadId=673998
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org