16.7.1.1. GCC问题

在 AIX 5.3 上，使用 GCC 编译和运行 PostgreSQL 有一些问题。

你将要使用 GCC 继 3.3.2 之后的一个版本，特别是如果你在使用一个打包好的版本。我们在 4.0.1 上获得了成功。早期版本的问题看起来更多地与 IBM 打包的 GCC 有关，而非 GCC 真正的问题，因此如果你自己编译 GCC， 你更有可能使用早期版本的 GCC 取得成功。

16.7.1.2. Unix域套接字崩溃

AIX 5.3 有一个问题是sockaddr_storage定义得不够大。在版本 5.3 中，IBM 增加了sockaddr_un（Unix域套接字的地址结构）的尺寸，但是没有相应地增加sockaddr_storage的尺寸。这样做的结果是在 PostgreSQL 中尝试使用 Unix域套接字会导致 libpq 让该数据结构溢出。 TCP/IP 连接工作正常，但是 Unix域套接字不行，这将使回归测试不能工作。

该问题已经被报告给了 IBM，并且已被记录为缺陷报告 PMR29657。如果你升级到 maintenance level 5300-03 或更新，将会包括这个修复。一种快速的解决方法是把/usr/include/sys/socket.h中的_SS_MAXSIZE改成 1025。在两种情况中，一旦你得到了修正过的头文件，你都需要重编译 PostgreSQL。

16.7.1.3. Internet地址问题

PostgreSQL 依赖系统的getaddrinfo函数来解析listen_addresses、pg_hba.conf等中的 IP 地址。旧版本的 AIX 在这个函数中有各种各样的缺陷。如果你存在与此有关的问题，更新到上文所示的合适的 AIX fix level 将会解决它。

一个用户报告：

当在 AIX 5.3 上实现 PostgreSQL 版本 8.1 时，我们会周期性地碰到问题，在其中统计收集器会"神秘地"无法成功启动。这似乎是在 IPv6 实现中意外行为的结果。看起来 PostgreSQL 和 IPv6 无法和 AIX 5.3 一起很好地工作。

下面任意一种动作都可以"修复"该问题。

• 删除 localhost 的 IPv6 地址：

  (as root)
  # ifconfig lo0 inet6 ::1/0 delete

• 从网络服务删除 IPv6。AIX 上的/etc/netsvc.conf大概等价于 Solaris/Linux 上的/etc/nsswitch.conf。在 AIX 上的默认值因此是：

  hosts=local,bind

  将其换成：

  hosts=local4,bind4

  来使 IPv6 地址的搜索无效。

16.7.1.4. 内存管理

AIX 的特别之处在于它的内存管理。你可能有一个装备有好多个吉字节空闲 RAM 的服务器，但是在运行应用时仍然会得到内存不足或者地址空间错误。一个例子是createlang会因为罕见的错误失败。例如，作为 PostgreSQL 安装的拥有者运行：

-bash-3.00$ createlang plperl template1
createlang: language installation failed: ERROR:  could not load library "/opt/dbs/pgsql748/lib/plperl.so": A memory address is not in the address space for the process.

作为拥有 PostgreSQL 安装的组中的非拥有者运行：

-bash-3.00$ createlang plperl template1
createlang: language installation failed: ERROR:  could not load library "/opt/dbs/pgsql748/lib/plperl.so": Bad address

另一个例子是 PostgreSQL 服务器日志中的内存不足错误，每次内存分配接近或者超过 256 MB 时都会失败。

所有这些问题的总体成因是服务器进程所用的寻址空间和内存模型。默认情况下，所有在 AIX 上编译的二进制都是32位。这并不依赖于硬件类型或使用的内核。这些32位进程被限制在 4GB 的内存中，并被使用几种模型之一安排成 256 MB 的段。该默认值允许在堆中低于 256 MB，因为它和栈共享一个单独的段。

在createlang的例子中，检查你的 umask 和你的 PostgreSQL 安装中的二进制的权限。这个例子中涉及的二进制是32位的并且被用模式 750 而不是 755 安装。由于这种方式的权限设置，只有所有者或拥有组的成员可以载入该库。因为它不是所有人可读的，载入器将该对象放在进程的堆中而不是它应该被放入的共享库段中。

这个问题的"理想的"解决方案是使用 PostgreSQL 的64位编译，但是这不是总是实用的，因为有32位处理器的系统可以编译64位二进制但是却不能运行它。

