AIX FAQ

Some of this may have already made it in; it's not totally clear...

At any rate, here's a revision to CVS HEAD to reflect some changes by
myself and by Seneca Cunningham for the AIX FAQ. It touches on the
following issues:

1. memcpy pointer patch for dynahash.c

2. AIX memory management, which can, for 32 bit cases, bite people
quite unexpectedly...

Index: FAQ_AIX
===================================================================
RCS file: /projects/cvsroot/pgsql/doc/FAQ_AIX,v
retrieving revision 1.16
diff -c -r1.16 FAQ_AIX
*** FAQ_AIX 5 Apr 2006 22:55:05 -0000 1.16
--- FAQ_AIX 6 Apr 2006 20:07:28 -0000
***************
*** 113,118 ****
--- 113,180 ----
http://www.faqs.org/faqs/aix-faq/part4/section-22.html

http://www.han.de/~jum/aix/ldd.c
+
+ ---
+ From: Christopher Browne <cbbrowne(at)ca(dot)afilias(dot)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:
***************
*** 185,187 ****
--- 247,367 ----
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 postmaster 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 postmaster 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
+ postmaster 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

--
(reverse (concatenate 'string "gro.gultn" "@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/linuxxian.html
"What's wrong with 3rd party tools? Especially if they are free? What
the **** do you think Unix is anyway? It's a big honkin' party of 3rd
party free tools." -- Bob Cassidy (rmcassid(at)uci(dot)edu)