平台相关的说明

PostgreSQL 9.6.0 手册
上一页	上一级	章 16. 从源代码安装	下一页

16.7.1. AIX

PostgreSQL 能在 AIX 上工作，但是正确地安装它却富有挑战性。从4.3.3到6.1的 AIX 被认为是可支持的。你可以使用 GCC 或本地 IBM 编译器xlc。通常，使用最新版本的 AIX 和 PostgreSQL 能有所帮助。在编译农场中检查有关已知能工作的 AIX 版本的最新信息。

被支持的 AIX 版本的最小推荐修理级别是：

AIX 4.3.3: Maintenance Level 11 + post ML11 bundle
AIX 5.1: Maintenance Level 9 + post ML9 bundle
AIX 5.2: Technology Level 10 Service Pack 3
AIX 5.3: Technology Level 7
AIX 6.1: Base Level

要检查你当前的修理级别，在AIX 4.3.3 至 AIX 5.2 ML 7中使用 oslevel -r，或者在后面的版本中使用 oslevel -s。

如果你已经在/usr/local中安装了 Readline 或 libz，在你自己的选项之外使用下列configure标志： --with-includes=/usr/local/include --with-libraries=/usr/local/lib.

16.7.1.1. GCC问题

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

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

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 地址的搜索无效。

警告

这实际上是对有关 IPv6 支持不成熟性的问题的一种变通方案，这在 AIX 5.3 发布的过程中有了显著地改进。它可以和 AIX 5.3 一起工作，但是不代表对此问题的一种华丽的解决方案。有报告称该变通方案不仅仅是多余的，还会在 AIX 6.1 上导致问题，在 AIX 6.1 中 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 的很多其他部分一样，如果这成为了一个问题，页面空间分配方法和耗尽内存导致的杀死在系统范围或进程范围是可以配置的。

参考和资源

"Large Program Support", AIX Documentation: General Programming Concepts: Writing and Debugging Programs.

"Program Address Space Overview", AIX Documentation: General Programming Concepts: Writing and Debugging Programs.

"Performance Overview of the Virtual Memory Manager (VMM)", AIX Documentation: Performance Management Guide.

"Page Space Allocation", AIX Documentation: Performance Management Guide.

"Paging-space thresholds tuning", AIX Documentation: Performance Management Guide.

Developing and Porting C and C++ Applications on AIX, IBM Redbook.

16.7.2. Cygwin

PostgreSQL 可以使用 Cygwin 来编译，它是用于 Windows 的一个类 Linux 环境，但是这种方法不如原生 Windows 编译（见第 17 章）并且我们已经不再推荐在 Cygwin 下运行一个服务器。

在从源代码编译时，按照正常安装过程进行（即./configure; make; 等；只要注意下列 Cygwin 相关的区别：

将你的路径设置为使用 Cygwin 的 bin 目录并且把它放在 Windows 工具的前面。这将帮助避免很多编译的问题。
不支持adduser命令；使用 Windows NT、2000 或 XP 上的用户管理应用来替代。否则，跳过这一步。
不支持su命令；在 Windows NT、2000 或 XP 上使用 ssh 来模拟 su。否则，跳过这一步。
不支持 OpenSSL。
为共享内存支持启动cygserver。要这样做，输入命令/usr/sbin/cygserver &。这个程序在你启动 PostgreSQL 服务器或初始化一个数据集簇（initdb）时的任何时刻都需要被运行。默认的cygserver配置可能需要被更改（例如增加SEMMNS）来防止 PostgreSQL 因为缺少系统资源而失败。
在某些不使用 C 区域的系统上编译可能会失败。要修复这个问题，通过在边以前export LANG=C.utf8把区域设置为 C，并且在安装完 PostgreSQL 之后把区域恢复成之前的设置。
并行回归测试（make check）可能产生虚假的回归测试错误，这是由于溢出的listen()连接缓冲区，它会导致连接拒绝错误或挂起。你可以使用MAX_CONNECTIONS来限制连接数：
```
make MAX_CONNECTIONS=5 check
```
（在某些系统上你可以有大约 10 个同时连接）。

可以把cygserver PostgreSQL 服务器安装为 Windows NT 服务。关于如何这样做的信息，请参考包含在 Cygwin 上 PostgreSQL 二进制包中的README文档。它被安装在目录/usr/share/doc/Cygwin中。

16.7.3. HP-UX

