本节记录 PostgreSQL 安装和设置时的一些平台相关附加问题。 请务必阅读安装说明，尤其是 Section 16.2。 此外，也请参阅 Chapter 33 中关于如何解释回归测试结果的说明。
这里未列出的平台，目前没有已知的平台特定安装问题。
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，但运行应用程序时仍会出现内存不足或地址空间错误。例如，加载扩展可能因不寻常的错误而失败。以下是以 PostgreSQL 安装所有者身份运行的例子：
=# CREATE EXTENSION plperl; ERROR: could not load library "/opt/dbs/pgsql/lib/plperl.so": A memory address is not in the address space for the process.
以 PostgreSQL 安装所属组中非所有者的成员身份运行：
=# CREATE EXTENSION plperl; ERROR: could not load library "/opt/dbs/pgsql/lib/plperl.so": Bad address
另一个例子是 PostgreSQL 服务器日志中的内存不足错误，此时每次接近或超过 256 MB 的内存分配都会失败。
这些问题的总体原因是服务器进程使用的默认位数和内存模型。默认情况下，在 AIX 上构建的所有二进制文件都是 32 位的。这与硬件类型或所用内核无关。这些 32 位进程的内存上限为 4 GB，按几种模型之一以 256 MB 的段布局。默认情况下，堆与栈共享一个段，因此堆可用空间不足 256 MB。
对于上面的 plperl 示例，请检查你的 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 的许多其他部分一样，如果这成为问题，可以在系统或进程级别配置分页空间分配方式和内存不足时终止进程的行为。
可以使用 Cygwin 这个 Windows 上的类 Linux 环境来构建 PostgreSQL，但这种方式不如原生 Windows 构建（见 Chapter 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() 的待处理连接队列中，会导致连接被拒绝的错误或挂起。可以使用 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 源码而非发行 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 的支持站点，例如 ftp://us-ffs.external.hp.com/，免费获取最新补丁。
如果在 PA-RISC 2.0 机器上构建，并希望使用 GCC 生成 64 位二进制文件，则必须使用 64 位版本的 GCC。
如果在 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 选项。
在回归测试中，几何测试可能存在一些低位数字差异，具体取决于所用编译器和数学库的版本。任何其他错误都值得怀疑。
要在 macOS 上从源代码构建 PostgreSQL，你需要安装 Apple 的命令行开发工具， 可通过执行下列命令完成：
xcode-select --install
（注意，这会弹出一个 GUI 对话框要求确认。） 你也可以视需要另外安装 Xcode。
在较新的 macOS 版本中，需要把 “sysroot” 路径嵌入到用于查找某些系统头文件的 include 开关中。 这会导致 configure 脚本的输出， 因为 configure 时所用 SDK 版本不同而变化。 在简单场景下这通常不是问题；但如果你要做的是类似于在与服务器代码构建机器不同的 另一台机器上构建扩展，就可能需要强制使用不同的 sysroot 路径。 要这样做，请设置 PG_SYSROOT，例如：
make PG_SYSROOT=/desired/path all
要找出你机器上的合适路径，请运行：
xcrun --show-sdk-path
请注意，使用与构建核心服务器时不同的 sysroot 版本来构建扩展并不值得推荐； 最坏情况下，这可能导致难以调试的 ABI 不一致。
你也可以在配置时通过向 configure 指定 PG_SYSROOT，选择非默认的 sysroot 路径：
./configure ... PG_SYSROOT=/desired/path
这主要适用于针对其他 macOS 版本进行交叉编译。 不能保证生成的可执行文件能在当前主机上运行。
如果要完全禁止 -isysroot 选项，请使用：
./configure ... PG_SYSROOT=none
（任何不存在的路径名都可以。） 如果你希望使用非 Apple 编译器进行构建，这可能会有用，但请注意， 这种情况并未经过 PostgreSQL 开发者测试，也不受支持。
macOS 的 “System Integrity Protection”（SIP）功能会破坏 make check，因为它会阻止将所需的 DYLD_LIBRARY_PATH 设置传给被测试的可执行文件。可以在 make check 之前先执行 make install 来规避这一问题。不过，大多数 Postgres 开发者会直接关闭 SIP。
Windows 版 PostgreSQL 可以使用 MinGW（用于 Microsoft 操作系统的类 Unix 构建环境）构建，也可以使用 Microsoft 的 Visual C++ 编译器套件构建。MinGW 构建方式使用本章介绍的常规构建系统；Visual C++ 构建方式完全不同，详见 Chapter 17。后者是完全原生的构建，不使用 MinGW 等附加软件。PostgreSQL 主网站上提供现成的安装程序。
原生 Windows 移植版本要求 32 位或 64 位的 Windows 2000 或更高版本。更早的操作系统没有足够的基础设施（但可以在其上使用 Cygwin）。可以从 http://www.mingw.org/ 下载 MinGW 这一类 Unix 构建工具，以及 MSYS 这一运行 configure 等 shell 脚本所需的 Unix 工具集。运行生成的二进制文件不需要它们；只有创建二进制文件时才需要。
要使用 MinGW 构建 64 位二进制文件，请从 https://mingw-w64.org/ 安装 64 位工具集，将其 bin 目录放入 PATH，并使用 --host=x86_64-w64-mingw32 选项运行 configure。
安装好所有组件后，建议在 CMD.EXE 下运行 psql，因为 MSYS 控制台存在缓冲问题。
如果 PostgreSQL 在 Windows 上崩溃，它能够生成 minidumps，可用于追踪崩溃原因， 类似于 Unix 上的核心转储。这些转储可以使用 Windows Debugger Tools 或 Visual Studio 读取。 要在 Windows 上启用转储生成，请在集簇数据目录中创建一个名为 crashdumps 的子目录。随后，转储会以唯一名称写入该目录， 该名称基于崩溃进程的标识符以及崩溃发生时的当前时间。
PostgreSQL 在 Solaris 上有良好支持。你的操作系统越新，遇到的问题越少；详情见下文。
你可以使用 GCC 或 Sun 编译器套件来构建。为了获得更好的代码优化，在 SPARC 架构上强烈推荐使用 Sun 编译器。我们收到过使用 GCC 2.95.1 时出现问题的报告；建议使用 GCC 2.95.3 或更高版本。如果使用 Sun 编译器，请注意不要选择 /usr/ucb/cc；应使用 /opt/SUNWspro/bin/cc。
你可以从 https://www.oracle.com/technetwork/server-storage/solarisstudio/downloads/ 下载 Sun Studio。许多 GNU 工具已经集成到 Solaris 10 中，或者包含在 Solaris companion CD 中。如果你需要适用于较旧 Solaris 版本的软件包，可以到 http://www.sunfreeware.com 查找这些工具。如果你更想要源码，请看 https://www.gnu.org/prep/ftp。
如果 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 家族上会明显更慢。
是的，可以使用 DTrace。更多信息见 Section 28.5。
如果发现链接 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 或更高版本。