如果想要一个 32 位二进制，在开始 PostgreSQL 服务器之前将LDR_CNTRL设置为MAXDATA=0xn0000000，其中 1 <= n <= 8，并且尝试不同的值以及postgresql.conf设置来找一个能让你满意的配置。这种LDR_CNTRL的使用告诉 AIX 你希望服务器留出MAXDATA字节给堆，以 256 MB 的段分配。当你找到了一个可工作的配置时，ldedit可以被用来修改二进制，这样它们默认使用想要的堆尺寸。PostgreSQL 也可以被重新编译，传递configure LDFLAGS="-Wl,-bmaxdata:0xn0000000"来达到相同的效果。

对于一个 64 位编译，设置OBJECT_MODE为 64 并且传递CC="gcc -maix64"和LDFLAGS="-Wl,-bbigtoc"给configure（给xlc的选项可能不同）。如果你省略OBJECT_MODE的输出，你的编译可能会因为链接器错误而失败。当OBJECT_MODE被设置时，它告诉 AIX 的编译工具（如ar、as和ld）默认要处理哪些对象类型。

默认情况下，过量使用页面空间的情况可能会发生。不过我们还没有看到过，当进程用尽内存并且出现了过量使用时 AIX 会杀死进程。我们见到过的最接近于此的是 fork 失败，其原因是系统觉得已经没有足够的内存给另一个进程。和 AIX 的很多其他部分一样，如果这成为了一个问题，页面空间分配方法和耗尽内存导致的杀死在系统范围或进程范围是可以配置的。

参考和资源

16.7.4.1. 在 Windows 上收集崩溃转储

如果 PostgreSQL 在 Windows 上崩溃，它有能力产生minidumps，这可以被用来追踪崩溃发生的原因，这与 Unix 上的核心转储相似。这些转储可以被使用Windows Debugger Tools或Visual Studio读取。要启用在 Windows 上的转储生成，可在集簇数据目录下创建一个名为crashdumps的子目录。转储将被写入到这个目录，转储的名字基于崩溃进程的标识符和崩溃的当前时间来确定。

16.7.5.1. Skunkware

你应该找到你的 SCO Skunkware CD 的拷贝。Skunkware CD 被包括在 UnixWare 7 和当前版本的 OpenServer 5。Skunkware 包括很多在互联网上可以得到的流行程序的待安装版本。例如，gzip、gunzip、GNU Make、Flex 和 Bison 都被包括在内。对于 UnixWare 7.1，这个 CD 现在被标为 "Open License Software Supplement"。如果你没有这个 CD，其中的软件可以从http://www.sco.com/skunkware/得到。

对于 UnixWare 和 OpenServer，Skunkware有不同的版本。请确保你为你的操作系统安装了正确的版本，除了以下需要注意的。

在 UnixWare 7.1.3 及其以后，GCC 被包括在 UDK CD 上作为 GNU Make。

16.7.5.2. GNU Make

你需要使用 GNU Make 程序，它位于 Skunkware CD 上。默认情况下，它作为/usr/local/bin/make安装。

对于 UnixWare 7.1.3 及以上，GNU Make 程序是 UDK CD 的 OSTK 部分，并且在/usr/gnu/bin/gmake中。

16.7.5.3. Readline

Readline 库在 Skunkware CD 上。但是它不被包括在 UnixWare 7.1 Skunkware CD 上。如果你有 UnixWare 7.0.0 或 7.0.1 Skunkware CD，你可以从那里安装 Readline 库。否则，试试http://www.sco.com/skunkware/。

默认情况下，Readline 安装到/usr/local/lib和/usr/local/include。但是，PostgreSQL configure 程序在没有得到帮助的情况下将不能找到它。如果你安装了 Readline，那么对configure使用下列选项：

./configure --with-libraries=/usr/local/lib --with-includes=/usr/local/include

16.7.5.4. 在 OpenServer 上使用 UDK

如果你正在 OpenServer 上使用新的 Universal Development Kit (UDK) 编译器，你需要指定 UDK 库的位置：

./configure --with-libraries=/udk/usr/lib --with-includes=/udk/usr/include

把这些和 Readline 选项放在一起：

./configure --with-libraries="/udk/usr/lib /usr/local/lib" --with-includes="/udk/usr/include /usr/local/include"

16.7.5.5. 阅读 PostgreSQL 手册页

默认情况下，PostgreSQL 手册页被安装到/usr/local/pgsql/share/man。默认情况下，UnixWare 不会在那里查看手册页。要能够阅读它们你需要修改/etc/default/man中的MANPATH变量，例如：

MANPATH=/usr/lib/scohelp/%L/man:/usr/dt/man:/usr/man:/usr/share/man:scohelp:/usr/local/man:/usr/local/pgsql/share/man

在 OpenServer 上，某些额外的研究需要被覆盖来使得手册页可用，因为其手册系统与其他平台有点不同。当前，PostgreSQL 将根本不会安装它们。

