Postgresql 中文操作指南
17.7. Platform-Specific Notes #
本节记录了有关 PostgreSQL 的安装和设置的其他特定于平台的问题。 请务必阅读安装说明，尤其是 Section 17.1。 此外，请查看 Chapter 33 以了解回归测试结果的解释。
未在此处涉及的平台没有已知的特定于平台的安装问题。
17.7.1. AIX #
您可以在 AIX 中使用 GCC 或本机 IBM 编译器 xlc 构建 PostgreSQL。
PostgreSQL 社区不再测试或支持 7.1 之前的 AIX 版本。
17.7.1.1. Memory Management #
在内存管理方面，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 位进程仅限于使用几个型号之一以 256 MB 段的形式布局的 4 GB 内存。默认情况下，堆中允许小于 256 MB，因为它与堆栈共享一个段。
在 plperl 示例的情况下，以上，检查 umask 和 PostgreSQL 安装中二进制文件 的权限。该示例中涉及的二进制文件是 32 位的，安装时模式为 750 而不是 755。由于权限以这种方式设置，因此只有所有者或拥有组的成员才能加载库。由于它不是世界可读的，加载器将对象放入进程堆中，而不是将其放置在共享库段中。
对此问题的“理想”解决方案是使用 64 位 PostgreSQL 构建，但这并不总是可行的，因为具有 32 位处理器的系统可以构建但无法运行 64 位二进制文件。
如果需要 32 位二进制文件，请在启动 PostgreSQL 服务器之前将 LDR_CNTRL 设置为 MAXDATA=0x_n_0000000，其中 1 ⇐ n ⇐ 8，并尝试不同的值和 postgresql.conf 设置以找到令人满意的配置。使用 LDR_CNTRL 告诉 AIX 您希望服务器每 256 MB 段分配 MAXDATA 字节给堆，以该数量分配。当您找到可行的配置时，可以使用 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 可以在类 Linux 的 Windows 环境 Cygwin 中构建，但这种方法不如本机 Windows 构建（请参见 Chapter 18），而且不再建议在 Cygwin 下运行服务器。
从源代码构建时，请按照 Unix 风格的安装过程进行（即 ./configure; make；等），注意以下 Cygwin 特有的差异：
可以将 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”路径嵌入包含开关中，以查找一些系统头文件。这导致 configure 脚本的输出因配置期间使用的 SDK 版本而异。在简单的情况下不应造成任何问题，但如果您尝试在与服务器代码构建的机器不同的机器上构建扩展程序，则可能需要强制使用不同的 sysroot 路径。要执行此操作，请设置 PG_SYSROOT，例如
make PG_SYSROOT=/desired/path all要在您的机器上查找适当的路径，请运行
xcrun --show-sdk-path请注意，强烈不推荐使用与构建核心服务器所用不同的 sysroot 版本来构建扩展；最坏的情况下，这会导致难以调试的 ABI 不一致。
您还可以在配置时通过指定 PG_SYSROOT 来配置选择一个非默认 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/Native Windows #
适用于 Windows 的 PostgreSQL 可以使用 Unix 风格的构建环境 MinGW 构建，也可以使用 Microsoft 的 Visual C 编译器套件构建。 MinGW 构建过程使用本章中描述的正常构建系统； Visual C 构建的工作方式完全不同，并且在 Chapter 18 中进行了描述。
本机 Windows 端口需要 32 或 64 位版本的 Windows 2000 或更高版本。 早期的操作系统没有足够的基础架构（但在这些操作系统上可以使用 Cygwin）。 Unix 风格的构建工具 MinGW 以及 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. Collecting Crash Dumps on Windows #
如果 Windows 上的 PostgreSQL 崩溃，它能够生成最小转储，该转储可用于追踪崩溃原因，类似于 Unix 上的核心转储。可以使用 Windows 调试器工具或 Visual Studio 读取这些转储。要在 Windows 上启用转储生成，请在群集数据目录中创建一个名为 crashdumps 的子目录。然后转储将写入此目录中，其唯一名称基于崩溃进程的标识符和崩溃的当前时间。
17.7.5. Solaris #
PostgreSQL 在 Solaris 上得到了很好的支持。您的操作系统越新，您遇到的问题就越少。
17.7.5.1. Required Tools #
您可以使用 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 Complains About a Failed Test Program #
如果 configure 抱怨测试程序失败，那么这可能是运行时链接程序无法找到某个库，可能是 libz、libreadline 或其他一些非标准库，例如 libssl。要将其指向正确的位置，请在 configure 命令行中设置 LDFLAGS 环境变量，例如：
configure ... LDFLAGS="-R /usr/sfw/lib:/opt/sfw/lib:/usr/local/lib"有关详细信息，请参阅 ld 手册页。
17.7.5.3. Compiling for Optimal Performance #
在 SPARC 架构上，强烈建议使用 Sun Studio 进行编译。尝试使用 -xO5 优化标志来生成明显更快的二进制文件。不要使用任何修改浮点运算行为和 errno 处理的标志（例如，-fast）。
如果您没有理由在 SPARC 上使用 64 位二进制文件，请首选 32 位版本。64 位运算较慢，64 位二进制文件比 32 位变体更慢。另一方面，AMD64 CPU 系列上的 32 位代码不是本机的，因此在该 CPU 系列上，32 位代码明显较慢。
17.7.5.4. Using DTrace for Tracing PostgreSQL #
是的，可以使用 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 安装版本太旧，无法处理静态函数中的 probes。你需要使用 Solaris 10u4 或更新版本才能使用 DTrace。