Cleaning up some remarkably old stuff in installation.sgml - Mailing list pgsql-docs

While poking at the configure options list, I noticed that there
is some other text in installation.sgml that is long past its
sell-by date.  For instance, the first para in install-requirements
points to standalone FAQ documents that we removed back in 8.4.
I don't think we need to have blow-by-blow discussions of decades-old
AIX or HPUX bugs either; nor recommendations to use gcc 2.95.3 ;-).
The HPUX section actually seems totally unnecessary after removing
info that is obsolete or duplicative.

Proposed patch attached.

            regards, tom lane

diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml
index 4493862..ff98fe1 100644
--- a/doc/src/sgml/installation.sgml
+++ b/doc/src/sgml/installation.sgml
@@ -54,10 +54,11 @@ 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.  Modern versions of Windows are also supported, but this chapter
+   does not cover installation on
+   Windows<phrase condition="standalone-ignore"> (see
+   <xref linkend="install-windows"/>)</phrase>.
   </para>

   <para>
@@ -1986,175 +1987,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 +2161,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>
@@ -2411,94 +2248,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>

@@ -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>.
@@ -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>