Skip to content

P
Postgres FD Implementation
Commit 63a14007 authored by Tom Lane's avatar Tom Lane
Browse files
Options

Updates from Giles Lean.

parent 776d9651
Show whitespace changes
Inline Side-by-side
Showing with 35 additions and 63 deletions
doc/FAQ_HPUX
View file @ 63a14007
=======================================================
Frequently Asked Questions (FAQ) for PostgreSQL 7.1
Frequently Asked Questions (FAQ) for PostgreSQL 7.3
HP-UX Specific
TO BE READ IN CONJUNCTION WITH THE NORMAL FAQ
=======================================================
last updated: $Date: 2002/10/22 13:46:59 $
last updated: $Date: 2002/11/02 00:46:23 $
current maintainer: Tom Lane (tgl@sss.pgh.pa.us)
original author: Tom Lane (tgl@sss.pgh.pa.us)
......@@ -12,10 +12,7 @@ original author: Tom Lane (tgl@sss.pgh.pa.us)
Questions covered here:
1.1) What do I need to install PostgreSQL on HP-UX?
1.2) Anything special about the build/install procedure?
1.3) yacc dies trying to process src/backend/parser/gram.y.
1.4) Linking the main postgres executable fails, complaining that
there's no "alloca" function.
1.5) OK, it seemed to build and install, but the regression test fails.
1.3) OK, it seemed to build and install, but the regression test fails.
----------------------------------------------------------------------
......@@ -24,30 +21,27 @@ Section 1: Installing PostgreSQL
1.1) What do I need to install PostgreSQL on HP-UX?
PostgreSQL 7.1 should work on Series 700/800 machines running HPUX 9.*,
10.*, or 11.*, given appropriate system patch levels and build tools.
At least one developer routinely tests on HPUX 10.20, and we have reports
of successful install on HPUX 11. Releases before 7.1 were tested on
HPUX 9.03 and 9.05; 7.1 should still work there although no recent tests
have been reported.
PostgreSQL 7.3 should work on Series 700/800 PA-RISC machines running
HP-UX 10.X or 11.X, given appropriate system patch levels and build
tools. At least one developer routinely tests on HPUX 10.20 and we
have reports of successful installations on HPUX 11.00 and 11.11.
Aside from the PostgreSQL source distribution, you will need GNU make
(HP's make will not do), and either GNU gcc or HP's full ANSI C compiler.
If you intend to build from CVS sources rather than a distribution tarball,
you will also need flex (GNU lex) and bison (GNU yacc).
I'd also recommend making sure you are fairly up-to-date on HP patches,
particularly if you are using HPUX 9. At a minimum, if you are on HPUX 9,
you *must* have PHSS_4630 (libm update) or a successor patch; otherwise
Postgres' date/time functions will misbehave. On general principles you
should be current on libc and ld/dld patches, as well as compiler patches
if you are using HP's C compiler. (The only other presently known failure
from out-of-date system libraries is that on HPUX 10.10, the backend will
crash after the second error message in a session unless you have upgraded
libc to PHCO_16722 or later.)
I'd also recommend making sure you are fairly up-to-date on HP
patches. At a minimum, if you are building 64 bit binaries on on HPUX
11.11 you may need PHSS_26263 (11.11) or a successor patch otherwise
initdb may hang:
See HP's support websites, such as http://us-support.external.hp.com/,
for free copies of their latest patches.
PHSS_26263 s700_800 11.11 ld(1) and linker tools cumulative patch
On general principles you should be current on libc and ld/dld
patches, as well as compiler patches if you are using HP's C compiler.
See HP's support sites such as http://itrc.hp.com and
ftp://us-ffs.external.hp.com/ for free copies of their latest patches.
1.2) Anything special about the build/install procedure?
......@@ -64,51 +58,29 @@ The default install target location is /usr/local/pgsql, which
you might want to change to something under /opt. If so, use
the --prefix switch to configure.
1.3) yacc dies trying to process src/backend/parser/gram.y.
HP's yacc doesn't create its tables large enough to handle the Postgres
grammar (a lot of other vendors' yaccs have this problem too). The
preferred solution is to use GNU bison instead. If you don't want to
do that for some reason, it's possible to increase yacc's table sizes
enough to cope. With a pre-6.4 PostgreSQL grammar, I was able to get
HPUX 9's yacc to work by setting YFLAGS to
-d -Np2000 -Ns3000 -Nm100000 -Nl2000 -Na30000 -Nc10000
(You can edit YFLAGS either in the template file before running
configure, or in src/Makefile.global afterwards.) Later PostgreSQL
releases might require even larger tables, but this should do for
a starting point.
Note that this shouldn't affect you if you are using a distribution
tarball, but it does matter if you pull the sources from the CVS server.
The CVS server does not store prebuilt yacc output files.
If you are building on a PA-RISC 2.0 machine and want the compiled
binaries to run on PA-RISC 1.1 machines you will need to specify
+DAportable in CFLAGS.
1.4) Linking the main postgres executable fails, complaining that
there's no "alloca" function.
You're using an old version of GNU bison. Update to 1.50 or later,
and re-make the bison output files. Or build with gcc, or update to
HPUX 10, either of which will provide support for alloca.
1.5) OK, it seemed to build and install, but the regression test fails.
1.3) OK, it seemed to build and install, but the regression test fails.
There are several "expected failures" due to differences between HPUX
and the regression test reference platform used by the PostgreSQL group.
All of these should be compensated for by the regression test comparison
mechanism, with the possible exception of some low-order-digit differences
in the geometry tests (depending on which compiler and math library
versions you use).
and the regression test reference platform used by the PostgreSQL
group. All of these should be compensated for by the regression test
comparison mechanism, with the possible exception of some
low-order-digit differences in the geometry tests, which vary depending
on which compiler and math library versions you use.
Any other error is cause for suspicion. In particular, if you see
failures in the datetime test on HPUX 9, you probably forgot to
install the libm patch PHSS_4630 --- see item 1.1 above.
Any other error is cause for suspicion.
The parallel regression test script (gmake check) is known to lock up
when run under HP's default Bourne shell, at least in HPUX 10.20. This
appears to be a shell bug, not the fault of the script. If you see that
the tests have stopped making progress and only a shell process is
consuming CPU, kill the shell and start over with
when run under HP's Bourne shells: /usr/bin/sh and /sbin/sh. This is a
known defect JAGad84609, the fix for which is not yet in any released
HP-UX version or shell patches. To work around it, use ksh to run the
regression script:
gmake SHELL=/bin/ksh check
to use ksh instead.
If you see that the tests have stopped making progress and only a shell
process is consuming CPU, kill the shell process and start over with the
above command.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment