Postgresql 中文操作指南

17.7. Platform-Specific Notes #

本节记录了有关 PostgreSQL 的安装和设置的其他特定于平台的问题。请务必阅读安装说明，尤其是 Section 17.1。此外，请查看 Chapter 33 以了解回归测试结果的解释。

This section documents additional platform-specific issues regarding the installation and setup of PostgreSQL. Be sure to read the installation instructions, and in particular Section 17.1 as well. Also, check Chapter 33 regarding the interpretation of regression test results.

未在此处涉及的平台没有已知的特定于平台的安装问题。

Platforms that are not covered here have no known platform-specific installation issues.

17.7.1. AIX #

您可以在 AIX 中使用 GCC 或本机 IBM 编译器 xlc 构建 PostgreSQL。

You can use GCC or the native IBM compiler xlc to build PostgreSQL on AIX.

PostgreSQL 社区不再测试或支持 7.1 之前的 AIX 版本。

AIX versions before 7.1 are no longer tested nor supported by the PostgreSQL community.

17.7.1.1. Memory Management #

在内存管理方面，AIX 可能会有一些特殊之处。您可能拥有一个内存中有多个千兆字节 RAM 的服务器，但在运行应用程序时仍然会遇到内存不足或地址空间错误。一个示例是加载扩展程序时出现异常错误。例如，以 PostgreSQL 安装所有者身份运行：

AIX can be somewhat peculiar with regards to the way it does memory management. You can have a server with many multiples of gigabytes of RAM free, but still get out of memory or address space errors when running applications. One example is loading of extensions failing with unusual errors. For example, running as the owner of the PostgreSQL installation:

=# 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 权限的组中的非所有者身份运行：

Running as a non-owner in the group possessing the PostgreSQL installation:

=# CREATE EXTENSION plperl;
ERROR:  could not load library "/opt/dbs/pgsql/lib/plperl.so": Bad address

另一个示例是 PostgreSQL 服务器日志中出现内存不足错误，其中所有内存分配接近或超过 256 MB 时都会失败。

Another example is out of memory errors in the PostgreSQL server logs, with every memory allocation near or greater than 256 MB failing.

所有这些问题的总体原因都是服务器进程使用的默认位数和内存模型。默认情况下，在 AIX 上构建的所有二进制文件都是 32 位的。这不依赖于正在使用的硬件类型或内核。这些 32 位进程仅限于使用几个型号之一以 256 MB 段的形式布局的 4 GB 内存。默认情况下，堆中允许小于 256 MB，因为它与堆栈共享一个段。

The overall cause of all these problems is the default bittedness and memory model used by the server process. By default, all binaries built on AIX are 32-bit. This does not depend upon hardware type or kernel in use. These 32-bit processes are limited to 4 GB of memory laid out in 256 MB segments using one of a few models. The default allows for less than 256 MB in the heap as it shares a single segment with the stack.

在 plperl 示例的情况下，以上，检查 umask 和 PostgreSQL 安装中二进制文件的权限。该示例中涉及的二进制文件是 32 位的，安装时模式为 750 而不是 755。由于权限以这种方式设置，因此只有所有者或拥有组的成员才能加载库。由于它不是世界可读的，加载器将对象放入进程堆中，而不是将其放置在共享库段中。

In the case of the plperl example, above, check your umask and the permissions of the binaries in your PostgreSQL installation. The binaries involved in that example were 32-bit and installed as mode 750 instead of 755. Due to the permissions being set in this fashion, only the owner or a member of the possessing group can load the library. Since it isn’t world-readable, the loader places the object into the process' heap instead of the shared library segments where it would otherwise be placed.

对此问题的“理想”解决方案是使用 64 位 PostgreSQL 构建，但这并不总是可行的，因为具有 32 位处理器的系统可以构建但无法运行 64 位二进制文件。

The “ideal” solution for this is to use a 64-bit build of PostgreSQL, but that is not always practical, because systems with 32-bit processors can build, but not run, 64-bit binaries.

如果需要 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" 以实现相同的效果。

