]> granicus.if.org Git - postgresql/commitdiff
update
authorPeter Eisentraut <peter_e@gmx.net>
Wed, 4 Apr 2001 20:02:31 +0000 (20:02 +0000)
committerPeter Eisentraut <peter_e@gmx.net>
Wed, 4 Apr 2001 20:02:31 +0000 (20:02 +0000)
doc/FAQ_Solaris

index fd6d3f0387acb23df0b0919143d63b36fb2de6c2..6103e1475b99e6f92de4bcf3712794f34f6f106d 100644 (file)
@@ -1,9 +1,9 @@
 ============================================================
-Frequently Asked Questions (FAQ) for PostgreSQL  V7.1
+Frequently Asked Questions (FAQ) for PostgreSQL 7.1
 Sun Solaris specific
 to be read in conjunction with the installation instructions
 ============================================================
-last updated:        $Date: 2001/03/13 20:42:11 $
+last updated:        $Date: 2001/04/04 20:02:31 $
 
 current maintainer:  Marc Liyanage (liyanage@access.ch)
 original author:     Marc Liyanage (liyanage@access.ch)
@@ -13,6 +13,9 @@ Contents:
 
 1) What tools do I need to build and install PostgreSQL on Solaris?
 2) Why do I get problems when building with OpenSSL support?
+3) Why does configure complain about a failed test program?
+4) A bunch of regression tests fail in random, non-reproduceable
+   patterns.  What's wrong?
 
 
 1) What tools do I need to build and install PostgreSQL on Solaris?
@@ -48,3 +51,36 @@ We believe that this should be fixed by OpenSSL.
 
 The problem can be worked around by removing the inclusion of
 <crypt.h> in these four files.
+
+
+3) Why does configure complain about a failed test program?
+
+This is probably a case of the run-time linker being unable to find
+libz or some other non-standard library, such as libssl.  To point it
+to the right location, set the LD_LIBRARY_PATH environment variable,
+e.g.,
+
+LD_LIBRARY_PATH=/usr/local/lib:/usr/local/ssl/lib
+export LD_LIBRARY_PATH
+
+and restart configure.  You will also have to keep this setting
+whenever you run any of the installed PostgreSQL programs.
+
+In the future, consider installing the offending libraries so they
+provide their own "rpath".
+
+
+4) A bunch of regression tests fail in random, non-reproduceable
+   patterns.  What's wrong?
+
+A lot of users have reported that the parallel regression test suite
+causes a varying, unpredictable set of tests to fail, usually tests in
+the second half of the run.  The failure is usually a failure to
+connect to the server at all, or an abrupt loss of the connection.
+Invariably, these problems go away when the regression test suite is
+changed to use TCP/IP sockets instead of Unix domain sockets.  (Change
+line 163 of src/test/regress/pg_regress to match *solaris*; yes, there
+should be an easier way to do this.)  Since a number of users do not
+seem to have any problems with this at all, we do not claim that "Unix
+domain sockets are broken on Solaris", but feel free to draw your own
+conclusions, or better yet, share your insights with the rest of us.