给定合适的系统补丁级别和编译工具，PostgreSQL 7.3+ 应该可以工作在运行 HP-UX 10.X 或 11.X 的 Series 700/800 PA-RISC 机器上。至少一个开发者例行地在 HP-UX 10.20 上测试过，并且我们有在 HP-UX 11.00 和 11.11 上成功安装的报告。

除了 PostgreSQL 源代码发布，你将需要 GNU make（HP 的 make 不行），并且需要 GCC 或 HP 的 ANSI C 编译器。如果你想从 Git 源编译而不是一个发布包，你还将需要 Flex（GNU lex）和 Bison（GNU yacc）。我们还推荐确认你真的在使用最新的 HP 补丁。最低限度下，如果你在 HP-UX 11.11 上编译 64 位二进制，你可能需要 PHSS_30966 (11.11) 或一个后继补丁，否则initdb可能中止：

PHSS_30966 s700_800 ld(1) and linker tools cumulative patch

在一般原则上，你应该使用 libc 和 ld/dld 的当前补丁，如果你在使用 HP 的 C 编译器也一样要用当前的编译器补丁。它们最新补丁的免费拷贝请见 HP 的支持站点如http://itrc.hp.com和ftp://us-ffs.external.hp.com/。

如果你正在一台 PA-RISC 2.0 机器上编译并且项使用 GCC 得到 64 位二进制，你必须使用 GCC 的 64 位版本。HP-UX PA-RISC 和 Itanium 的 GCC 二进制可以从http://www.hp.com/go/gcc得到。别忘了在同时获取并安装 binutils。

如果你正在一台 PA-RISC 2.0 机器上编译并且想让编译好的二进制运行在 PA-RISC 1.1 机器上，你将需要在CFLAGS中指定+DAportable。

如果你正在一台 HP-UX Itanium 机器上编译，你将需要最新的 HP ANSI C 编译器，以及它的依赖补丁或后继补丁：

PHSS_30848 s700_800 HP C Compiler (A.05.57)
PHSS_30849 s700_800 u2comp/be/plugin library Patch

如果你同时有 HP 的 C 编译器和 GCC 的编译器，那么在运行configure时你可能希望显式地选择要使用的编译器：

./configure CC=cc

用于 HP 的 C 编译器，或者

./configure CC=gcc

用于 GCC。如果你忽略这个设置，configure 在可以选择时会使用gcc。

默认的安装目标位置是/usr/local/pgsql，你可能希望修改它为/opt之下的某个地方。如果是这样，使用configure的--prefix开关。

在回归测试中，在几何测试中可能会有某些低序位差别，这会根据你使用的编译器和数学库版本而变化。任何其他错误都需要怀疑。

16.7.4. MinGW/原生 Windows

用于 Windows 的 PostgreSQL 可以使用 MinGW 编译，它是一个用于微软操作系统的类 Unix 的编译环境。也可以使用微软的Visual C++编译器套件来编译。MinGW 编译使用本章中描述的正常编译系统；而 Visual C++ 编译的工作完全不同并且在第 17 章中描述。后者是一种完全原生的编译并且没有像 MinGW 那样使用额外软件。在 PostgreSQL 的主网站上有一个现成的安装器可用。

原生 Windows 移植要求一个 Windows 2000 或更高的 32 或 64 位版本。早期的操作系统没有足够的基础设施（但 Cygwin可以用在它们之上）。类 Unix 的编译工具 MinGW 和 MSYS（一个 Unix 工具集合，用于运行如configure之类的 shell 脚本）可以从http://www.mingw.org/下载。运行结果二进制两者都需要，它们只在创建二进制时需要。

要使用 MinGW 编译 64 位二进制，从http://mingw-w64.sourceforge.net/安装 64 位工具。把它放在PATH中的 bin 目录，并且使用--host=x86_64-w64-mingw32选项运行configure.

在你安装完所有的东西之后，我们建议你在CMD.EXE下运行psql，因为 MSYS 控制台有缓冲问题。

16.7.4.1. 在 Windows 上收集崩溃转储

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

16.7.5. SCO OpenServer 和 SCO UnixWare

PostgreSQL 可以在 SCO UnixWare 7 和 SCO OpenServer 5 上编译。在 OpenServer 上，你可以使用 OpenServer Development Kit 或 Universal Development Kit。但是可能需要一些调整，如下所述。

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

PostgreSQL 在 Solaris 上得到了很好的支持。你的操作系统越新，你将会碰到更少的问题；细节如下。

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 或更新的版本。

PostgreSQL

16.7. 平台相关的说明