15.7. 平台相关说明 #
本节记录 PostgreSQL 安装和设置时的一些平台相关附加问题。请务必阅读安装说明，尤其是第 15.2 节。此外，也请参阅第 30 章中关于如何解释回归测试结果的说明。
这里未列出的平台，目前没有已知的平台特定安装问题。
15.7.1. AIX #
PostgreSQL 可以在 AIX 上运行，但正确安装可能比较困难。AIX 4.3.3 至 6.1 被视为受支持版本。你可以使用 GCC 或原生 IBM 编译器 xlc。一般来说，使用较新的 AIX 和 PostgreSQL 版本会有所帮助。关于哪些 AIX 版本已知可用的最新信息，请查看构建农场。
对于受支持的 AIX 版本，建议至少达到以下修复级别：
- AIX 4.3.3
维护级别 11，加上 ML11 后续补丁包
- AIX 5.1
维护级别 9，加上 ML9 后续补丁包
- AIX 5.2
技术级别 10，服务包 3
- AIX 5.3
技术级别 7
- AIX 6.1
基础级别
要检查当前修复级别，在 AIX 4.3.3 至 AIX 5.2 ML 7 上使用 oslevel -r，在更高版本上使用 oslevel -s。
如果将 Readline 或 libz 安装在 /usr/local，除了自己的选项外，还应使用以下 configure 标志：--with-includes=/usr/local/include --with-libraries=/usr/local/lib。
15.7.1.1. GCC 问题
在 AIX 5.3 上，使用 GCC 编译和运行 PostgreSQL 曾出现一些问题。
应使用晚于 3.3.2 的 GCC 版本，尤其是在使用预打包版本时。我们使用 4.0.1 的效果很好。较早版本的问题似乎更多与 IBM 打包 GCC 的方式有关，而非 GCC 本身的问题，因此如果自行编译 GCC，使用较早版本的 GCC 也很可能成功。
15.7.1.2. Unix 域套接字不可用
AIX 5.3 存在一个问题：sockaddr_storage 的大小定义不足。在 5.3 版中，IBM 增大了 Unix 域套接字地址结构 sockaddr_un 的大小，却未相应增大 sockaddr_storage。结果是，尝试通过 Unix 域套接字使用 PostgreSQL 时，libpq 会写出该数据结构的边界。TCP/IP 连接正常，但 Unix 域套接字无法正常工作，导致回归测试无法运行。
此问题已报告给 IBM，缺陷报告编号为 PMR29657。升级到维护级别 5300-03 或更高版本即可包含此修复。一种快速解决办法是将 /usr/include/sys/socket.h 中的 _SS_MAXSIZE 改为 1025。无论采用哪种方法，在取得修正后的头文件后，都应重新编译 PostgreSQL。
15.7.1.3. 互联网地址问题
PostgreSQL 依赖系统的 getaddrinfo 函数解析 listen_addresses、pg_hba.conf 等位置中的 IP 地址。较旧的 AIX 版本在此函数中存在多种缺陷。如果遇到与这些设置有关的问题，更新到上面所列的适当 AIX 修复级别应该能够解决。
一位用户报告：
在 AIX 5.3 上部署 PostgreSQL 8.1 时，我们不时遇到统计信息收集器“莫名其妙地”无法成功启动的问题。这似乎是 IPv6 实现中意外行为所致。看起来在 AIX 5.3 上，PostgreSQL 与 IPv6 配合得不太好。
以下任意操作都能“修复”此问题。
删除 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 支持不成熟所引发问题的临时解决办法，而 IPv6 支持在 AIX 5.3 的各次发布中已有明显改进。此方法在 AIX 5.3 上有效，但并不是优雅的解决方案。据报告，在 IPv6 支持更成熟的 AIX 6.1 上，这种做法不仅没有必要，还会导致问题。
15.7.1.4. 内存管理
AIX 的内存管理方式有些特殊。服务器可能有数 GB 乃至更多的空闲 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 位进程的内存上限为 4 GB，按几种模型之一以 256 MB 的段布局。默认情况下，堆与栈共享一个段，因此堆可用空间不足 256 MB。
对于上面的 createlang 示例，请检查你的 umask 和 PostgreSQL 安装中二进制文件的权限。该示例涉及的二进制文件是 32 位的，安装时使用模式 750 而非 755。由于权限以这种方式设置，只有所有者或所属组的成员可以加载该库。因为它不是所有用户可读，加载器会将该对象放入进程的堆中，而不是通常应放置的共享库段。
这个问题的“理想”解决办法是使用 64 位构建的 PostgreSQL，但这并非总是可行，因为采用 32 位处理器的系统可以构建 64 位二进制文件，却无法运行它们。
如果需要 32 位二进制文件，请在启动 PostgreSQL 服务器之前，将 LDR_CNTRL 设为 MAXDATA=0x，其中 1 <= n <= 8，并尝试不同的值及 n0000000postgresql.conf 设置，找到能令人满意地工作的配置。这样使用 LDR_CNTRL 会告知 AIX，为服务器的堆预留 MAXDATA 字节，按 256 MB 的段分配。找到可用配置后，可以使用 ldedit 修改二进制文件，使其默认使用所需的堆大小。也可以重新构建 PostgreSQL，传入 configure LDFLAGS="-Wl,-bmaxdata:0x 来达到相同效果。n0000000"
对于 64 位构建，将 OBJECT_MODE 设为 64，并向 configure 传入 CC="gcc -maix64" 和 LDFLAGS="-Wl,-bbigtoc"。（xlc 的选项可能不同。）如果未导出 OBJECT_MODE，构建可能因链接器错误而失败。设置 OBJECT_MODE 后，它会告知 AIX 的 ar、as 和 ld 等构建工具默认处理哪种对象。
默认情况下，可能发生分页空间过量分配。虽然我们尚未见过这种情况，但当内存耗尽且访问了过量分配的空间时，AIX 会终止进程。我们遇到过最接近的情况是，系统认为没有足够内存容纳另一个进程，导致 fork 失败。与 AIX 的许多其他部分一样，如果这成为问题，可以在系统或进程级别配置分页空间分配方式和内存不足时终止进程的行为。
References and Resources
“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.
15.7.2. Cygwin #
可以使用 Cygwin 这个 Windows 上的类 Linux 环境来构建 PostgreSQL，但这种方式不如原生 Windows 构建（见第 16 章），且如今已不再推荐在 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()的待处理连接队列溢出而误报回归测试失败；队列溢出会导致连接被拒绝的错误或挂起。可以使用 make 变量MAX_CONNECTIONS限制连接数，方法如下：make MAX_CONNECTIONS=5 check
（在某些系统上，并发连接数最高可达约 10 个。）
可以把 cygserver 和 PostgreSQL 服务器安装为
Windows NT 服务。关于具体做法，请参阅 Cygwin 上 PostgreSQL 二进制包附带的
README 文档。它安装在
/usr/share/doc/Cygwin 目录中。
15.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 源码而非发行 tar 包构建，还需要 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 位二进制文件，则必须使用 64 位版本的 GCC。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 选项。
在回归测试中，几何测试可能存在一些低位数字差异，具体取决于所用编译器和数学库的版本。任何其他错误都值得怀疑。
15.7.4. macOS #
在较新的 macOS 版本中，需要把
“sysroot” 路径嵌入到用于查找某些系统头文件的 include 开关中。这会导致 configure 脚本的输出，因为 configure 时所用 SDK 版本不同而变化。在简单场景下这通常不是问题；但如果你要做的是类似于在与服务器代码构建机器不同的另一台机器上构建扩展，就可能需要强制使用不同的 sysroot 路径。要这样做，请设置 PG_SYSROOT，例如：
make PG_SYSROOT=/desired/path all要找出你机器上的合适路径，请运行：
xcodebuild -version -sdk macosx Path
请注意，使用与构建核心服务器时不同的 sysroot 版本来构建扩展并不值得推荐；最坏情况下，这可能导致难以调试的 ABI 不一致。
你也可以在配置时通过向 configure 指定
PG_SYSROOT，选择非默认的 sysroot 路径：
./configure ... PG_SYSROOT=/desired/path
macOS 的“系统完整性保护”（SIP）功能会破坏 make check，因为它会阻止将所需的 DYLD_LIBRARY_PATH 设置传给被测试的可执行文件。可以在 make check 之前先执行 make install 来规避这一问题。不过，大多数 Postgres 开发者会直接关闭 SIP。
15.7.5. MinGW/原生 Windows #
Windows 版 PostgreSQL 可以使用 MinGW（用于 Microsoft 操作系统的类 Unix 构建环境）构建，也可以使用 Microsoft 的 Visual C++ 编译器套件构建。MinGW 构建方式使用本章介绍的常规构建系统；Visual C++ 构建方式完全不同，详见第 16 章。后者是完全原生的构建，不使用 MinGW 等附加软件。PostgreSQL 主网站上提供现成的安装程序。
原生 Windows 移植版本要求 32 位或 64 位的 Windows 2000 或更高版本。更早的操作系统没有足够的基础设施（但可以在其上使用 Cygwin）。可以从http://www.mingw.org/下载 MinGW 这一类 Unix 构建工具，以及 MSYS 这一运行 configure 等 shell 脚本所需的 Unix 工具集。运行生成的二进制文件不需要它们；只有创建二进制文件时才需要。
要使用 MinGW 构建 64 位二进制文件，请从http://mingw-w64.sourceforge.net/安装 64 位工具集，将其 bin 目录放入 PATH，并使用 --host=x86_64-w64-mingw32 选项运行 configure。
安装好所有组件后，建议在 CMD.EXE 下运行 psql，因为 MSYS 控制台存在缓冲问题。
15.7.5.1. 在 Windows 上收集崩溃转储 #
如果 PostgreSQL 在 Windows 上崩溃，它能够生成
minidumps，可用于追踪崩溃原因，类似于 Unix 上的核心转储。这些转储可以使用
Windows Debugger Tools 或
Visual Studio 读取。要在 Windows 上启用转储生成，请在集簇数据目录中创建一个名为
crashdumps 的子目录。随后，转储会以唯一名称写入该目录，该名称基于崩溃进程的标识符以及崩溃发生时的当前时间。
15.7.6. SCO OpenServer 和 SCO UnixWare #
PostgreSQL 可以在 SCO UnixWare 7 和 SCO OpenServer 5 上构建。在 OpenServer 上，你可以使用 OpenServer Development Kit，也可以使用 Universal Development Kit。不过，可能需要按下面的说明做一些调整。
15.7.6.1. Skunkware
你应当找到你的 SCO Skunkware CD 副本。Skunkware CD 随 UnixWare 7 和当前版本的 OpenServer 5 一起提供。Skunkware 包含 Internet 上许多流行程序的即装即用版本。例如，gzip、gunzip、GNU Make、Flex 和 Bison 都包含在内。对于 UnixWare 7.1，这张 CD 现在标为 "Open License Software Supplement"。如果你没有这张 CD，其上的软件可以从http://www.sco.com/skunkware/获取。
Skunkware 对 UnixWare 和 OpenServer 有不同的版本。请确保为你的操作系统安装正确的版本，下面注明的情况除外。
在 UnixWare 7.1.3 及更高版本中，UDK CD 上附带有 GCC 编译器，GNU Make 也是如此。
15.7.6.2. GNU Make
你需要使用 GNU Make 程序，它在 Skunkware CD 上。默认情况下，它会安装为 /usr/local/bin/make。
对于 UnixWare 7.1.3 及更高版本，GNU Make 程序位于 UDK CD 的
OSTK 部分，路径为 /usr/gnu/bin/gmake。
15.7.6.3. Readline
Readline 库在 Skunkware CD 上。但 UnixWare 7.1 的 Skunkware CD 并不包含它。如果你有 UnixWare 7.0.0 或 7.0.1 的 Skunkware CD，可以从那里安装。否则，请尝试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
15.7.6.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"
15.7.6.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 完全不会安装它们。
15.7.6.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) 及之后的编译器发生了变化。
15.7.6.7. UnixWare上的线程
对于线程，你必须在所有使用 libpq
的程序上使用 -Kpthread。libpq 使用
pthread_* 调用，而这些调用只有在使用
-Kpthread/-Kthread 标志时才可用。
15.7.7. Solaris #
PostgreSQL 在 Solaris 上有良好支持。你的操作系统越新，遇到的问题越少；详情见下文。
15.7.7.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 配套光盘中。如果你需要适用于较旧 Solaris 版本的软件包，可以到http://www.sunfreeware.com查找这些工具。如果你更想要源码，请看http://www.gnu.org/order/ftp.html。
15.7.7.2. OpenSSL 的问题
在以 OpenSSL 支持构建 PostgreSQL 时，你可能会在以下文件中遇到编译错误：
src/backend/libpq/crypt.csrc/backend/libpq/password.csrc/interfaces/libpq/fe-auth.csrc/interfaces/libpq/fe-connect.c
这是因为标准的 /usr/include/crypt.h 头文件与 OpenSSL 提供的头文件之间存在命名空间冲突。
将你的 OpenSSL 安装升级到 0.9.6a 版可解决此问题。Solaris 9 及更高版本带有较新版本的 OpenSSL。
15.7.7.3. configure 报告测试程序失败
如果 configure 报告某个测试程序失败，这多半是因为运行时链接器找不到某些库，通常是 libz、libreadline，或其他非标准库如 libssl。要把它指向正确位置，请在
configure 命令行中设置环境变量 LDFLAGS，例如：
configure ... LDFLAGS="-R /usr/sfw/lib:/opt/sfw/lib:/usr/local/lib"
更多信息请参见 ld 手册页。
15.7.7.4. 64 位构建有时会崩溃
在 Solaris 7 及更早版本上，64 位 libc 的 vsnprintf 例程存在缺陷，导致 PostgreSQL 不定期发生核心转储。已知最简单的解决办法是强制 PostgreSQL 使用自带的 vsnprintf，而不是库中的版本。为此，在运行 configure 后，编辑由 configure 生成的文件：在 src/Makefile.global 中，将以下行：
LIBOBJS =
改为：
LIBOBJS = snprintf.o
（此变量中可能已经列有其他文件，顺序无关紧要。）然后照常构建。
15.7.7.5. 为获得最佳性能而编译
在 SPARC 架构上，强烈推荐使用 Sun Studio 进行编译。可以尝试使用 -xO5 优化标志，以生成显著更快的二进制文件。不要使用任何会改变浮点运算行为以及 errno 处理行为的标志（例如 -fast）。这些标志可能导致 PostgreSQL 出现不符合标准的行为，例如在日期和时间计算中。
如果你没有理由在 SPARC 上使用 64 位二进制文件，那么优先选择 32 位版本。64 位运算更慢，而且 64 位二进制文件也比 32 位变体慢。另一方面，在 AMD64 CPU 家族上，32 位代码并不是原生模式，因此 32 位代码在该 CPU 家族上会明显更慢。
15.7.7.6. 使用 DTrace 跟踪 PostgreSQL
是的，可以使用 DTrace。更多信息见第 27.4 节。你还可以在这篇文章中找到更多信息：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 或更高版本。