本节记录 PostgreSQL 安装和设置时的一些平台相关附加问题。 请务必阅读安装说明，尤其是 Section 16.2。 此外，也请参阅 Chapter 32 中关于如何解释回归测试结果的说明。
这里未列出的平台，目前没有已知的平台特定安装问题。
PostgreSQL 可以在 AIX 上运行，但大约 6.1 之前的 AIX 版本存在各种问题，不建议使用。你可以使用 GCC 或原生 IBM 编译器 xlc。
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 下运行服务器。
从源码构建时，请按照 Unix 风格的安装过程操作（即 ./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 目录中。
要在 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 来绕过这一点。不过，大多数 PostgreSQL 开发者会直接关闭 SIP。
Windows 版 PostgreSQL 可以使用 MinGW（用于 Microsoft 操作系统的类 Unix 构建环境）构建，也可以使用 Microsoft 的 Visual C++ 编译器套件构建。MinGW 构建过程使用本章介绍的常规构建系统；Visual C++ 构建方式完全不同，详见 Chapter 17。
原生 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 编译器。 如果你使用的是 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 手册页。
在 SPARC 架构上，强烈推荐使用 Sun Studio 进行编译。 可以尝试使用 -xO5 优化标志，以生成显著更快的二进制文件。 不要使用任何会改变浮点运算行为以及 errno 处理行为的标志 （例如 -fast）。
如果你没有理由在 SPARC 上使用 64 位二进制，那么优先选择 32 位版本。 64 位运算更慢，而且 64 位二进制通常也比 32 位变体慢。 另一方面，在 AMD64 CPU 家族上，32 位代码并不是原生模式， 因此 32 位代码在该 CPU 家族上会明显更慢。
是的，可以使用 DTrace。更多信息见 Section 27.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 或更高版本才能使用 DTrace。