Thread: Pgsql 7.3/7.4/8.0 on IA64 HP-UX 11i?
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
pgsql-bugs@postgresql.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>...
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 > pgsql-bugs@postgresql.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!
"Ed L." <pgsql@bluepolka.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
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 > > pgsql-bugs@postgresql.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 pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
On Monday August 16 2004 5:44, Tom Lane wrote:
> "Ed L." <pgsql@bluepolka.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
"Ed L." <pgsql@bluepolka.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
On Tuesday August 17 2004 10:08, Tom Lane wrote: > "Ed L." <pgsql@bluepolka.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.
"Ed L." <pgsql@bluepolka.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
On Tuesday August 17 2004 10:38, Tom Lane wrote: > "Ed L." <pgsql@bluepolka.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
"Ed L." <pgsql@bluepolka.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
On Tuesday September 28 2004 1:18, Tom Lane wrote: > "Ed L." <pgsql@bluepolka.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/forums/questionanswer.do?admit=716493758+1096399563091+28353475&threadId=673998
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