diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml
index 449386243b28545148c01b4a82a361c02b44c463..31ed516ac28e32dfd59afff6c581e4d791a81fa5 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>