+++ /dev/null
-=======================================================
-Frequently Asked Questions (FAQ) for PostgreSQL
-AIX Specific
-TO BE READ IN CONJUNCTION WITH THE NORMAL FAQ
-=======================================================
-Last updated: $Date: 2007/10/09 01:28:24 $
-
-Topics
-
-- AIX 4.3.2 Port Report
-- AIX 5.3 Additional Information
-- AIX, readline, and postgres 8.1.x:
-- AIX Memory Management: An Overview
-- Statistics Collector Fun on AIX
-
------
-
-From: Zeugswetter Andreas <ZeugswetterA@spardat.at>
-$Date: 2007/10/09 01:28:24 $
-
-On AIX 4.3.2 PostgreSQL compiled with the native IBM compiler xlc
-(vac.C 5.0.1) passes all regression tests. Other versions of OS and
-compiler should also work. If you don't have a powerpc or use gcc you
-might see rounding differences in the geometry regression test.
-
-Use the following configure flags in addition to your own
-if you have readline or libz there:
---with-includes=/usr/local/include --with-libraries=/usr/local/lib
-
-There will probably be warnings about 0.0/0.0 division and duplicate
-symbols which you can safely ignore.
-
-Compiling PostgreSQL with gcc (2.95.3) on AIX also works.
-
-You need libm.a that is in the fileset bos.adt.libm. (Try the
-following command.)
-$ lslpp -l bos.adt.libm
-
-
----
-From: Christopher Browne <cbbrowne@ca.afilias.info>
-Date: 2005-07-15
-
-On AIX 5.3, there have been some problems getting PostgreSQL to
-compile and run using GCC.
-
-1. 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.
-
-2. AIX 5.3 has a problem where sockadr_storage is not defined to be
- large enough. In version 5.3, IBM increased the size of
- sockaddr_un, the address structure for UNIX Domain Sockets, but
- did not correspondingly increase the size of sockadr_storage.
-
- The result of this is that attempts to use UDS with PostgreSQL
- lead to libpq overflowing the data structure. TCP/IP connections
- work OK, but not UDS, which prevents the regression tests from
- working.
-
- The nonconformance may be readily demonstrated by compiling and
- running the following C program which calculates and compares the
- sizes of the various structures:
-
-test_size.c
-------------
-
----------- snip here - test_size.c ----------------------------
-#include <stdio.h>
-#include <sys/un.h>
-#include <sys/socket.h>
-int main (int argc, char *argv[]) {
- struct sockaddr_storage a;
- struct sockaddr_un b;
- printf("Size of sockadr_storage: %d\n", sizeof(a));
- printf ("Size of sockaddr_un:%d\n", sizeof(b));
-
- if (sizeof(a) >= sizeof(b))
- printf ("Conformant to RFC 3493\n");
- else
- printf ("Non-conformant to RFC 3493\n");
-}
----------- snip here - test_size.c ----------------------------
-
-
-The problem was reported to IBM, and is recorded as bug report
-PMR29657.
-
-An immediate resolution is to alter _SS_MAXSIZE to = 1025 in
-/usr/include/sys/socket.h, which will resolve the immediate problem.
-
-It appears that the "final" resolution will be to alter _SS_MAXSIZE to
-1280, making the size nicely align with page boundaries.
-
-IBM will be providing a fix in the next maintenance release (expected
-in October 2005) with an updated socket.h.
----
-PMR29657 was resolved in APAR IY74147: INCOMPATIBILITY BETWEEN
-SOCKADDR_UN AND SOCKADDR_STORAGE STRUCT
-
-APAR information
-APAR number IY74147
-Reported component name AIX 5.3
-Reported component ID 5765G0300
-Reported release 530
-Status CLOSED PER
-PE NoPE
-HIPER NoHIPER
-Submitted date 2005-07-18
-Closed date 2005-07-18
-Last modified date 2005-09-06
-
-If you upgrade to maintenance level 5300-03, that will include this
-fix. Use the command "oslevel -r" to determine what maintenance level
-you are at.
----
-From: Christopher Browne <cbbrowne@ca.afilias.info>
-Date: 2005-07-15
-
-Some of the AIX tools may be "a little different" from what you may be
-accustomed to on other platforms. If you are looking for a version of
-ldd, useful for determining what object code depends on what
-libraries, the following URLs may help you...
-
-http://www.faqs.org/faqs/aix-faq/part4/section-22.html
-
-http://www.han.de/~jum/aix/ldd.c
-
----
-From: Christopher Browne <cbbrowne@ca.afilias.info>
-Date: 2005-11-02
-
-On AIX 5.3 ML3 (e.g. maintenance level 5300-03), there is some problem
-with the handling of the pointer to memcpy. It is speculated that
-this relates to some linker bug that may have been introduced between
-5300-02 and 5300-03, but we have so far been unable to track down the
-cause.
-
-At any rate, the following patch, which "unwraps" the function
-reference, has been observed to allow PG 8.1 pre-releases to pass
-regression tests.
-
-The same behaviour (albeit with varying underlying functions to
-"blame") has been observed when compiling with either GCC 4.0 or IBM
-XLC.
-
------------- per Seneca Cunningham -------------------
-
-The following patch works on the AIX 5.3 ML3 box here and didn't cause
-any problems with postgres on the x86 desktop. It's just a cleaner
-version of what I tried earlier.
-
-*** dynahash.c.orig Tue Nov 1 19:41:42 2005
---- dynahash.c Tue Nov 1 20:30:33 2005
-***************
-*** 670,676 ****
-
-
- /* copy key into record */
- currBucket->hashvalue = hashvalue;
-! hashp->keycopy(ELEMENTKEY(currBucket), keyPtr, keysize);
-
-
- /* caller is expected to fill the data field on return */
-
-
---- 670,687 ----
-
-
- /* copy key into record */
- currBucket->hashvalue = hashvalue;
-! if (hashp->keycopy == memcpy)
-! {
-! memcpy(ELEMENTKEY(currBucket), keyPtr, keysize);
-! }
-! else if (hashp->keycopy == strncpy)
-! {
-! strncpy(ELEMENTKEY(currBucket), keyPtr, keysize);
-! }
-! else
-! {
-! hashp->keycopy(ELEMENTKEY(currBucket), keyPtr, keysize);
-! }
-
-
- /* caller is expected to fill the data field on return */
-
------------- per Seneca Cunningham -------------------
-
----
-
-AIX, readline, and postgres 8.1.x:
-----------------------------------
-
-If make check doesn't work on AIX with initdb going into an infinite
-loop or failing with child processes terminated with signal 11, the
-problem could be the installed copy of readline. Previously a patch to
-dynahash.c was suggested to get around this, don't use it, better ways
-to get postgres working exist.
-
-See <http://archives.postgresql.org/pgsql-patches/2005-11/msg00139.php>
-for details about the problem.
-
-Working around the problem:
----------------------------
-Try one of the following:
-
-o Use the new 8.2devel backend Makefile:
-
-After the matter of readline's export list and the problems that were
-occurring on AIX because of it being linked to the backend, a filter
-to exclude unneeded libraries from being linked against the backend was
-added. Get revision 1.112 of src/backend/Makefile from CVS and replace
-the copy that came with postgres with it. Build normally.
-
-o Use libedit
-
-There are a few libedit ports available online. Build and install the
-desired port. If libreadline.a can be found in /lib, /usr/lib, or in
-any location passed to postgres' configure via "--with-libraries=",
-readline will be detected and used by postgres. IBM's rpm of readline
-creates a symlink to /opt/freeware/lib/libreadline.a in /lib, so merely
-excluding /opt/freeware/lib from the passed library path does not stop
-readline from being used.
-
-If the linker cannot avoid finding libreadline.a, use revision 1.433
-configure.in and 1.19 config/programs.m4 from CVS, change 8.2devel to
-the appropriate 8.1.x in configure.in and run autoconf. Add the
-configure flag "--with-libedit-preferred".
-
-If the version of libedit used calls its "history.h" something other
-than history.h, place a symlink called history.h to it somewhere that
-the C preprocessor will check.
-
-o Configure with "--without-readline"
-
-postgres can be configured with the option "--without-readline". When
-this is enabled, postgres will not link against libreadline or libedit.
-psql will not have history, tab completion, or any of the other niceties
-that readline and libedit bring, but external readline wrappers exist
-that add that functionality.
-
-o Use readline 5.0
-
-Readline 5.0 does not induce the problems, however it does export
-memcpy and strncpy when built using the easy method of "-bexpall". Like
-4.3, it is possible to do a build that does not export these symbols,
-but it does take considerable manual effort and the creation of export
-files.
-
-References
-----------
-"AIX 5L Porting Guide"
- IBM Redbook
- http://www.redbooks.ibm.com/redbooks/pdfs/sg246034.pdf
- http://www.redbooks.ibm.com/abstracts/sg246034.html?Open
-
-"Developing and Porting C and C++ Applications on AIX"
- IBM Redbook
- http://www.redbooks.ibm.com/redbooks/pdfs/sg245674.pdf
- http://www.redbooks.ibm.com/abstracts/sg245674.html?Open
-
------
-
-AIX Memory Management: An Overview
-==================================
-
-by Seneca Cunningham...
-
-AIX can be somewhat peculiar with regards to the way it does memory
-management. You can have a server with many multiples of gigabytes of
-RAM free, but still get out of memory or address space errors when
-running applications.
-
-Two examples of AIX-specific memory problems
---------------------------------------------
-Both examples were from systems with gigabytes of free RAM.
-
-a) createlang failing with unusual errors
- Running as the owner of the postgres install:
- -bash-3.00$ createlang plpgsql template1
- createlang: language installation failed: ERROR: could not load library
- "/opt/dbs/pgsql748/lib/plpgsql.so": A memory address is not in the
- address space for the process.
-
- Running as a non-owner in the group posessing the postgres install:
- -bash-3.00$ createlang plpgsql template1
- createlang: language installation failed: ERROR: could not load library
- "/opt/dbs/pgsql748/lib/plpgsql.so": Bad address
-
-b) out of memory errors in the postgres logs
- Every memory allocation near or greater than 256MB failing.
-
-
-The cause of these problems
-----------------------------
-
-The overall cause of all these problems is the default bittedness and
-memory model used by the server process.
-
-By default, all binaries built on AIX are 32-bit. This does not
-depend upon hardware type or kernel in use. These 32-bit processes
-are limited to 4GB of memory laid out in 256MB segments using one of a
-few models. The default allows for less than 256MB in the heap as it
-shares a single segment with the stack.
-
-In the case of example a), above, check your umask and the permissions
-of the binaries in your postgres install. The binaries involved in
-that example were 32-bit and installed as mode 750 instead of 755.
-Due to the permissions being set in this fashion, only the owner or a
-member of the possessing group can load the library. Since it isn't
-world-readable, the loader places the object into the process' heap
-instead of the shared library segments where it would otherwise be
-placed.
-
-Solutions and workarounds
--------------------------
-In this section, all build flag syntax is presented for gcc.
-
-The "ideal" solution for this is to use a 64-bit build of postgres,
-but that's not always practical. Systems with 32-bit processors can
-build, but not run, 64-bit binaries.
-
-If a 32-bit binary is desired, set LDR_CNTRL to "MAXDATA=0xn0000000",
-where 1 <= n <= 8, before starting the postgres server and try different
-values and postgresql.conf settings to find a configuration that works
-satisfactorily. This use of LDR_CNTRL tells AIX that you want the
-server to have $MAXDATA bytes set aside for the heap, allocated in
-256MB segments.
-
-When you find a workable configuration, ldedit can be used to modify
-the binaries so that they default to using the desired heap size.
-
-PostgreSQL might also be rebuilt, passing configure
-LDFLAGS="-Wl,-bmaxdata:0xn0000000" to achieve the same effect.
-
-For a 64-bit build, set OBJECT_MODE to 64 and pass CC="gcc -maix64"
-and LDFLAGS="-Wl,-bbigtoc" to configure. If you omit the export of
-OBJECT_MODE, your build may fail with linker errors. When OBJECT_MODE
-is set, it tells AIX's build utilities such as ar, as, and ld what
-type of objects to default to handling.
-
-Overcommit
-----------
-
-By default, overcommit of paging space can happen. While I have not
-seen this occur, AIX will kill processes when it runs out of memory
-and the overcommit is accessed. The closest to this that I have seen
-is fork failing because the system decided that there was not enough
-memory for another process. Like many other parts of AIX, the paging
-space allocation method and out-of-memory kill is configurable on a
-system- or process-wide basis if this becomes a problem.
-
-References and resources
-------------------------
-"Large Program Support"
- AIX Documentation: General Programming Concepts: Writing and Debugging Programs
- http://publib.boulder.ibm.com/infocenter/pseries/topic/com.ibm.aix.doc/aixprggd/genprogc/lrg_prg_support.htm
-
-"Program Address Space Overview"
- AIX Documentation: General Programming Concepts: Writing and Debugging Programs
- http://publib.boulder.ibm.com/infocenter/pseries/topic/com.ibm.aix.doc/aixprggd/genprogc/address_space.htm
-
-"Performance Overview of the Virtual Memory Manager (VMM)"
- AIX Documentation: Performance Management Guide
- http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.doc/aixbman/prftungd/resmgmt2.htm
-
-"Page Space Allocation"
- AIX Documentation: Performance Management Guide
- http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.doc/aixbman/prftungd/memperf7.htm
-
-"Paging-space thresholds tuning"
- AIX Documentation: Performance Management Guide
- http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.doc/aixbman/prftungd/memperf6.htm
-
-"Developing and Porting C and C++ Applications on AIX"
- IBM Redbook
- http://www.redbooks.ibm.com/redbooks/pdfs/sg245674.pdf
- http://www.redbooks.ibm.com/abstracts/sg245674.html?Open
-
-
-Statistics Collector Fun on AIX
---------------------------------
-
-When implementing PostgreSQL version 8.1 on AIX 5.3, we periodically
-ran into problems where the statistics collector would "mysteriously"
-not come up successfully.
-
-This appears to be the result of unexpected behaviour in the IPv6
-implementation. It looks like PostgreSQL and IPv6 do not play very
-well together at this time on AIX.
-
-Any of the following actions "fix" the problem.
-
-1. Delete the localhost ipv6 address
-
-(as root)
-# ifconfig lo0 inet6 ::1/0 delete
-
-2. Remove IPv6 from net services. The file /etc/netsvc.conf, on AIX,
-is roughly equivalent to /etc/nsswitch.conf on Solaris/Linux.
-
-The default, on AIX, is thus:
-
- hosts=local,bind
-
-Replace this with:
-
- hosts=local4,bind4
-
-to deactivate searching for IPv6 addresses.
-
-
-Shared Linking
---------------
-
-Shared libraries in AIX are different from shared libraries in Linux.
-
-A shared library on AIX is an 'ar' archive containing shared objects. A
-shared object is produced by the linker when invoked appropriately (e.g.
-with -G), it is what we call a shared library on Linux.
-
--> On AIX, you can do a static as well as a dynamic
--> link against a shared library, it depends on how you
--> invoke the linker.
-
-When you link statically, the shared objects from the library are added
-to your executable as required; when you link dynamically, only
-references to the shared objects are included in the executable.
-
-Consequently you do not need a separate static library on AIX if you
-have a dynamic library.
-
-However, you CAN have static libraries (ar archives containing *.o
-files), and the linker will link against them. This will of course
-always be a static link.
-
-When the AIX linker searches for libraries to link, it will look for a
-library libxy.a as well as for a single shared object libxy.so when you
-tell it to -lyx. When it finds both in the same directory, it will
-prefer libpq.a unless invoked with -brtl.
-
-This is where the problem occurs:
-
-By default, PostgreSQL will (in the Linux way) create a shared object
-libpq.so and a static library libpq.a in the same directory.
-
-Up to now, since the linker was invoked without the -brtl flag, linking
-on AIX was always static, as the linker preferred libpq.a over libpq.so.
-
-We could have solved the problem by linking with -brtl on AIX, but we
-chose to go a more AIX-conforming way so that third party programs
-linking against PostgreSQL libraries will not be fooled into linking
-statically by default.
-
-The 'new way' on AIX is:
-- Create libxy.so.n as before from the static library
- libxy.a with the linker.
-- Remove libxy.a
-- Recreate libxy.a as a dynamic library with
- ar -cr libxy.a libxy.so.n
-- Only install libxy.a, do not install libxy.so
-
-Since linking is dynamic on AIX now, we have a new problem:
-
-We must make sure that the executable finds its library even if the
-library is not installed in one of the standard library paths (/usr/lib
-or /lib).
-
-On Linux this is done with an RPATH, on AIX the equivalent is LIBPATH
-that can be specified at link time with -blibpath:<colon separated path>
-. If you do not specify the LIBPATH, it is automatically computed from
-the -L arguments given to the linker. The LIBPATH, when set, must
-contain ALL directories where shared libraries should be searched,
-including the standard library directories.
-
-Makefile.aix has been changed to link executables with a LIBPATH that
-contains --libdir when PostgreSQL is configured with --enable-rpath (the
-default).
-
-The AIX equivalent for the Linux environment variable LD_LIBRARY_PATH is
-LIBPATH.
-
-The regression tests rely on LD_LIBRARY_PATH and have to be changed to
-set LIBPATH as well.
-
-Laurenz Albe
-
-<!-- $PostgreSQL: pgsql/doc/src/sgml/installation.sgml,v 1.314 2008/11/21 16:46:19 petere Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/installation.sgml,v 1.315 2008/11/24 11:59:37 petere Exp $ -->
<chapter id="installation">
<title><![%standalone-include[<productname>PostgreSQL</>]]>
installation issues.
</para>
+ <sect2 id="installation-notes-aix">
+ <title>AIX</title>
+
+ <indexterm zone="installation-notes-aix">
+ <primary>AIX</primary>
+ <secondary>installation on</secondary>
+ </indexterm>
+
+ <para>
+ PostgreSQL on AIX works, but getting it installed properly can be
+ challenging. Both AIX version 4.3 and 5.3 are supported in
+ theory. You can use GCC or the native IBM compiler xlc. 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.
+ </para>
+
+ <para>
+ Use the following <command>configure</command> flags in addition
+ to your own if you have Readline or libz
+ there: <literal>--with-includes=/usr/local/include
+ --with-libraries=/usr/local/lib</literal>.
+ </para>
+
+ <para>
+ If you don't have a PowerPC or use GCC you might see rounding
+ differences in the geometry regression test. There will probably
+ be warnings about 0.0/0.0 division and duplicate symbols which you
+ can safely ignore.
+ </para>
+
+ <para>
+ Some of the AIX tools may be <quote>a little different</quote>
+ from what you may be accustomed to on other platforms. If you are
+ looking for a version of <command>ldd</command>, useful for
+ determining what object code depends on what libraries, the
+ following URLs may help you:
+ <ulink url="http://www.faqs.org/faqs/aix-faq/part4/section-22.html"></ulink>,
+ <ulink url="http://www.han.de/~jum/aix/ldd.c"></ulink>.
+ </para>
+
+ <sect3>
+ <title>AIX 4.3.2</title>
+
+ <para>
+ On AIX 4.3.2, you need <filename>libm.a</filename> that is in the
+ fileset bos.adt.libm. Try the following command:
+<screen>
+$ lslpp -l bos.adt.libm
+</screen>
+ </para>
+ </sect3>
+
+ <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>sockadr_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>sockadr_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, that will
+ include this fix. Use the command <literal>oslevel -r</literal>
+ to determine what maintenance level you are at. An immediate
+ resolution is to alter <symbol>_SS_MAXSIZE</symbol> to = 1025 in
+ <filename>/usr/include/sys/socket.h</filename>.
+ </para>
+ </sect3>
+
+ <sect3>
+ <title>Memory Management</title>
+ <!-- http://archives.postgresql.org/message-id/603bgqmpl9.fsf@dba2.int.libertyrms.com -->
+
+ <para>
+ AIX can be somewhat peculiar with regards to the way it does
+ memory management. You can have a server with many multiples of
+ gigabytes of RAM free, but still get out of memory or address
+ space errors when running applications. One example
+ is <command>createlang</command> failing with unusual errors.
+ For example, running as the owner of the PostgreSQL installation:
+<screen>
+-bash-3.00$ createlang plpgsql template1
+createlang: language installation failed: ERROR: could not load library "/opt/dbs/pgsql748/lib/plpgsql.so": A memory address is not in the address space for the process.
+</screen>
+ Running as a non-owner in the group posessing the PostgreSQL
+ installation:
+<screen>
+-bash-3.00$ createlang plpgsql template1
+createlang: language installation failed: ERROR: could not load library "/opt/dbs/pgsql748/lib/plpgsql.so": Bad address
+</screen>
+ Another example is out of memory errors in the PostgreSQL server
+ logs, with every memory allocation near or greater than 256 MB
+ failing.
+ </para>
+
+ <para>
+ The overall cause of all these problems is the default bittedness
+ and memory model used by the server process. By default, all
+ binaries built on AIX are 32-bit. This does not depend upon
+ hardware type or kernel in use. These 32-bit processes are
+ limited to 4 GB of memory laid out in 256 MB segments using one
+ of a few models. The default allows for less than 256 MB in the
+ heap as it shares a single segment with the stack.
+ </para>
+
+ <para>
+ In the case of the <command>createlang</command> example, above,
+ check your umask and the permissions of the binaries in your
+ PostgreSQL installation. The binaries involved in that example
+ were 32-bit and installed as mode 750 instead of 755. Due to the
+ permissions being set in this fashion, only the owner or a member
+ of the possessing group can load the library. Since it isn't
+ world-readable, the loader places the object into the process'
+ heap instead of the shared library segments where it would
+ otherwise be placed.
+ </para>
+
+ <para>
+ The <quote>ideal</quote> solution for this is to use a 64-bit
+ build of PostgreSQL, but that is not always practical, because
+ systems with 32-bit processors can build, but not run, 64-bit
+ binaries.
+ </para>
+
+ <para>
+ If a 32-bit binary is desired, set <symbol>LDR_CNTRL</symbol> to
+ <literal>MAXDATA=0x<replaceable>n</replaceable>0000000</literal>,
+ where 1 <= n <= 8, before starting the PostgreSQL server,
+ and try different values and <filename>postgresql.conf</filename>
+ settings to find a configuration that works satisfactorily. This
+ use of <symbol>LDR_CNTRL</symbol> tells AIX that you want the
+ server to have <symbol>MAXDATA</symbol> bytes set aside for the
+ heap, allocated in 256 MB segments. When you find a workable
+ configuration,
+ <command>ldedit</command> can be used to modify the binaries so
+ that they default to using the desired heap size. PostgreSQL can
+ also be rebuilt, passing <literal>configure
+ LDFLAGS="-Wl,-bmaxdata:0x<replaceable>n</replaceable>0000000"</literal>
+ to achieve the same effect.
+ </para>
+
+ <para>
+ For a 64-bit build, set <envar>OBJECT_MODE</envar> to 64 and
+ pass <literal>CC="gcc -maix64"</literal>
+ and <literal>LDFLAGS="-Wl,-bbigtoc"</literal>
+ to <command>configure</command>. (Options for
+ <command>xlc</command> might differ.) If you omit the export of
+ <envar>OBJECT_MODE</envar>, your build may fail with linker errors. When
+ <envar>OBJECT_MODE</envar> is set, it tells AIX's build utilities
+ such as <command>ar</>, <command>as</>, and <command>ld</> what
+ type of objects to default to handling.
+ </para>
+
+ <para>
+ By default, overcommit of paging space can happen. While we have
+ not seen this occur, AIX will kill processes when it runs out of
+ memory and the overcommit is accessed. The closest to this that
+ we have seen is fork failing because the system decided that
+ there was not enough memory for another process. Like many other
+ parts of AIX, the paging space allocation method and
+ out-of-memory kill is configurable on a system- or process-wide
+ basis if this becomes a problem.
+ </para>
+
+ <bibliography>
+ <title>References and resources</title>
+
+ <biblioentry>
+ <biblioset relation="article">
+ <title><ulink url="http://publib.boulder.ibm.com/infocenter/pseries/topic/com.ibm.aix.doc/aixprggd/genprogc/lrg_prg_support.htm">Large Program Support</ulink></title>
+ </biblioset>
+ <biblioset relation="book">
+ <title>AIX Documentation: General Programming Concepts: Writing and Debugging Programs</title>
+ </biblioset>
+ </biblioentry>
+
+ <biblioentry>
+ <biblioset relation="article">
+ <title><ulink url="http://publib.boulder.ibm.com/infocenter/pseries/topic/com.ibm.aix.doc/aixprggd/genprogc/address_space.htm">Program Address Space Overview</ulink></title>
+ </biblioset>
+ <biblioset relation="book">
+ <title>AIX Documentation: General Programming Concepts: Writing and Debugging Programs</title>
+ </biblioset>
+ </biblioentry>
+
+ <biblioentry>
+ <biblioset relation="article">
+ <title><ulink url="http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.doc/aixbman/prftungd/resmgmt2.htm">Performance Overview of the Virtual Memory Manager (VMM)</ulink></title>
+ </biblioset>
+ <biblioset relation="book">
+ <title>AIX Documentation: Performance Management Guide</title>
+ </biblioset>
+ </biblioentry>
+
+ <biblioentry>
+ <biblioset relation="article">
+ <title><ulink url="http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.doc/aixbman/prftungd/memperf7.htm">Page Space Allocation</ulink></title>
+ </biblioset>
+ <biblioset relation="book">
+ <title>AIX Documentation: Performance Management Guide</title>
+ </biblioset>
+ </biblioentry>
+
+ <biblioentry>
+ <biblioset relation="article">
+ <title><ulink url="http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.doc/aixbman/prftungd/memperf6.htm">Paging-space thresholds tuning</ulink></title>
+ </biblioset>
+ <biblioset relation="book">
+ <title>AIX Documentation: Performance Management Guide</title>
+ </biblioset>
+ </biblioentry>
+
+ <biblioentry>
+ <title><ulink url=" http://www.redbooks.ibm.com/abstracts/sg245674.html?Open">Developing and Porting C and C++ Applications on AIX</ulink></title>
+ <publisher>
+ <publishername>IBM Redbook</publishername>
+ </publisher>
+ </biblioentry>
+ </bibliography>
+ </sect3>
+
+ <sect3>
+ <title>Statistics Collector Issues</title>
+ <!-- http://archives.postgresql.org/message-id/6064jt6cfm.fsf_-_@dba2.int.libertyrms.com -->
+
+ <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 behaviour in the IPv6
+ implementation. It looks like PostgreSQL and IPv6 do not play
+ very well together at this time on AIX.
+ </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>
+ </sect3>
+ </sect2>
+
<sect2 id="installation-notes-cygwin">
<title>Cygwin</title>
projects / postgresql.git / commitdiff