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)

[Tom Lane]

"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?

regards, tom lane

---------------------------(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 Tuesday September 28 2004 1:12, Ed L. wrote:

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?

Well, for what it's worth, here's how I finally got postgresql 8.0.0beta3 to
build 64-bit executables on one HP-UX B.11.23 ia64 system using a gcc 3.4.2
depot-installed compiler (thanks to a prior patch from Shinji Teragaito).
All 96 regression tests passed.

export CC=gcc CFLAGS="-O2 -mlp64" LDFLAGS=-mlp64
../configure --without-readline --without-zlib

then apply attached patch.

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

http://archives.postgresql.org