=======================================================
-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)
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.
----------------------------------------------------------------------
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?
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.
projects / postgresql / commitdiff