登录17.7. 特定于平台的说明#
本节记录了有关 PostgreSQL 安装和设置的其他特定于平台的问题。务必阅读安装说明，特别是第 17.1 节。此外，请查看第 33 章，了解回归测试结果的解释。
此处未涵盖的平台没有已知的特定于平台的安装问题。
17.7.1. AIX#
您可以在AIX上使用 GCC 或本机 IBM 编译器xlc构建PostgreSQL。
AIX7.1 之前的版本不再受PostgreSQL社区测试或支持。
17.7.1.1. 内存管理#
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*n*0000000，其中 1 <= n <= 8，然后尝试不同的值和postgresql.conf设置，以找到令人满意的配置。这种使用LDR_CNTRL的方法告诉 AIX，您希望服务器为堆保留MAXDATA字节，并以 256 MB 段分配。当您找到可行的配置时，可以使用ldedit修改二进制文件，以便它们默认使用所需的堆大小。PostgreSQL 也可以重新构建，传递configure LDFLAGS="-Wl,-bmaxdata:0x*n*0000000"以实现相同的效果。
对于 64 位构建，将OBJECT_MODE设置为 64，并将CC="gcc -maix64"和LDFLAGS="-Wl,-bbigtoc"传递给configure。（xlc的选项可能有所不同。）如果您省略OBJECT_MODE的导出，您的构建可能会因链接器错误而失败。设置OBJECT_MODE时，它会告诉 AIX 的构建实用程序（如ar、as和ld）默认处理哪种类型的对象。
默认情况下，可能会过度提交分页空间。虽然我们没有看到这种情况发生，但 AIX 会在内存耗尽且访问过度提交时终止进程。我们见过的最接近这种情况的是，由于系统决定没有足够的内存供另一个进程使用，因此 fork 失败。与 AIX 的许多其他部分一样，如果出现此问题，可以在系统或进程范围内配置分页空间分配方法和内存不足终止。
17.7.2. Cygwin#
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中。
17.7.3. macOS#
要在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。
17.7.4. MinGW/原生 Windows#
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 控制台存在缓冲问题。
17.7.4.1. 在 Windows 上收集崩溃转储#
如果 Windows 上的 PostgreSQL 崩溃，它有能力生成最小转储，可用于追踪崩溃原因，类似于 Unix 上的核心转储。可以使用Windows 调试工具或Visual Studio读取这些转储。要在 Windows 上启用转储生成，请在群集数据目录内创建一个名为crashdumps的子目录。然后，转储将写入此目录，其唯一名称基于崩溃进程的标识符和崩溃的当前时间。
17.7.5. Solaris#
PostgreSQL 在 Solaris 上得到很好的支持。您的操作系统越新，您遇到的问题就越少。
17.7.5.1. 必需的工具#
您可以使用 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。
17.7.5.2. configure 抱怨测试程序失败#
如果configure抱怨测试程序失败，这可能是运行时链接器无法找到某个库，可能是 libz、libreadline 或其他一些非标准库，例如 libssl。要将其指向正确的位置，请在configure命令行上设置LDFLAGS环境变量，例如：
configure ... LDFLAGS="-R /usr/sfw/lib:/opt/sfw/lib:/usr/local/lib"请参阅ld手册页以了解更多信息。
17.7.5.3. 编译以获得最佳性能#
在 SPARC 架构上，强烈建议使用 Sun Studio 进行编译。尝试使用-xO5优化标志来生成明显更快的二进制文件。不要使用任何修改浮点运算和errno处理行为的标志（例如，-fast）。
如果您没有理由在 SPARC 上使用 64 位二进制文件，请使用 32 位版本。64 位操作更慢，64 位二进制文件比 32 位变体更慢。另一方面，AMD64 CPU 系列上的 32 位代码不是本机代码，因此在该 CPU 系列上 32 位代码明显更慢。
17.7.5.4. 使用 DTrace 追踪 PostgreSQL#
是的，可以使用 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。