pgsql.cc 提供对 postgresql.org 官网内容的中文翻译，由 Pigsty 团队维护。
本节记录关于 PostgreSQL 安装和设置的其他平台特定问题。请务必 同时阅读安装说明，尤其是 第 15.2 节。 另外，关于回归测试结果的解释，请查阅 第 30 章。
这里未列出的平台，目前没有已知的平台特定安装问题。
PostgreSQL 可以在 AIX 上工作，但要正确安装可能颇有挑战。 AIX 4.3.3 到 6.1 版本被视为受支持。你可以使用 GCC 或 IBM 原生 编译器 xlc。一般而言，使用较新版本的 AIX 和 PostgreSQL 会有帮助。 关于哪些 AIX 版本已知可以工作，请查看构建农场获取最新信息。
对于受支持的 AIX 版本，建议至少达到以下修复级别：
维护级别 11，加上 ML11 后续补丁包
维护级别 9，加上 ML9 后续补丁包
技术级别 10，服务包 3
技术级别 7
基础级别
要检查当前修复级别，在 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。
在 AIX 5.3 上，使用 GCC 编译和运行 PostgreSQL 曾出现一些问题。
应使用晚于 3.3.2 的 GCC 版本，尤其是在使用预打包版本时。我们使用 4.0.1 的效果很好。较早版本的问题似乎更多与 IBM 打包 GCC 的方式有关，而非 GCC 本身的问题，因此如果自行编译 GCC，使用较早版本的 GCC 也很可能成功。
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。
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 上，这种做法不仅没有必要，还会导致问题。
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 的许多其他部分一样，如果这成为问题，可以在系统或进程级别配置分页空间分配方式和内存不足时终止进程的行为。
“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.
可以使用 Cygwin 这个 Windows 上的类 Linux 环境来构建 PostgreSQL，但这种方式不如原生 Windows 构建 （见 第 16 章）， 如今已不再推荐。
从源码构建时，请按照常规安装过程操作（即 ./configure; make 等），同时注意以下 Cygwin 特有的差异：
请把路径设置成优先使用 Cygwin 的 bin 目录，而不是 Windows 工具目录。这有助于避免编译问题。
GNU make 命令叫做 make，而不是 gmake。
不支持 adduser 命令；请使用 Windows NT、 2000 或 XP 中相应的用户管理应用。如果不是这些系统，则跳过 此步骤。
不支持 su 命令；请在 Windows NT、2000 或 XP 上使用 ssh 模拟 su。如果不是这些系统，则跳过此步骤。
不支持 OpenSSL。
启动 cygserver 以获得共享内存支持。为此， 可输入命令 /usr/sbin/cygserver &。每当你启动 PostgreSQL 服务器或初始化数据库 群集（initdb）时，该程序都必须处于运行 状态。默认的 cygserver 配置可能需要修改 （例如增大 SEMMNS），以防止 PostgreSQL 因 系统资源不足而失败。
并行回归测试（make check）可能因 listen() 积压队列溢出而产生虚假的回归 测试失败，导致连接被拒绝错误或挂起。你可以用 make 变量 MAX_CONNECTIONS 来限制连接数，如下所示：
make MAX_CONNECTIONS=5 check
（在某些系统上，最多可以有约 10 个并发连接。）
可以把 cygserver 和 PostgreSQL 服务器安装为 Windows NT 服务。关于具体做法，请参阅 Cygwin 上 PostgreSQL 二进制包附带的 README 文档。它安装在 /usr/share/doc/Cygwin 目录中。
如果系统补丁级别和构建工具合适，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 源码而不是发布 tarball 构建，还需要 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 开关。
在回归测试中，几何测试可能存在一些低位数字差异，具体取决于所用编译器和数学库的版本。任何其他错误都值得怀疑。
据报告，PostgreSQL 已在 MIPS r8000、r10000（ip25 和 ip27） 和 r12000（ip35）处理器上成功运行，操作系统为 IRIX 6.5.5m、 6.5.12、6.5.13 和 6.5.26，使用的 MIPSPro 编译器版本为 7.30、 7.3.1.2m、7.3 和 7.4.4m。
你需要 MIPSPro 完整 ANSI C 编译器。用 GCC 构建会存在问题。 这是一个已知的 GCC 缺陷（截至 3.0 版仍未修复），与使用返回 某些类型结构的函数有关。此缺陷影响 inet_ntoa、inet_lnaof、inet_netof、inet_makeaddr 和 semctl 等函数。据说可以通过强制代码把这些 函数与 libgcc 链接来修复，但尚未经过测试。
据了解，MIPSPro 编译器 7.4.1m 版会生成不正确的代码。症状是 尝试启动数据库时出现“invalid primary checkpoint record”。）7.4.4m 版没有问题；中间版本的状态不确定。
可能会出现如下编译问题：
cc-1020 cc: ERROR File = pqcomm.c, Line = 427
The identifier "TCP_NODELAY" is undefined.
if (setsockopt(port->sock, IPPROTO_TCP, TCP_NODELAY,
某些版本把 TCP 定义放在 sys/xti.h 中， 因此需要把 #include <sys/xti.h> 加入 src/backend/libpq/pqcomm.c 和 src/interfaces/libpq/fe-connect.c。如果你遇到了 这个问题，请告知我们，以便我们开发正式的修复。
在回归测试中，几何测试可能存在一些低位数字差异，具体取决于 你使用的 FPU。任何其他错误都值得怀疑。
Windows 版 PostgreSQL 可以用 MinGW（一个用于 Microsoft 操作 系统的类 Unix 构建环境）构建，也可以使用 Microsoft 的 Visual C++ 编译器套件构建。 MinGW 构建变体使用本章所述的常规构建系统；Visual C++ 构建 的方式则完全不同，其说明见 第 16 章。 那是完全原生的构建，不使用 MinGW 之类的额外软件。主 PostgreSQL 网站上提供现成的安装程序。
原生 Windows 移植要求 32 位或 64 位的 Windows 2000 或更高 版本。更早的操作系统没有足够的基础设施（但在那些系统上可以 使用 Cygwin）。MinGW（类 Unix 构建工具）和 MSYS（运行 configure 等 shell 脚本所需的 Unix 工具集） 可从 http://www.mingw.org/ 下载。运行 构建出的二进制文件并不需要它们；它们只在创建二进制文件时 需要。
一切安装完毕后，建议在 CMD.EXE 下运行 psql，因为 MSYS 控制台存在缓冲 问题。
PostgreSQL 可以在 SCO UnixWare 7 和 SCO OpenServer 5 上构建。 在 OpenServer 上，你可以使用 OpenServer Development Kit，也可以使用 Universal Development Kit。不过，可能需要按下面的说明做一些调整。
你应当找到你的 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 也是如此。
你需要使用 GNU Make 程序，它在 Skunkware CD 上。默认情况下， 它安装为 /usr/local/bin/make。为避免与 SCO 的 make 程序混淆，你可以把 GNU make 改名为 gmake。
从 UnixWare 7.1.3 开始，GNU Make 程序位于 UDK CD 的 OSTK 部分，即 /usr/gnu/bin/gmake。
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
如果你在 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"
默认情况下，PostgreSQL 的手册页安装到 /usr/local/pgsql/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/man
在 OpenServer 上，要让手册页可用还需要额外花些功夫研究，因为其 手册系统与其他平台有些不同。目前，PostgreSQL 完全不会安装它们。
对于早于 OpenUNIX 8.0.0（UnixWare 7.1.2）所附编译器的版本 （包括 7.1.1b 特性补充），你可能需要在 CFLAGS 或 CC 环境变量中指定 -Xb。 其征兆是编译 tuplesort.c 时出现引用内联 函数的错误。显然 7.1.2（8.0.0）及之后的编译器有了变化。
对于线程，你必须在所有 使用 libpq 的程序上使用 -Kpthread。libpq 使用 pthread_* 调用，而这些调用只有加上 -Kpthread/-Kthread> 标志才可用。
PostgreSQL 在 Solaris 上有良好支持。你的操作系统越新，遇到的问题越少；详情见下文。
请注意，Solaris 10（自 update 2 起）捆绑了 PostgreSQL。官方 软件包还可从 http://pgfoundry.org/projects/solarispackages/ 获取。较旧 Solaris 版本（8、9）的软件包可以从 http://www.sunfreeware.com/ 或 http://www.blastwave.org/ 获得。
你可以用 GCC 或 Sun 的编译器套件构建。为了更好的代码优化， 在 SPARC 架构上强烈推荐使用 Sun 的编译器。我们听说过使用 GCC 2.95.1 出现问题的报告；建议使用 gcc 2.95.3 或更高版本。 如果你使用 Sun 的编译器，注意不要选择 /usr/ucb/cc，而应使用 /opt/SUNWspro/bin/cc。
你可以从 http://developers.sun.com/sunstudio/downloads/ 下载 Sun Studio。许多 GNU 工具已集成到 Solaris 10 中，或者 位于 Solaris 伴侣 CD 上。如果你需要面向较旧 Solaris 版本的 软件包，可以在 http://www.sunfreeware.com 或 http://www.blastwave.org 找到这些工具。 如果你更愿意使用源码，请看 http://www.gnu.org/order/ftp.html。
在以 OpenSSL 支持构建 PostgreSQL 时，你可能会在以下文件中遇到编译错误：
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。
如果 configure 抱怨测试程序失败，这很可能 是运行时链接器找不到某个库——可能是 libz、libreadline 或其他 非标准库（如 libssl）。要让链接器指向正确的位置，请在 configure 命令行上设置 LDFLAGS 环境变量，例如：
configure ... LDFLAGS="-R /usr/sfw/lib:/opt/sfw/lib:/usr/local/lib"
更多信息参见 ld 手册页。
在 Solaris 7 及更早版本上，64 位 libc 的 vsnprintf 例程存在缺陷，导致 PostgreSQL 不定期发生核心转储。已知最简单的解决办法是强制 PostgreSQL 使用自带的 vsnprintf，而不是库中的版本。为此，在运行 configure 后，编辑由 configure 生成的文件：在 src/Makefile.global 中，将以下行：
LIBOBJS =
改为：
LIBOBJS = snprintf.o
（此变量中可能已经列有其他文件，顺序无关紧要。）然后照常构建。
在 SPARC 架构上，强烈推荐使用 Sun Studio 进行编译。可以尝试使用 -xO5 优化标志，以生成显著更快的二进制文件。不要使用任何会改变浮点运算行为以及 errno 处理行为的标志（例如 -fast）。这些标志可能导致 PostgreSQL 出现不符合标准的行为，例如在日期和时间计算中。
如果你没有理由在 SPARC 上使用 64 位二进制文件，那么优先选择 32 位版本。64 位运算更慢，而且 64 位二进制文件也比 32 位变体慢。另一方面，在 AMD64 CPU 家族上，32 位代码并不是原生模式，因此 32 位代码在该 CPU 家族上会明显更慢。
关于为性能调优 PostgreSQL 和 Solaris 的一些技巧，可参见 http://www.sun.com/servers/coolthreads/tnb/applications_postgresql.jsp。 这篇文章主要针对 T2000 平台，但其中许多建议对其他运行 Solaris 的硬件同样有用。
是的，可以使用 DTrace。更多信息参见 第 27.4 节。 你还可以在这篇文章中找到更多信息： http://blogs.sun.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 gmake: *** [postgres] Error 1
说明你的 DTrace 安装太旧，无法处理静态函数中的探针。 你需要 Solaris 10u4 或更新版本。
译文有误、术语不当或页面显示问题，请到译文仓库 pgsty/pgdoc 报告译文问题。 英文原文本身的问题，请在当前版本的对应页面向上游反馈；上游不再修订已结束维护的版本。