16.7.5.6. 带 7.1.1b 特性补充的 C99 问题

对于那些早于随 OpenUNIX 8.0.0（UnixWare 7.1.2）一起发布的编译器版本的编译器，它们包括 7.1.1b 特性补充，你可能需要在CFLAGS或CC环境变量中指定-Xb。这种问题的迹象是在编译引用内联函数的tuplesort.c时的一个错误。显然在 7.1.2（8.0.0）及以后的编译器中已有修改。

16.7.5.7. UnixWare 上的线程

对于线程，你必须在所有使用libpq的程序上使用-Kpthread。libpq使用pthread_*调用，这些只能在有-Kpthread/-Kthread标志的情况下可用。

16.7.6.1. 要求的工具

你可以使用 GCC 或 Sun 的编译器套件进行编译。为了更好的代码优化，我们强烈推荐在 SPARC 架构下使用 Sun 的编译器。我们已经得到一些使用 GCC 2.95.1 时的问题报告；我们推荐 GCC 2.95.3 或之后的版本。如果你正在使用 Sun 的编译器，注意不要选择/usr/ucb/cc；而是使用/opt/SUNWspro/bin/cc。

你可以从http://www.oracle.com/technetwork/server-storage/solarisstudio/downloads/下载 Sun Studio。很多 GNU 工具都被整合到了 Solaris 10，或者它们在 Solaris companion CD 中。如果你喜欢用于老版本 Solaris 的包，你可以在http://www.sunfreeware.com找到这些工具。如果你想要源码，在http://www.gnu.org/order/ftp.html上找找。

16.7.6.2. OpenSSL 的问题

当你编译 PostgreSQL 带有 OpenSSL 支持时，你可能在下列文件中得到编译错误：

• src/backend/libpq/crypt.c

• src/backend/libpq/password.c

• src/interfaces/libpq/fe-auth.c

• src/interfaces/libpq/fe-connect.c

这是由于标准/usr/include/crypt.h头部和 OpenSSL 提供的头文件之间的一个名字空间冲突导致的。

升级你的 OpenSSL 安装到版本 0.9.6a 来修复这个问题。 Solaris 9 及以上有一个更新版本的 OpenSSL。

16.7.6.3. configure 抱怨一个失败的测试程序

如果configure抱怨一个失败的测试程序，可能的情况是运行时链接器无法找到某些库，可能是libz、libreadline或某些其他非标准库如 libssl。要向它指出正确的位置，在configure命令行上设置LDFLAGS环境变量，例如：

configure ... LDFLAGS="-R /usr/sfw/lib:/opt/sfw/lib:/usr/local/lib"

更多信息可见ld手册页。

16.7.6.4. 64-位编译有时会崩溃

在 Solaris 7 和更老的版本上，64-位版本的 libc 有一个有缺陷的vsnprintf例程，这导致 PostgreSQL 中不稳定的核心转储。最简单的已知解决方案是强制 PostgreSQL 使用它自己的vsnprintf版本而不是库中的拷贝。要这样做，运行configure之后编辑一个由configure产生的文件： 在文件src/Makefile.global中将行

LIBOBJS =

改成

LIBOBJS = snprintf.o

（可能有其他文件已经被列在这个变量中。顺序无影响）。然后正常编译。

16.7.6.5. 为最优性能编译

在 SPARC 架构上，我们强烈推荐使用 Sun Studio来编译。尝试使用-xO5优化标志来生成显著加快的二进制。不要使用任何修改浮点操作和errno处理（例如-fast）行为的标志。这些标志可能会做出某些非标准 PostgreSQL 行为，例如在日期/时间计算中。

如果你没有理由要使用 SPARC 上的 64 位二进制，最好用 32 位版本。64 位操作较慢并且 64 位二进制比其 32 位变体要慢。并且在另一方面，AMD64 CPU 家族上的32 位代码不是原生的，并且这也是问什么在这个 CPU 族中 32 位代码要明显地更慢。

16.7.6.6. 用 DTrace 来跟踪 PostgreSQL

是的，可以使用 DTrace。详见 第 28.5 节。你还可以在这篇文章https://blogs.oracle.com/robertlor/entry/user_level_dtrace_probes_in中找到更多信息。

如果你看到postgres可执行程序的链接中断并且报出下面的错误消息：

Undefined                       first referenced
 symbol                             in file
AbortTransaction                    utils/probes.o
CommitTransaction                   utils/probes.o
ld: fatal: Symbol referencing errors. No output written to postgres
collect2: ld returned 1 exit status
make: *** [postgres] Error 1

说明你的 DTrace 安装太旧，无法处理静态函数中的探测。你需要 Solaris 10u4 或更新的版本。