本节记录了有关 PostgreSQL 安装和设置的其他特定于平台的问题。务必阅读安装说明，特别是 第 17.1 节。此外，请查看 第 33 章，了解回归测试结果的解释。
此处未涵盖的平台没有已知的特定于平台的安装问题。
您可以在 AIX 上使用 GCC 或本机 IBM 编译器 xlc 构建 PostgreSQL。
AIX 7.1 之前的版本不再受 PostgreSQL 社区测试或支持。
AIX 在内存管理方式方面可能有点特殊。您可能有一台服务器，其 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 的模式安装。由于权限以这种方式设置，因此只有所有者或拥有组的成员才能加载库。由于它不是世界可读的，因此加载器将对象放入进程的堆中，而不是将其放置在共享库段中（否则会将其放置在共享库段中）。
解决此问题的“理想”解决方案是使用 PostgreSQL 的 64 位版本，但这并不总是可行的，因为具有 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，并将 CC="gcc -maix64" 和 LDFLAGS="-Wl,-bbigtoc" 传递给 configure。（xlc 的选项可能有所不同。）如果您省略 OBJECT_MODE 的导出，您的构建可能会因链接器错误而失败。设置 OBJECT_MODE 时，它会告诉 AIX 的构建实用程序（如 ar、as 和 ld）默认处理哪种类型的对象。
默认情况下，可能会过度提交分页空间。虽然我们没有看到这种情况发生，但 AIX 会在内存耗尽且访问过度提交时终止进程。我们见过的最接近这种情况的是，由于系统决定没有足够的内存供另一个进程使用，因此 fork 失败。与 AIX 的许多其他部分一样，如果出现此问题，可以在系统或进程范围内配置分页空间分配方法和内存不足终止。
PostgreSQL 可以使用 Cygwin（Windows 的类 Linux 环境）构建，但该方法不如本机 Windows 构建 (参见 第 18 章)，并且不再建议在 Cygwin 下运行服务器。
从源代码构建时，请按照类 Unix 安装过程进行操作（即 ./configure; make；等），注意以下特定于 Cygwin 的差异
将您的路径设置为在 Windows 实用程序之前使用 Cygwin bin 目录。这将有助于防止编译问题。
adduser 命令不受支持；请在 Windows 上使用适当的用户管理应用程序。否则，请跳过此步骤。
不支持 su 命令；使用 ssh 在 Windows 上模拟 su。否则，跳过此步骤。
不支持 OpenSSL。
启动 cygserver 以获得共享内存支持。为此，输入命令 /usr/sbin/cygserver &。每当您启动 PostgreSQL 服务器或初始化数据库集群 (initdb) 时，都需要运行此程序。可能需要更改默认 cygserver 配置（例如，增加 SEMMNS），以防止 PostgreSQL 因系统资源不足而失败。
在使用 C 以外区域设置的某些系统上，构建可能会失败。要解决此问题，请在构建之前将区域设置设置为 C，方法是执行 export LANG=C.utf8，然后在安装 PostgreSQL 后将其设置回之前的设置。
由于溢出了 listen() 积压队列，导致连接被拒绝错误或挂起，因此并行回归测试 (make check) 可能会生成虚假的回归测试失败。您可以使用 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 不一致。
您还可以在配置时通过将 PG_SYSROOT 指定给 configure 来选择非默认 sysroot 路径
./configure ... PG_SYSROOT=/desired/path
这主要适用于为其他 macOS 版本交叉编译。无法保证生成的执行文件将在当前主机上运行。
要完全禁止 -isysroot 选项，请使用
./configure ... PG_SYSROOT=none
（任何不存在的路径名都可以）。如果你希望使用非 Apple 编译器进行构建，这可能有用，但请注意，PostgreSQL 开发人员并未测试或支持这种情况。
macOS 的 “系统完整性保护” (SIP) 功能会中断 make check，因为它会阻止将 DYLD_LIBRARY_PATH 的所需设置传递给正在测试的执行文件。你可以通过在 make check 之前执行 make install 来解决这个问题。不过，大多数 PostgreSQL 开发人员只是关闭了 SIP。
PostgreSQL for Windows 可以使用 MinGW（Microsoft 操作系统的类 Unix 构建环境）或 Microsoft 的 Visual C++ 编译器套件进行构建。MinGW 构建过程使用本章中描述的常规构建系统；Visual C++ 构建的工作方式完全不同，在 第 18 章 中进行了描述。
原生 Windows 端口需要 32 位或 64 位版本的 Windows 2000 或更高版本。早期操作系统没有足够的基础设施（但可以在这些操作系统上使用 Cygwin）。MinGW（类 Unix 构建工具）和 MSYS（运行 shell 脚本（如 configure）所需的 Unix 工具集合）可以从 http://www.mingw.org/ 下载。运行生成的二进制文件不需要这两个工具；它们仅用于创建二进制文件。
要使用 MinGW 构建 64 位二进制文件，请从 https://mingw-w64.org/ 安装 64 位工具集，将其 bin 目录放入 PATH 中，并使用 --host=x86_64-w64-mingw32 选项运行 configure。
安装好所有内容后，建议你在 CMD.EXE 下运行 psql，因为 MSYS 控制台存在缓冲问题。
如果 Windows 上的 PostgreSQL 崩溃，它有能力生成 最小转储，可用于追踪崩溃原因，类似于 Unix 上的核心转储。可以使用 Windows 调试工具 或 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 伴侣 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 位代码不是本机代码，因此在该 CPU 系列上 32 位代码明显更慢。
是的，可以使用 DTrace。有关更多信息，请参见 第 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 或更高版本才能使用 DTrace。