diff options
| -rw-r--r-- | doc/src/sgml/installation.sgml | 311 |
1 files changed, 28 insertions, 283 deletions
diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml index 449386243b2..31ed516ac28 100644 --- a/doc/src/sgml/installation.sgml +++ b/doc/src/sgml/installation.sgml @@ -18,9 +18,13 @@ documentation. See standalone-profile.xsl for details. <para> This chapter describes the installation of <productname>PostgreSQL</productname> using the source code - distribution. (If you are installing a pre-packaged distribution, + distribution. If you are installing a pre-packaged distribution, such as an RPM or Debian package, ignore this chapter - and read the packager's instructions instead.) + and read the packager's instructions instead. + Also, this chapter does not describe the preferred way to install + <productname>PostgreSQL</productname> on Microsoft + Windows<phrase condition="standalone-ignore"> (for that, see + <xref linkend="install-windows"/>)</phrase>. </para> <sect1 id="install-short"> @@ -54,10 +58,8 @@ su - postgres In general, a modern Unix-compatible platform should be able to run <productname>PostgreSQL</productname>. The platforms that had received specific testing at the - time of release are listed in <xref linkend="supported-platforms"/> - below. In the <filename>doc</filename> subdirectory of the distribution - there are several platform-specific <acronym>FAQ</acronym> documents you - might wish to consult if you are having trouble. + time of release are described in <xref linkend="supported-platforms"/> + below. </para> <para> @@ -1986,175 +1988,11 @@ export MANPATH </indexterm> <para> - PostgreSQL works on AIX, but getting it installed properly can be - challenging. AIX versions from 4.3.3 to 6.1 are considered supported. - You can use GCC or the native IBM compiler <command>xlc</command>. In - general, using recent versions of AIX and PostgreSQL helps. Check - the build farm for up to date information about which versions of - AIX are known to work. + PostgreSQL works on AIX, but AIX versions before about 6.1 have + various issues and are not recommended. + You can use GCC or the native IBM compiler <command>xlc</command>. </para> - <para> - The minimum recommended fix levels for supported AIX versions are: - </para> - - <variablelist> - <varlistentry> - <term>AIX 4.3.3</term> - <listitem><para>Maintenance Level 11 + post ML11 bundle</para></listitem> - </varlistentry> - - <varlistentry> - <term>AIX 5.1</term> - <listitem><para>Maintenance Level 9 + post ML9 bundle</para></listitem> - </varlistentry> - - <varlistentry> - <term>AIX 5.2</term> - <listitem><para>Technology Level 10 Service Pack 3</para></listitem> - </varlistentry> - - <varlistentry> - <term>AIX 5.3</term> - <listitem><para>Technology Level 7</para></listitem> - </varlistentry> - - <varlistentry> - <term>AIX 6.1</term> - <listitem><para>Base Level</para></listitem> - </varlistentry> - </variablelist> - - <para> - To check your current fix level, use - <command>oslevel -r</command> in AIX 4.3.3 to AIX 5.2 ML 7, or - <command>oslevel -s</command> in later versions. - </para> - - <para> - Use the following <command>configure</command> flags in addition - to your own if you have installed Readline or libz in - <literal>/usr/local</literal>: - <literal>--with-includes=/usr/local/include - --with-libraries=/usr/local/lib</literal>. - </para> - - <sect3> - <title>GCC Issues</title> - - <para> - On AIX 5.3, there have been some problems getting PostgreSQL to - compile and run using GCC. - </para> - - <para> - You will want to use a version of GCC subsequent to 3.3.2, - particularly if you use a prepackaged version. We had good - success with 4.0.1. Problems with earlier versions seem to have - more to do with the way IBM packaged GCC than with actual issues - with GCC, so that if you compile GCC yourself, you might well - have success with an earlier version of GCC. - </para> - </sect3> - - <sect3> - <title>Unix-Domain Sockets Broken</title> - - <para> - AIX 5.3 has a problem - where <structname>sockaddr_storage</structname> is not defined to - be large enough. In version 5.3, IBM increased the size of - <structname>sockaddr_un</structname>, the address structure for - Unix-domain sockets, but did not correspondingly increase the - size of <structname>sockaddr_storage</structname>. The result of - this is that attempts to use Unix-domain sockets with PostgreSQL - lead to libpq overflowing the data structure. TCP/IP connections - work OK, but not Unix-domain sockets, which prevents the - regression tests from working. - </para> - - <para> - The problem was reported to IBM, and is recorded as bug report - PMR29657. If you upgrade to maintenance level 5300-03 or later, - that will include this fix. A quick workaround - is to alter <symbol>_SS_MAXSIZE</symbol> to 1025 in - <filename>/usr/include/sys/socket.h</filename>. In either case, - recompile PostgreSQL once you have the corrected header file. - </para> - </sect3> - - <sect3> - <title>Internet Address Issues</title> - - <para> - PostgreSQL relies on the system's <function>getaddrinfo</function> function - to parse IP addresses in <varname>listen_addresses</varname>, - <filename>pg_hba.conf</filename>, etc. Older versions of AIX have assorted - bugs in this function. If you have problems related to these settings, - updating to the appropriate AIX fix level shown above - should take care of it. - </para> - - <!-- https://archives.postgresql.org/message-id/6064jt6cfm.fsf_-_@dba2.int.libertyrms.com --> - - <para> - One user reports: - </para> - - <para> - When implementing PostgreSQL version 8.1 on AIX 5.3, we - periodically ran into problems where the statistics collector - would <quote>mysteriously</quote> not come up successfully. This - appears to be the result of unexpected behavior in the IPv6 - implementation. It looks like PostgreSQL and IPv6 do not play - very well together on AIX 5.3. - </para> - - <para> - Any of the following actions <quote>fix</quote> the problem. - <itemizedlist> - <listitem> - <para> - Delete the IPv6 address for localhost: -<screen> -(as root) -# ifconfig lo0 inet6 ::1/0 delete -</screen> - </para> - </listitem> - - <listitem> - <para> - Remove IPv6 from net services. The - file <filename>/etc/netsvc.conf</filename> on AIX is roughly - equivalent to <filename>/etc/nsswitch.conf</filename> on - Solaris/Linux. The default, on AIX, is thus: -<programlisting> -hosts=local,bind -</programlisting> - Replace this with: -<programlisting> -hosts=local4,bind4 -</programlisting> - to deactivate searching for IPv6 addresses. - </para> - </listitem> - </itemizedlist> - </para> - - <warning> - <para> - This is really a workaround for problems relating - to immaturity of IPv6 support, which improved visibly during the - course of AIX 5.3 releases. It has worked with AIX version 5.3, - but does not represent an elegant solution to the problem. It has - been reported that this workaround is not only unnecessary, but - causes problems on AIX 6.1, where IPv6 support has become more mature. - </para> - </warning> - - </sect3> - <sect3> <title>Memory Management</title> <!-- https://archives.postgresql.org/message-id/603bgqmpl9.fsf@dba2.int.libertyrms.com --> @@ -2324,9 +2162,9 @@ ERROR: could not load library "/opt/dbs/pgsql/lib/plperl.so": Bad address </para> <para> - When building from source, proceed according to the normal + When building from source, proceed according to the Unix-style installation procedure (i.e., <literal>./configure; - make</literal>; etc.), noting the following-Cygwin specific + make</literal>; etc.), noting the following Cygwin-specific differences: <itemizedlist> @@ -2378,7 +2216,7 @@ ERROR: could not load library "/opt/dbs/pgsql/lib/plperl.so": Bad address Building might fail on some systems where a locale other than C is in use. To fix this, set the locale to C by doing <command>export LANG=C.utf8</command> before building, and then - setting it back to the previous setting, after you have installed + setting it back to the previous setting after you have installed PostgreSQL. </para> </listitem> @@ -2395,7 +2233,7 @@ ERROR: could not load library "/opt/dbs/pgsql/lib/plperl.so": Bad address make MAX_CONNECTIONS=5 check </programlisting> (On some systems you can have up to about 10 simultaneous - connections). + connections.) </para> </listitem> </itemizedlist> @@ -2411,94 +2249,6 @@ make MAX_CONNECTIONS=5 check </para> </sect2> - <sect2 id="installation-notes-hpux"> - <title>HP-UX</title> - - <indexterm zone="installation-notes-hpux"> - <primary>HP-UX</primary> - <secondary>installation on</secondary> - </indexterm> - - <para> - 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 HP-UX - 10.20, and we have reports of successful installations on HP-UX - 11.00 and 11.11. - </para> - - <para> - Aside from the PostgreSQL source distribution, you will need GNU - make (HP's make will not do), and either GCC or HP's full ANSI C - compiler. If you intend to build from Git sources rather than a - distribution tarball, you will also need Flex (GNU lex) and Bison - (GNU yacc). We also recommend making sure you are fairly - up-to-date on HP patches. At a minimum, if you are building 64 - bit binaries on HP-UX 11.11 you may need PHSS_30966 (11.11) or a - successor patch otherwise <command>initdb</command> may hang: -<literallayout> -PHSS_30966 s700_800 ld(1) and linker tools cumulative patch -</literallayout> - - 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 <ulink url="ftp://us-ffs.external.hp.com/"></ulink> for free - copies of their latest patches. - </para> - - <para> - If you are building on a PA-RISC 2.0 machine and want to have - 64-bit binaries using GCC, you must use a GCC 64-bit version. - </para> - - <para> - 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 - <option>+DAportable</option> in <envar>CFLAGS</envar>. - </para> - - <para> - If you are building on a HP-UX Itanium machine, you will need the - latest HP ANSI C compiler with its dependent patch or successor - patches: -<literallayout> -PHSS_30848 s700_800 HP C Compiler (A.05.57) -PHSS_30849 s700_800 u2comp/be/plugin library Patch -</literallayout> - </para> - - <para> - If you have both HP's C compiler and GCC's, then you might want to - explicitly select the compiler to use when you - run <command>configure</command>: -<programlisting> -./configure CC=cc -</programlisting> - for HP's C compiler, or -<programlisting> -./configure CC=gcc -</programlisting> - for GCC. If you omit this setting, then configure will - pick <command>gcc</command> if it has a choice. - </para> - - <para> - The default install target location - is <filename>/usr/local/pgsql</filename>, which you might want to - change to something under <filename>/opt</filename>. If so, use - the - <option>--prefix</option> switch to <command>configure</command>. - </para> - - <para> - In the regression tests, there might be 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. - </para> - </sect2> - <sect2 id="installation-notes-macos"> <title>macOS</title> @@ -2562,12 +2312,12 @@ xcodebuild -version -sdk macosx Path PostgreSQL for Windows can be built using MinGW, a Unix-like build environment for Microsoft operating systems, or using Microsoft's <productname>Visual C++</productname> compiler suite. - The MinGW build variant uses the normal build system described in + The MinGW build procedure uses the normal build system described in this chapter; the Visual C++ build works completely differently and is described in <xref linkend="install-windows"/>. - It is a fully native build and uses no additional software like - MinGW. A ready-made installer is available on the main - PostgreSQL web site. + The Visual C++ build is recommended, as it is fully native and uses no + additional software like MinGW. A ready-made installer is available on + the main PostgreSQL web site. </para> <para> @@ -2624,8 +2374,7 @@ xcodebuild -version -sdk macosx Path <para> PostgreSQL is well-supported on Solaris. The more up to date your - operating system, the fewer issues you will experience; details - below. + operating system, the fewer issues you will experience. </para> <sect3> @@ -2634,8 +2383,7 @@ xcodebuild -version -sdk macosx Path <para> You can build with either GCC or Sun's compiler suite. For better code optimization, Sun's compiler is strongly recommended - on the SPARC architecture. We have heard reports of problems - when using GCC 2.95.1; GCC 2.95.3 or later is recommended. If + on the SPARC architecture. If you are using Sun's compiler, be careful not to select <filename>/usr/ucb/cc</filename>; use <filename>/opt/SUNWspro/bin/cc</filename>. @@ -2644,9 +2392,9 @@ xcodebuild -version -sdk macosx Path <para> You can download Sun Studio from <ulink url="https://www.oracle.com/technetwork/server-storage/solarisstudio/downloads/"></ulink>. - Many of GNU tools are integrated into Solaris 10, or they are - present on the Solaris companion CD. If you like packages for - older version of Solaris, you can find these tools + Many GNU tools are integrated into Solaris 10, or they are + present on the Solaris companion CD. If you need packages for + older versions of Solaris, you can find these tools at <ulink url="http://www.sunfreeware.com"></ulink>. If you prefer sources, look @@ -2682,18 +2430,15 @@ configure ... LDFLAGS="-R /usr/sfw/lib:/opt/sfw/lib:/usr/local/lib" flag to generate significantly faster binaries. Do not use any flags that modify behavior of floating-point operations and <varname>errno</varname> processing (e.g., - <option>-fast</option>). These flags could raise some - nonstandard PostgreSQL behavior for example in the date/time - computing. + <option>-fast</option>). </para> <para> If you do not have a reason to use 64-bit binaries on SPARC, prefer the 32-bit version. The 64-bit operations are slower and - 64-bit binaries are slower than the 32-bit variants. And on + 64-bit binaries are slower than the 32-bit variants. On the other hand, 32-bit code on the AMD64 CPU family is not native, - and that is why 32-bit code is significant slower on this CPU - family. + so 32-bit code is significantly slower on that CPU family. </para> </sect3> @@ -2718,7 +2463,7 @@ collect2: ld returned 1 exit status make: *** [postgres] Error 1 </screen> your DTrace installation is too old to handle probes in static - functions. You need Solaris 10u4 or newer. + functions. You need Solaris 10u4 or newer to use DTrace. </para> </sect3> </sect2> |