If a 32-bit binary is desired, set LDR_CNTRL to MAXDATA=0x_n_0000000, where 1 ⇐ n ⇐ 8, before starting the PostgreSQL server, and try different values and postgresql.conf settings to find a configuration that works satisfactorily. This use of LDR_CNTRL tells AIX that you want the server to have MAXDATA bytes set aside for the heap, allocated in 256 MB segments. When you find a workable configuration, ldedit can be used to modify the binaries so that they default to using the desired heap size. PostgreSQL can also be rebuilt, passing configure LDFLAGS="-Wl,-bmaxdata:0x_n_0000000" to achieve the same effect.

对于 64 位构建，将 OBJECT_MODE 设置为 64，并将 CC="gcc -maix64" 和 LDFLAGS="-Wl,-bbigtoc" 传递给 configure。（xlc 选项可能有所不同。）如果您省略 OBJECT_MODE 的导出，您的构建可能会因链接器错误而失败。设置 OBJECT_MODE 时，它会告诉 AIX 的构建实用程序，例如 ar、as 和 ld，默认处理哪种类型的对象。

For a 64-bit build, set OBJECT_MODE to 64 and pass CC="gcc -maix64" and LDFLAGS="-Wl,-bbigtoc" to configure. (Options for xlc might differ.) If you omit the export of OBJECT_MODE, your build may fail with linker errors. When OBJECT_MODE is set, it tells AIX’s build utilities such as ar, as, and ld what type of objects to default to handling.

默认情况下，分页空间可能过度提交。虽然我们没有看到这种情况发生，但 AIX 会在内存不足且访问过度提交时终止进程。我们所见最接近的情况是由于系统决定没有足够的内存供另一个进程使用，因此导致 fork 失败。与 AIX 的许多其他部分一样，如果出现此问题，则可以在系统或全进程范围内配置分页空间分配方法和内存不足终止。

By default, overcommit of paging space can happen. While we have not seen this occur, AIX will kill processes when it runs out of memory and the overcommit is accessed. The closest to this that we have seen is fork failing because the system decided that there was not enough memory for another process. Like many other parts of AIX, the paging space allocation method and out-of-memory kill is configurable on a system- or process-wide basis if this becomes a problem.

17.7.2. Cygwin #

PostgreSQL 可以在类 Linux 的 Windows 环境 Cygwin 中构建，但这种方法不如本机 Windows 构建（请参见 Chapter 18），而且不再建议在 Cygwin 下运行服务器。

PostgreSQL can be built using Cygwin, a Linux-like environment for Windows, but that method is inferior to the native Windows build (see Chapter 18) and running a server under Cygwin is no longer recommended.

从源代码构建时，请按照 Unix 风格的安装过程进行（即 ./configure; make；等），注意以下 Cygwin 特有的差异：

When building from source, proceed according to the Unix-style installation procedure (i.e., ./configure; make; etc.), noting the following Cygwin-specific differences:

可以将 cygserver 和 PostgreSQL 服务器安装为 Windows NT 服务。有关如何执行此操作的信息，请参阅 Cygwin 中的 PostgreSQL 二进制包附带的 README 文档。它安装在 /usr/share/doc/Cygwin 目录中。

It is possible to install cygserver and the PostgreSQL server as Windows NT services. For information on how to do this, please refer to the README document included with the PostgreSQL binary package on Cygwin. It is installed in the directory /usr/share/doc/Cygwin.

17.7.3. macOS #

要在 macOS 上从源代码构建 PostgreSQL，您需要安装 Apple 的命令行开发人员工具，可以通过发出以下命令来完成：

To build PostgreSQL from source on macOS, you will need to install Apple’s command line developer tools, which can be done by issuing

xcode-select --install

（请注意，这将弹出一个 GUI 对话框窗口进行确认）。您可能希望安装 Xcode 也可能不希望。

(note that this will pop up a GUI dialog window for confirmation). You may or may not wish to also install Xcode.

在最近的 macOS 版本中，有必要将“sysroot”路径嵌入包含开关中，以查找一些系统头文件。这导致 configure 脚本的输出因配置期间使用的 SDK 版本而异。在简单的情况下不应造成任何问题，但如果您尝试在与服务器代码构建的机器不同的机器上构建扩展程序，则可能需要强制使用不同的 sysroot 路径。要执行此操作，请设置 PG_SYSROOT，例如

On recent macOS releases, it’s necessary to embed the “sysroot” path in the include switches used to find some system header files. This results in the outputs of the configure script varying depending on which SDK version was used during configure. That shouldn’t pose any problem in simple scenarios, but if you are trying to do something like building an extension on a different machine than the server code was built on, you may need to force use of a different sysroot path. To do that, set PG_SYSROOT, for example

