本节记录 PostgreSQL 安装和设置时的一些平台相关附加问题。 请务必阅读安装说明，尤其是 Section 17.1。 此外，也请参阅 Chapter 31 中关于如何解释回归测试结果的说明。
这里未列出的平台，目前没有已知的平台特定安装问题。
你可以使用 GCC，或者 IBM 的原生编译器 xlc， 在 AIX 上构建 PostgreSQL。
AIX 7.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。由于权限这样设置，只有所有者或所属组成员才能加载该库。 因为它不是 world-readable，加载器会把对象放入进程堆，而不是本应使用的共享库段。
这个问题的“理想”解决方案是使用 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 构建，且如今已不再推荐在 Cygwin 下运行服务器。
从源代码构建时，请按照 Unix 风格的安装过程（也就是 ./configure; make；等等）进行，但要注意下列 Cygwin 特有的差异：
请把路径设置成优先使用 Cygwin 的 bin 目录，而不是 Windows 工具目录。 这有助于避免编译问题。
不支持 adduser 命令；请使用 Windows 中相应的 用户管理应用。除此之外，跳过这一步即可。
不支持 su 命令；请在 Windows 上使用 ssh 来模拟 su。 除此之外，跳过这一步即可。
不支持 OpenSSL。
请启动 cygserver 以支持共享内存。 为此，请输入命令 /usr/sbin/cygserver &。每次启动 PostgreSQL 服务器或初始化数据库集簇 （initdb）时，该程序都必须在运行中。 默认的 cygserver 配置可能需要修改 （例如增大 SEMMNS），以防止 PostgreSQL 因系统资源不足而失败。
在某些使用非 C 区域设置的系统上，构建可能会失败。 要修复这一点，请在构建前执行 export LANG=C.utf8 把区域设置改为 C， 安装完 PostgreSQL 后再把它恢复为之前的设置。
并行回归测试（make check）可能会因为 listen() backlog 队列溢出而产生伪造的回归测试失败， 进而导致连接拒绝错误或挂起。你可以像下面这样使用 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。
可以使用 MinGW 这个 Windows 上的类 Unix 构建环境来构建 Windows 版 PostgreSQL。推荐为此使用 MSYS2 环境，并安装所需的前置软件包。
如果 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。
如果您发现文档中有不正确的内容、与您使用特定功能的经验不符或需要进一步说明，请使用此表单来报告文档问题。