Cleaning up some remarkably old stuff in installation.sgml
От | Tom Lane |
---|---|
Тема | Cleaning up some remarkably old stuff in installation.sgml |
Дата | |
Msg-id | 15538.1567042743@sss.pgh.pa.us обсуждение исходный текст |
Список | 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>
В списке pgsql-docs по дате отправления:
Предыдущее
От: Tom LaneДата:
Сообщение: Re: Can we bring some organization to the configure options list?