make PG_SYSROOT=/desired/path all

要在您的机器上查找适当的路径，请运行

To find out the appropriate path on your machine, run

xcrun --show-sdk-path

请注意，强烈不推荐使用与构建核心服务器所用不同的 sysroot 版本来构建扩展；最坏的情况下，这会导致难以调试的 ABI 不一致。

Note that building an extension using a different sysroot version than was used to build the core server is not really recommended; in the worst case it could result in hard-to-debug ABI inconsistencies.

您还可以在配置时通过指定 PG_SYSROOT 来配置选择一个非默认 sysroot 路径：

You can also select a non-default sysroot path when configuring, by specifying PG_SYSROOT to configure:

./configure ... PG_SYSROOT=/desired/path

这样做主要适用于跨编译到其他某些 macOS 版本。不保证最终的可执行文件将在当前主机上运行。

This would primarily be useful to cross-compile for some other macOS version. There is no guarantee that the resulting executables will run on the current host.

要全部禁止 -isysroot 选项，请使用

To suppress the -isysroot options altogether, use

./configure ... PG_SYSROOT=none

（任何不存在的路径名都可以使用）。如果您希望使用非 Apple 编译器进行构建，这可能很有用，但请注意，PostgreSQL 开发人员不对此种情况进行测试或提供支持。

(any nonexistent pathname will work). This might be useful if you wish to build with a non-Apple compiler, but beware that that case is not tested or supported by the PostgreSQL developers.

macOS 的“系统完整性保护”（SIP）功能会破坏 make check，因为它会阻止将 DYLD_LIBRARY_PATH 的所需设置传递到正在测试的可执行文件。您可以在 make check 之前执行 make install 来解决此问题。不过，大多数 PostgreSQL 开发人员只是关闭了 SIP。

macOS’s “System Integrity Protection” (SIP) feature breaks make check, because it prevents passing the needed setting of DYLD_LIBRARY_PATH down to the executables being tested. You can work around that by doing make install before make check. Most PostgreSQL developers just turn off SIP, though.

17.7.4. MinGW/Native Windows #

适用于 Windows 的 PostgreSQL 可以使用 Unix 风格的构建环境 MinGW 构建，也可以使用 Microsoft 的 Visual C 编译器套件构建。 MinGW 构建过程使用本章中描述的正常构建系统； Visual C 构建的工作方式完全不同，并且在 Chapter 18 中进行了描述。

PostgreSQL for Windows can be built using MinGW, a Unix-like build environment for Microsoft operating systems, or using Microsoft’s Visual C compiler suite. The MinGW build procedure uses the normal build system described in this chapter; the Visual C build works completely differently and is described in Chapter 18.

本机 Windows 端口需要 32 或 64 位版本的 Windows 2000 或更高版本。早期的操作系统没有足够的基础架构（但在这些操作系统上可以使用 Cygwin）。 Unix 风格的构建工具 MinGW 以及 MSYS（一个运行 shell 脚本（如 configure）所需的 Unix 工具集合）可以从 http://www.mingw.org/下载。结果的二进制文件不需要它们中的任何一个；仅在构建二进制文件时需要它们。

The native Windows port requires a 32 or 64-bit version of Windows 2000 or later. Earlier operating systems do not have sufficient infrastructure (but Cygwin may be used on those). MinGW, the Unix-like build tools, and MSYS, a collection of Unix tools required to run shell scripts like configure, can be downloaded from http://www.mingw.org/. Neither is required to run the resulting binaries; they are needed only for creating the binaries.

若要使用 MinGW 构建 64 位二进制文件，请从 https://mingw-w64.org/安装 64 位工具集，将其 bin 目录放到 PATH_中，然后使用 _—host=x86_64-w64-mingw32_选项运行 _configure。

To build 64 bit binaries using MinGW, install the 64 bit tool set from https://mingw-w64.org/, put its bin directory in the PATH, and run configure with the —host=x86_64-w64-mingw32 option.

安装好所有内容后，建议您在 CMD.EXE 下运行 psql，因为 MSYS 控制台有缓冲问题。

After you have everything installed, it is suggested that you run psql under CMD.EXE, as the MSYS console has buffering issues.

17.7.4.1. Collecting Crash Dumps on Windows #

如果 Windows 上的 PostgreSQL 崩溃，它能够生成最小转储，该转储可用于追踪崩溃原因，类似于 Unix 上的核心转储。可以使用 Windows 调试器工具或 Visual Studio 读取这些转储。要在 Windows 上启用转储生成，请在群集数据目录中创建一个名为 crashdumps 的子目录。然后转储将写入此目录中，其唯一名称基于崩溃进程的标识符和崩溃的当前时间。

If PostgreSQL on Windows crashes, it has the ability to generate minidumps that can be used to track down the cause for the crash, similar to core dumps on Unix. These dumps can be read using the Windows Debugger Tools or using Visual Studio. To enable the generation of dumps on Windows, create a subdirectory named crashdumps inside the cluster data directory. The dumps will then be written into this directory with a unique name based on the identifier of the crashing process and the current time of the crash.

17.7.5. Solaris #

PostgreSQL 在 Solaris 上得到了很好的支持。您的操作系统越新，您遇到的问题就越少。

PostgreSQL is well-supported on Solaris. The more up to date your operating system, the fewer issues you will experience.

17.7.5.1. Required Tools #

您可以使用 GCC 或 Sun 的编译器套件进行构建。为了更好的代码优化，强烈建议在 SPARC 架构上使用 Sun 的编译器。如果您正在使用 Sun 的编译器，请注意不要选择 /usr/ucb/cc；请使用 /opt/SUNWspro/bin/cc。

You can build with either GCC or Sun’s compiler suite. For better code optimization, Sun’s compiler is strongly recommended on the SPARC architecture. If you are using Sun’s compiler, be careful not to select /usr/ucb/cc; use /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。

You can download Sun Studio from https://www.oracle.com/technetwork/server-storage/solarisstudio/downloads/. Many GNU tools are integrated into Solaris 10, or they are present on the Solaris companion CD. If you need packages for older versions of Solaris, you can find these tools at http://www.sunfreeware.com. If you prefer sources, look at https://www.gnu.org/prep/ftp.

17.7.5.2. configure Complains About a Failed Test Program #

如果 configure 抱怨测试程序失败，那么这可能是运行时链接程序无法找到某个库，可能是 libz、libreadline 或其他一些非标准库，例如 libssl。要将其指向正确的位置，请在 configure 命令行中设置 LDFLAGS 环境变量，例如：

If configure complains about a failed test program, this is probably a case of the run-time linker being unable to find some library, probably libz, libreadline or some other non-standard library such as libssl. To point it to the right location, set the LDFLAGS environment variable on the configure command line, e.g.,

configure ... LDFLAGS="-R /usr/sfw/lib:/opt/sfw/lib:/usr/local/lib"

有关详细信息，请参阅 ld 手册页。

See the ld man page for more information.

17.7.5.3. Compiling for Optimal Performance #

在 SPARC 架构上，强烈建议使用 Sun Studio 进行编译。尝试使用 -xO5 优化标志来生成明显更快的二进制文件。不要使用任何修改浮点运算行为和 errno 处理的标志（例如，-fast）。

On the SPARC architecture, Sun Studio is strongly recommended for compilation. Try using the -xO5 optimization flag to generate significantly faster binaries. Do not use any flags that modify behavior of floating-point operations and errno processing (e.g., -fast).

如果您没有理由在 SPARC 上使用 64 位二进制文件，请首选 32 位版本。64 位运算较慢，64 位二进制文件比 32 位变体更慢。另一方面，AMD64 CPU 系列上的 32 位代码不是本机的，因此在该 CPU 系列上，32 位代码明显较慢。

If you do not have a reason to use 64-bit binaries on SPARC, prefer the 32-bit version. The 64-bit operations are slower and 64-bit binaries are slower than the 32-bit variants. On the other hand, 32-bit code on the AMD64 CPU family is not native, so 32-bit code is significantly slower on that CPU family.

17.7.5.4. Using DTrace for Tracing PostgreSQL #

是的，可以使用 DTrace。有关更多信息，请参见 Section 28.5。

Yes, using DTrace is possible. See Section 28.5 for further information.

如果看到 postgres 可执行文件链接中止并伴随以下错误消息：

If you see the linking of the postgres executable abort with an error message like:

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。

your DTrace installation is too old to handle probes in static functions. You need Solaris 10u4 or newer to use DTrace.