数据库PostrageSQL-从源代码安装

从源代码安装

本章的内容描述从源代码发布安装PostgreSQL（如果你安装的是打包好的版本如RPM或Debian包，那么请略过这一章并且阅读打包者的指导）。

16.1. 简单版

./configure
make
su
make install
adduser postgres
mkdir /usr/local/pgsql/data
chown postgres /usr/local/pgsql/data
su - postgres
/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
/usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data >logfile 2>&1 &
/usr/local/pgsql/bin/createdb test
/usr/local/pgsql/bin/psql test

本章剩余部分都是完全版。

16.2. 要求

一般说来，一个现代的与 Unix 兼容的平台应该就能运行PostgreSQL。 到发布为止已经明确测试过的平台的列表在 Section 16.6中列出。在发布的doc子目录里面有许多平台相关的FAQ文档，如果你碰到问题你可能会需要参考它们。

编译PostgreSQL需要下列软件包：

• 要求GNU make版本3.80或以上；其他的make程序或更老的GNU make版本将不会工作（GNU make有时以名字gmake安装）。要测试GNU make可以输入：make --version
• 你需要一个ISO/ANSI C 编译器（至少是 C89兼容的）。我们推荐使用最近版本的GCC，不过，众所周知的是PostgreSQL可以利用许多不同厂商的不同编译器进行编译。
• 除了gzip和bzip2之外，我们还需要tar来解包源代码发布。
• 默认时将自动使用GNU Readline库。它允许psql（PostgreSQL的命令行SQL 解释器）记住你输入的每一个命令并且允许你使用箭头键来找回和编辑之前的命令。

如果你不想用它，那么你必需给configure声明--without-readline选项。作为一种可选方案，你常常可以使用 BSD许可证的libedit库，它最初是在NetBSD上开发的。libedit库是GNU Readline兼容的， 如果没有发现libreadline或者configure使用了--with-libedit-preferred选项，都会使用这个库。如果你使用的是一个基于包的 Linux 发布，那么要注意你需要readline和readline-devel两个包，特别是如果这两个包在你的版本里是分开的时候。

• 默认的时候将使用zlib压缩库。 如果你不想使用它，那么你必须给configure声明--without-zlib选项。使用这个选项关闭了在pg_dump和pg_restore中对压缩归档的支持。

下列包是可选的。在默认配置的时候并不要求它们，但是如果打开了一些编译选项之后就需要它们了，如下文所解释的：

• 要编译服务器端编程语言PL/Perl，你需要一个完整的 Perl安装，包括libperl 库和头文件。 所需的最低版本是Perl 5.8.3。 因为PL/Perl是一个共享库， libperl库在大多数

平台上也必须是一个共享库。最近的版本的 Perl好像已经默认这样做了，但是早先的版本可不是 这样的，而且这总是一种在站点上安装 Perl 的选择。如果选择了编译 PL/Perl但是它却找不到一个共享的 libperl，那么configure将会失败。 在这种情况下，你将不得不重新手工编译并且安装Perl 以便能编译PL/Perl。在 Perl的配置处理过程中，需要一个共享库。

如果你想更多地使用PL/Perl， 你应当保证Perl安装在编译时启用了 usemultiplicity选项（perl -V将会显示是否是这样）。

• 要编译PL/Python服务器端编程语言， 你需要一个Python的安装，包括头文件和distu￾tils模块。最低的版本要求是Python 2.4。如果是版本3.1或更高版本，则支持Python 3，如果使用 Python 3 请参考Section 46.1
  因为PL/Python将以共享库的方式编译， libpython库在大多数平台上也必须是一个共享库。 在默认的从源码安装Python时不是这样的， 而是在很多操作系统发布中有一个共享库可用。如果选择了编译PL/Python但找不到一个共享的 libpython，configure将 会失败。这可能意味着你不得不安装额外的包或者（部分）重编译 Python安装以提供这个共享库。 在从源码编译时，请用–enable-shared标志运行 Python的配置脚本。
• 如果你想编译PL/Tcl过程语言， 你当然需要安装Tcl，要求的最低版本是 Tcl 8.4。
• 要打开本地语言支持（NLS），也就是说， 用英语之外的语言显示程序的消息，你需要一个Gettext API的实现。有些操作系统内置了这些（例如Linux、NetBSD、So￾laris）， 对于其它系统，你可以从http://www.gnu.org/software/gettext/下载一个额外的包。如果你在使用GNU C 库里面的Gettext实现， 那么你就额外需要GNU Gettext包，因为我们需要里面的几个工具程序。对于任何其它的实现，你应该不需要它。
• 如果您想支持加密的客户端连接，则需要OpenSSL。最低要求的版本是0.9.8。
• 如果你想支持使用Kerberos、OpenLDAP和/或PAM服务的认证，那你需要相应的包。
• 要编译PostgreSQL文档，有一些独立的要求集，请见 Section J.2。如果你正从Git树而不是使用发布的源代码包进行编译，或者你想做服务器端开发， 那么你还需要下面的包：
• 如果你需要从 Git 检出中编译，或者你修改了实际的扫描器和分析器的定义文件，那么你需要 GNU Flex和Bison。 如果你需要它们，那么确保自己拿到的是Flex 2.5.31 或更新的版本， 以及Bison 1.875 或者更新的版本。不能使用其他lex和yacc程序。
• 如果需要从 Git 检出中编译，或者你修改了任何使用 Perl 脚本的编译步骤的输入文件，那么你需要Perl 5.8.3或以后的版本。如果你在 Windows 上编译，你在任何情况下都需要Perl。运行一些测试套件时也需要Perl。
  如果你需要获取GNU包，你可以在你的本地GNU镜像站点 （看看 https://www.gnu.org/prep/ftp或者ftp://ftp.gnu.org/gnu/找到它们。
  还要检查一下你是否有足够的磁盘空间。你将大概需要近 100MB 用于存放编译过程中的源码树和大约 20 MB 用于安装目录。 一个空数据库集簇大概需要35 MB。一个数据库所占的空间大约是存储同样数据的平面文件所占空间的五倍。如果你要运行回归测试，还临时需要额外的 150MB。请用df命令检查剩余磁盘空间。

16.3. 获取源码

PostgreSQL 11.2 源代码可以从我们的官方网站 https://www.postgresql.org/download/的下载区中获得。你将得到一个名为postgresql-11.2.tar.gz或postgresql-11.2.tar.bz2的文件。在你获取文件之后，解压缩它：

gunzip postgresql-11.2.tar.gz
tar xf postgresql-11.2.tar

（如果你得到的是.bz2文件，请用bunzip2代替gunzip）。这样将在当前目录创建一个目录postgresql-11.2， 里面是PostgreSQL源代码。 进入这个目录完成安装过程的其他步骤。你也可以直接从版本控制库中获得源代码，参见Appendix I。

16.4. 安装过程

1. 配置
   安装过程的第一步就是为你的系统配置源代码树并选择你喜欢的选项。这个工作是通过运行configure脚本实现的，对于默认安装，你只需要简单地输入：

./configure

该脚本将运行一些测试来决定一些系统相关的变量， 并检测你的操作系统的特殊设置，并且最后将在编译树中创建一些文件以记录它找到了什么。如果你想保持编译目录的独立，你也可以在一个源码树之外的目录中运行configure 。这个过程也被称为一个VPATH编译。做法如下：

mkdir build_dir
cd build_dir
/path/to/source/tree/configure [options go here]
make

默认设置将编译服务器和辅助程序，还有只需要 C 编译器的所有客户端程序和接口。默认时所有文件都将安装到/usr/local/pgsql。

你可以通过给出下面的configure命令行选项中的一个或更多的选项来自定义编译和安装过程：

--prefix=PREFIX

把所有文件装在目录PREFIX中而不是/usr/local/pgsql中。 实际的文件会安装到数个子目录中；没有一个文件会直接安装到PREFIX目录里。

如果你有特殊需要，你还可以用下面的选项自定义不同的子目录的位置。 不过，如果你把这些设置保留默认，那么安装将是可重定位的，意思是你可以在安装过后移动目录（man和doc位置不受此影响）。

对于可重定位的安装，你可能需要使用configure的–disable-rpath选项。 还有，你需要告诉操作系统如何找到共享库。

--exec-prefix=EXEC-PREFIX

你可以把体系相关的文件安装到一个不同的前缀下（EXEC-PREFIX），而不是PREFIX中设置的地方。 这样做可以比较方便地在不同主机之间共享体系相关的文件。 如果你省略这些，那么EXEC-PREFIX就会被设置为等于 PREFIX并且体系相关和体系无关的文件都会安装到同一棵目录树下，这也可能是你想要的。

--bindir=DIRECTORY

为可执行程序指定目录。默认是EXEC-PREFIX/bin， 通常也就是/usr/local/pgsql/bin。

--sysconfdir=DIRECTORY

用于各种各样配置文件的目录，默认为PREFIX/etc。

--libdir=DIRECTORY

设置安装库和动态装载模块的目录。默认是EXEC-PREFIX/lib。

--includedir=DIRECTORY

C 和 C++ 头文件的目录。默认是PREFIX/include。

--datarootdir=DIRECTORY

设置多种只读数据文件的根目录。这只为后面的某些选项设置默认值。默认值为PREFIX/share。

--datadir=DIRECTORY

设置被安装的程序使用的只读数据文件的目录。默认值为DATAROOTDIR。注意这不会对你的数据库文件被放置的位置产生任何影响。

--localedir=DIRECTORY

设置安装区域数据的目录，特别是消息翻译目录文件。默认值为DATAROOTDIR/locale。

--mandir=DIRECTORY

PostgreSQL自带的手册页将安装到这个目录，它们被安装在相应的manx子目录里。默认是DATAROOTDIR/man。

--docdir=DIRECTORY

设置安装文档文件的根目录，“man”页不包含在内。这只为后续选项设置默认值。这个选项的默认值为DATAROOTDIR/doc/postgresql。

--htmldir=DIRECTORY

PostgreSQL的HTML格式的文档将被安装在这个目录中。默认值为DATAROOTDIR。

为了让PostgreSQL能够安装在一些共享的安装位置（例如/usr/local/include）， 同时又不至于和系统其它部分产生名字空间干扰，我们特别做了一些处理。 首先，安装脚本会自动给datadir、sysconfdir和docdir后面附加上“/postgresql”字符串，除非展开的完整路径名已经包含字符串“postgres”或者“pgsql”。
例如，如果你选择/usr/local作为前缀， 那么文档将安装在/usr/lo￾cal/doc/postgresql，但如果前缀是/opt/postgres， 那么它将被放到/opt/postgres/doc。客户接口的公共 C 头文件安装到了includedir，并
且是名字空间无关的。内部的头文件和服务器头文件都安装在includedir下的私有目录中。参考每种接口的文档获取关于如何访问头文件的信息。最后，如果合适，那么也会在libdir下创建一个私有的子目录用于动态可装载的模块。

--with-extra-version=STRING

把STRING追加到 PostgreSQL 版本号。例如，你可以使用它来标记从未发布的 Git快照或者包含定制补丁（带有一个如git describe标识符之类的额外版本号或者一个分发包发行号）创建的二进制文件。

--with-includes=DIRECTORIES

DIRECTORIES是一个冒号分隔的目录列表，这些目录将被加入编译器的头文件搜索列表中。 如果你有一些可选的包（例如 GNU Readline）安装在非标准位置， 你就必须使用这个选项，以及可能还有相应的 --with-libraries选项。
例子：

--with-includes=/opt/gnu/include:/usr/sup/include.
--with-libraries=DIRECTORIES

DIRECTORIES是一个冒号分隔的目录列表，这些目录是用于查找库文件的。 如果你有一些包安装在非标准位置，你可能就需要使用这个选项（以及对应的–with￾includes选项）。
例子：

--with-libraries=/opt/gnu/lib:/usr/sup/lib.
--enable-nls[=LANGUAGES]

打开本地语言支持（NLS），也就是以非英文显示程序消息的能力。LANGUAGES是一个空格分隔的语言代码列表， 表示你想支持的语言。例如–enable-nls=‘defr’ （你提供的列表和实际支持的列表之间的交集将会自动计算出来）。如果你没有声明一个列表，那么就会安装所有可用的翻译。

要使用这个选项，你需要一个Gettext API 的实现。见上文。

--with-pgport=NUMBER

把NUMBER设置为服务器和客户端的默认端口。默认是 5432。 这个端口可以在以后修改，不过如果你在这里声明，那么服务器和客户端将有相同的编译好了的默认值。这样会非常方便些。 通常选取一个非默认值的理由是你企图在同一台机器上运行多个PostgreSQL服务器。

--with-perl

制作PL/Perl服务器端编程语言。

--with-python

制作PL/Python服务器端编程语言。

--with-tcl

制作PL/Tcl服务器编程语言。

--with-tclconfig=DIRECTORY

Tcl 安装文件tclConfig.sh，其中里面包含编译与 Tcl 接口的模块的配置信息。该文件通常可以自动地在一个众所周知的位置找到，但是如果你需要一个不同版本的Tcl，你也可以指定可以找到它的目录。

--with-gssapi

编译 GSSAPI 认证支持。在很多系统上，GSSAPI（通常是 Ker￾beros 安装的一部分）系统不会被安装在默认搜索位置（例如/usr/include、/usr/lib），因此你必须使用选项–with-includes和–with-libraries来配合该选项。configure将会检查所需的头文件和库以确保你的 GSSAPI 安装足以让配置继续下去。

--with-krb-srvnam=NAME

默认的 Kerberos 服务主的名称（也被 GSSAPI 使用）。默认是postgres。通常没有理由改变这个值，除非你是一个 Windows 环境，这种情况下该名称必须被设置为大写形式POSTGRES。

--with-llvm

支持基于LLVM的JIT编译 （请参阅Chapter 32）。 这需要安装LLVM库。 当前LLVM的最低要求版本是3.9。llvm-config 可用于查找所需的编译选项。llvm-config会在PATH 上搜索所有受支持版本的llvm-config-$major-$minor。 如果那还不能找到正确的二进制文件，请使用LLVM_CONFIG指定正确的 llvm-config的路径。例如：

./configure ... --with-llvm LLVM_CONFIG='/path/to/llvm/bin/llvm-config'

LLVM支持需要兼容的clang编译器 （必要时使用CLANG环境变量指定）和有效的C++编译器 （必要时使用使用CXX环境变量指定）。

--with-icu

支持ICU库。 这需要安装ICU4C软件包。 目前要求的最低ICU4C版本是4.2。默认的，pkg-config 将被用来查找所需的编译选项。支持ICU4C版本4.6及更高版本。 对于较老版本，或者如果pkg-config不可用， 可以将变量ICU_CFLAGS和ICU_LIBS 指定为configure，就像下面的示例中那样：

./configure ... --with-icu ICU_CFLAGS='-I/some/where/include' ICU_LIBS='-
L/some/where/lib -licui18n -licuuc -licudata'

(如果ICU4C在编译器的默认搜索路径中， 那么你仍然需要指定一个非空的字符串，以避免使用pkg-config， 例如ICU_CFLAGS=’ '。)

--with-openssl

编译SSL（加密）连接支持。这个选项需要安装OpenSSL包。configure将会检查所需的头文件和库以确保你的 OpenSSL安装足以让配置继续下去。

--with-pam

编译PAM（可插拔认证模块）支持。

--with-bsd-auth

编译 BSD 认证支持（BSD 认证框架目前只在 OpenBSD 上可用）。

--with-ldap

为认证和连接参数查找编译LDAP支持 （详见Section 34.17和Section 20.10）。在Unix 上，这需要安装OpenLDAP包。在 Windows 上将使用默认的WinLDAP库。config￾ure将会检查所需的头文件和库以确保你的 OpenLDAP安装足以让配置继续下去。

--with-systemd

编译对systemd 服务通知的支持。如果服务器是在systemd 机制下被启动，这可以提高集成度，否则不会有影响 否则，; 参考 Section 18.3 查看更多信息 。要使用这个选项，必须安装libsystemd 以及相关的头文件。

--without-readline

避免使用Readline库（以及libedit）。这个选项禁用了psql中的命令行编辑和历史， 因此我们不建议这么做。

--with-libedit-preferred

更倾向于使用BSD许可证的libedit库而不是GPL许可证的Readline。这个选项只有在你同时安装了两个库时才有意义，在那种情况下默认会使用Readline。

--with-bonjour

编译 Bonjour 支持。这要求你的操作系统支持 Bonjour。在 macOS 上建议使用。

--with-uuid=LIBRARY

使用指定的 UUID 库编译uuid-ossp模块（提供生成 UUID 的函数）。 LIBRARY必须是下列之一：

• bsd，用来使用 FreeBSD、NetBSD 和一些其他 BSD 衍生系统 中的 UUID 函数
• e2fs，用来使用e2fsprogs项目创建的 UUID 库， 这个库出现在大部分的 Linux系统和 macOS 中，并且也能找到用于其他平台的 版本
• ossp，用来使用OSSP UUID library1

--with-ossp-uuid
--with-uuid=ossp的已废弃的等效选项。
--with-libxml

编译 libxml （启用 SQL/XML 支持）。这个特性需要 Libxml 版本 2.6.23 及以上。Libxml 会安装一个程序xml2-config，它可以被用来检测所需的编译器和链接器选项。如果能找到，PostgreSQL 将自动使用它。要制定一个非常用的libxml 安装位置，你可以设置环境变量XML2_CONFIG指向xml2-config程序所属的安装，或者使用选项--with-includes和--with-libraries。

--with-libxslt

编译xml2模块时使用 libxslt。xml2依赖这个库来执行XML的XSL转换。

--disable-float4-byval

禁用 float4 值的“传值”，导致它们只能被“传引用”。这个选项会损失性能，但是在需要兼容使用 C 编写并使用“ver￾sion 0”调用规范的老用户定义函数时可能需要这个选项。更好的长久解决方案是将任何这样的函数更新成使用“version 1”调用规范。

--disable-float8-byval

禁用 float8 值的“传值”，导致它们只能被“传引用”。这个选项会损失性能，但是在需要兼容使用 C 编写并使用“ver￾sion 0”调用规范的老用户定义函数时可能需要这个选项。更好的长久解决方案是将任何这样的函数更新成使用“version 1”调用规范。注意这个选项并非只影响 float8，它还影响 int8 和某些相关类型如时间戳。在32位平台上，--dis-able-float8-byval是默认选项并且不允许选择--enable-float8-byval。

--with-segsize=SEGSIZE

设置段尺寸，以 G 字节计。大型的表会被分解成多个操作系统文件，每一个的尺寸等于段尺寸。这避免了与操作系统对文件大小限制相关的问题。默认的段尺寸（1G字节）在所有支持的平台上都是安全的。如果你的操作系统有“largefile”支持（如今大部分都支持），你可以使用一个更大的段尺寸。这可以有助于在使用非常大的表时消耗的文件描述符数目。但是要当心不能选择一个超过你将使用的平台和文件系统所支持尺寸的值。你可能希望使用的其他工具（如tar）也可以对可用文件尺寸设限。如非绝对必要，我们推荐这个值应为2的幂。注意改变这个值需要一次initdb。

--with-blocksize=BLOCKSIZE

设置块尺寸，以 K 字节计。这是表内存储和I/O的单位。默认值（8K字节）适合于大多数情况，但是在特殊情况下可能其他值更有用。这个值必须是2的幂并且在 1和 32 （K字节）之间。注意修改这个值需要一次 initdb。

--with-wal-segsize=SEGSIZE

设置WAL 段尺寸，以 M 字节计。这是 WAL 日志中每一个独立文件的尺寸。调整这个值来控制传送 WAL 日志的粒度非常有用。默认尺寸为 16 M字节。这个值必须是2的幂并且在 1 到 1024 （M字节）之间。注意修改这个值需要一次 initdb。

--with-wal-blocksize=BLOCKSIZE

设置WAL 块尺寸，以 K 字节计。这是 WAL 日志存储和I/O的单位。默认值（8K 字节）适合于大多数情况，但是在特殊情况下其他值更好有用。这个值必须是2的幂并且在 1 到 64（K字节）之间。注意修改这个值需要一次 initdb。

--disable-spinlocks

即便PostgreSQL对于该平台没有 CPU 自旋锁支持，也允许编译成功。自旋锁支持的缺乏会导致较差的性能，因此这个选项只有当编译终端或者通知你该平台缺乏自旋锁支持时才应被使用。如果在你的平台上要求使用该选项来编译PostgreSQL，请将此问题报告给PostgreSQL的开发者。

--disable-strong-random

即使PostgreSQL不支持平台上的强大随机数，也允许构建成功。 一些认证协议以及pgcrypto 模块中的一些例程需要随机数的来源。–disable-strong-ran￾dom 禁用需要密码强的随机数的功能，并用弱伪随机数生成器代替验证盐值生成和查询取消密钥。 它可能会使认证安全性降低。

--disable-thread-safety

禁用客户端库的线程安全性。这会阻止libpq和ECPG程序中的并发线程安全地控制它们私有的连接句柄。

--with-system-tzdata=DIRECTORY

PostgreSQL包含它自己的时区数据库，它被用于日期和时间操作。这个时区数据库实际上是和 IANA 时区数据库相兼容的，后者在很多操作系统如 FreeBSD、Linux和Solaris上都有提供，因此再次安装它可能是冗余的。当这个选项被使用时，将不会使用DIRECTORY中系统提供的时区数据库，而是使用包括在PostgreSQL 源码发布中的时区数据库。DIRECTORY必须被指定为一个绝对路径。/usr/share/zoneinfo在某些操作系统上是一个很有可能的路径。注意安装例程将不会检测不匹配或错误的时区数据。如果你使用这个选项，建议你运行回归测试来验证你指定的时区数据能正常地工作在PostgreSQL中。

这个选项主要针对那些很了解他们的目标操作系统的二进制包发布者。使用这个选项主要优点是不管何时当众多本地夏令时规则之一改变时， PostgreSQL 包不需要被升级。另一个优点是如果时区数据库文件在安装时不需要被编译， PostgreSQL可以被更直接地交叉编译。

--without-zlib

避免使用Zlib库。这样就禁用了pg_dump和 pg_restore中对压缩归档的支持。这个选项只适用于那些没有这个库的少见的系统。

--enable-debug

把所有程序和库以带有调试符号的方式编译。这意味着你可以通过一个调试器运行程序来分析问题。 这样做显著增大了最后安装的可执行文件的大小，并且在非 GCC的编译器上，这么做通常还要关闭编译器优化， 这些都导致速度的下降。但是，如果有这些符号的话，就可以非常有效地帮助定位可能发生问题的位置。

目前，我们只是在你使用 GCC 的情况下才建议在生产安装中使用这个选项。但是如果你正在进行开发工作，或者正在使用 beta 版本，那么你就应该总是打开它。

--enable-coverage

如果在使用 GCC，所有程序和库都会用代码覆盖率测试工具编译。在运行时，它们会在编译目录中生成代码覆盖率度量的文件。详见Section 33.5。这个选项只用于GCC 以及做开发工作时。

--enable-profiling

如果在使用 GCC，所有程序和库都被编译成可以进行性能分析。在后端退出时，将会创建一个子目录，其中包含用于性能分析的gmon.out文件。这个选项只用于 GCC和做开发工作时。

--enable-cassert

打开在服务器中的assertion检查， 它会检查许多“不可能发生”的条件。它对于代码开发的用途而言是无价之宝， 不过这些测试可能会显著地降低服务器的速度。

并且，打开这个测试不会提高你的系统的稳定性！ 这些断言检查并不是按照严重性分类的，因此一些相对无害的小故障也可能导致服务器重启 — 只要它触发了一次断言失败。 目前，我们不推荐在生产环境中使用这个选项，但是如果你在做开发或者在使用 beta 版本的时候应该打开它。

--enable-depend

打开自动倚赖性跟踪。如果打开这个选项，那么制作文件（makefile）将设置为在任何头文件被修改的时候都将重新编译所有受影响的目标文件。 如果你在做开发的工作，那么这个选项很有用，但是如果你只是想编译一次并且安装，那么这就是浪费时间。 目前，这个选项只对 GCC 有用。

--enable-dtrace

为PostgreSQL编译对动态跟踪工具 DTrace 的支持。 详见Section 28.5。要指向dtrace程序，必须设置环境变量DTRACE。这通常是必需的，因为dtrace通常被安装在/usr/sbin中，该路径可能不在搜索路径中。dtrace程序的附加命令行选项可以在环境变量DTRACEFLAGS中指定。在 Solaris上，要在一个64位二进制中包括 DTrace，你必须为 configure 指定DTRACE￾FLAGS="-64"。例如，使用 GCC 编译器：

./configure CC='gcc -m64' --enable-dtrace DTRACEFLAGS='-64' ...

使用 Sun 的编译器：

./configure CC='/opt/SUNWspro/bin/cc -xtarget=native64' --enable-dtrace
 DTRACEFLAGS='-64' ...
--enable-tap-tests

启用 Perl TAP 工具进行测试。这要求安装了 Perl 以及 Perl 模块IPC::Run。 详见 Section 33.4。

如果你喜欢用那些和configure选取的不同的 C 编译器，那么你可以你的环境变量CC设置为你选择的程序。默认时，只要gcc可以使用，configure将选择它， 或者是该平台的默认（通常是cc）。类似地，你可以用CFLAGS变量覆盖默认编译器标志。你可以在configure命令行上指定环境变量， 例如：

./configure CC=/opt/bin/gcc CFLAGS='-O2 -pipe'

下面是可以以这种方式设置的有效变量的列表：

BISON
Bison程序
CC
C编译器
CFLAGS
传递给 C 编译器的选项
CLANG
clang程序的路径，用于处理使用-with-llvm 进行编译时内联的源代码。
CPP
C 预处理器
CPPFLAGS
传递给 C 预处理器的选项
CXX
C++编译器
CXXFLAGS
传给C++编译器的选项
DTRACE
dtrace程序的位置
DTRACEFLAGS
传递给dtrace程序的选项
FLEX
Flex程序
LDFLAGS
链接可执行程序或共享库时使用的选项
LDFLAGS_EX
只用于链接可执行程序的附加选项
LDFLAGS_SL
只用于链接共享库的附加选项
LLVM_CONFIG
llvm-config程序用于查找 LLVM安装。
MSGFMT
用于本地语言支持的msgfmt程序
PERL
Perl 解释器的全路径名称。这将被用来决定编译 PL/Perl 时的依赖性。
PYTHON
Python 解释器程序。这将被用来决定编译 PL/Python 时的依赖性。另外这里指定
的是 Python 2 还是 Python 3 （或者是隐式选择）决定了 PL/Python 语言的哪一种
变种将成为可用的。 详见Section 46.1。 如果未设置，则按以下顺序探测：python
python3 python2。
TCLSH
Tcl 解释器的程序。这将被用来决定编译 PL/Tcl 时的依赖性，并且它将被替换到
Tcl 脚本中。
XML2_CONFIG
用于定位 libxml 安装的xml2-config程序。
有时候，将编译器标志事后添加到由configure选择的集合中非常有用。 一个重要的例
子是，gcc的-Werror 选项不能包含在传递给configure的CFLAGS中， 因为它会中断许
多configure的内置测试。要添加这样的标志， 在运行make时将它们包含在COPT环境变
量中。 将COPT的内容添加到由configure设置的 CFLAGS和LDFLAGS中。例如，你可以这
样做
make COPT='-Werror'
或者
export COPT='-Werror'
make

在开发服务器内部代码时，我们推荐使用配置选项–enable-cassert（它会打开很多运行时错误检查）和–enable-debug（它会提高调试工具的有用性）。
如果在使用 GCC，最好使用至少-O1的优化级别来编译，因为不使用优化（-O0）会禁用某些重要的编译器警告（例如使用未经初始化的变量）。
但是，非零的优化级别会使调试更复杂，因为在编译好的代码中步进通常将不能和源代码行一一对应。如果你在尝试调试优化过的代码时觉得困惑，将感兴趣的特定文件使用-O0编译。一种简单的方式是传递一个选项给make：make PROFILE=-O0 file.o.
COPT和PROFILE环境变量同样由PostgreSQL makefile实际处理。要使用哪个是一个性能问题，但是开发者的共同习惯是将 PROFILE用于一次性的标识调整，而始终保持设置COPT。

2. 编译
   要开始编译，键入：

make

（一定要记得用GNU make）。依你的硬件而异，编译过程可能需要 5 分钟到半小时。显示的最后一行应该是：

All of PostgreSQL successfully made. Ready to install.

如果你希望编译所有能编译的东西，包括文档（HTML和手册页）以及附加模块（contrib），这样键入：make world 显示的最后一行应该是：

PostgreSQL, contrib, and documentation successfully made. Ready to install.

如果要调用另一个makefile而不是手动构建，则必须取消设置 MAKELEVEL或将其设置为零，例如这样:

build-postgresql:
 $(MAKE) -C postgresql MAKELEVEL=0 all

否则可能会导致奇怪的错误消息，通常是有关缺少头文件的消息。

3. 回归测试
   如果你想在安装文件前测试新编译的服务器， 那么你可以在这个时候运行回归测试。 回归测试是一个用于验证PostgreSQL在你的系统上是否按照开发人员设想的那样运行的测试套件。键入：

make check

（这条命令不能以 root 运行；请在非特权用户下运行该命令）。 (This won't work as root; do it as an unprivileged user.) 详细参考Chapter 33中关于如何解释测试结果的信息。你可以在以后的任何时间通过执行这条命令来运行这个测试。

4. 安装文件

如果你正在升级一套现有的系统，请阅读Section 18.6。 其中有关于升级一个集簇的指导。

要安装PostgreSQL，输入：

make install

这条命令将把文件安装到在Step 1中指定的目录。确保你有足够的权限向该区域写入。通常你需要用 root 权限做这一步。或者你也可以事先创建目标目录并且分派合适的权限。

要安装文档（HTML和手册页），输入：

make install-docs

如果你按照上面的方法编译了所有东西，输入：

make install-world

这也会安装文档。

你可以使用make install-strip代替make install， 在安装可执行文件和库文件时把它们剥离。 这样将节约一些空间。如果你编译时带着调试支持，那么抽取将有效地删除调试支持， 因此我们应该只是在不再需要调试的时候做这些事情。 install-strip力图做一些合理的工作来节约空间， 但是它并不了解如何从可执行文件中抽取每个不需要的字节， 因此，如果你希望节约所有可能节约的磁盘空间，那么你可能需要手工做些处理。

标准的安装只提供客户端应用开发和服务器端程序开发所需的所有头文件，例如用 C 写的定制函数或者数据类型（在PostgreSQL 8.0 之前，后者需要独立地执行一次make in￾stall-all-headers命令，不过现在这个步骤已经融合到标准的安装步骤中）。

只安装客户端：. 如果你只想装客户应用和接口，那么你可以用下面的命令：

make -C src/bin install
make -C src/include install
make -C src/interfaces install
make -C doc install

src/bin中有一些服务器专用的二进制文件，但是它们很小。

卸载：. 要撤销安装可以使用命令make uninstall。不过这样不会删除任何创建出来的目录。
清理：. 在安装完成以后，你可以通过在源码树里面用命令make clean删除编译文件。 这样会保留configure程序生成的文件，这样以后你就可以用make命令重新编译所有东西。 要把源码树恢复为发布时的状态，可用make distclean命令。 如果你想从同一棵源码树上为多个不同平台制作，你就一定要运行这条命令并且为每个编译重新配置（另外一种方法是在每种平台上使用一套独立的编译树，这样源代码树就可以保留不被更改）。

如果你执行了一次制作，然后发现你的configure选项是错误的， 或者你修改了任何con￾figure所探测的东西（例如，升级了软件）， 那么在重新配置和编译之前运行一下make dist clean是个好习惯。如果不这样做， 你修改的配置选项可能无法传播到所有需要变化的地方。

16.5. 安装后设置

16.5.1. 共享库

在一些有共享库的系统里，你需要告诉你的系统如何找到新安装的共享库。那些并不是必须做这个工作的系统包括 FreeBSD、HP-UX、Linux、NetBSD、OpenBSD和Solaris。设置共享库的搜索路径的方法因平台而异， 但是最广泛使用的方法是设置环境变量LD_LIBRARY_PATH，例如在 Bourne shells （sh、ksh、bash、zsh）中：

LD_LIBRARY_PATH=/usr/local/pgsql/lib
export LD_LIBRARY_PATH

或者在csh或tcsh中：setenv LD_LIBRARY_PATH /usr/local/pgsql/lib 把/usr/local/pgsql/lib换成你在Step 1时设置的–libdir。 你应该把这些命令放到 shell启动文件，如/etc/profile或~/.bash_profile中。 和这个方法相关的一些注意事项和很好的信息可以在http://xahlee.info/UnixResource_dir/_/ldpath.html找到。

在有些系统上，更好的方法可能是在编译之前设置环境变量LD_RUN_PATH。在Cygwin上，把库目录放在PATH中或者把.dll文件移动到bin目录。如果有疑问，请参考你的系统的手册页（可能是ld.so或rld）。 如果稍后你收到下面这样的消息：

psql: error in loading shared libraries
libpq.so.2.1: cannot open shared object file: No such file or directory

那么这一步就是必须的了。这个只需关注一下就是了。如果你用的系统是Linux，并且你还有 root 权限，那么你可以在安装之后运行：/sbin/ldconfig /usr/local/pgsql/lib（或者等效的目录）以便让运行时链接器更快地找到共享库。请参考ldconfig的手册页获取更多信息。在FreeBSD、NetBSD和OpenBSD上，命令是：

/sbin/ldconfig -m /usr/local/pgsql/lib

我们不知道其它的系统有等效的命令。

16.5.2. 环境变量

如果你安装到/usr/local/pgsql或者其他默认不在搜索路径中的地方， 那你应该在你的PATH环境变量里面增加一个 /usr/local/pgsql/bin（或者是你在Step 1时给选项–bindir设置的任何值） 。严格来说，这些都不是必须的，但这么做可以让你使用Post￾greSQL更方便。

要做这些事情，把下面几行加到你的 shell 启动文件，如~/.bash_profile（如果想影响所有用户就放在/etc/profile）：

PATH=/usr/local/pgsql/bin:$PATH
export PATH

如果你用的是csh或者tcsh，那么用这条命令：

set path = ( /usr/local/pgsql/bin $path )

为了让你的系统找得到man文档，你需要加类似下面的一行到一个shell启动文件里 （除非你安装到了默认搜索的位置）：

MANPATH=/usr/local/pgsql/share/man:$MANPATH
export MANPATH

环境变量PGHOST和PGPORT为客户端应用指定了数据库服务器的主机和端口， 它们会覆盖编译时的默认项。如果你想从远程运行客户端应用， 那么为每个准备使用该数据库的用户都设置PGHOST将会非常方便。但这不是必须的，而且大部分客户端程序也可以通过命令行选项替换这些设置。

16.6. 平台支持

如果代码包含规定要工作在一个平台（即一种 CPU 架构和操作系统的结合）上并且它最近已经被验证能在该平台上编译并通过其回归测试，PostgreSQL开发社区才会认为该平台是被支持的。目前，大部分平台兼容性的测试都是由PostgreSQL 编译农场2的测试机器自动完成的。如果你对在一个并没有出现在编译农场中的平台上运行PostgreSQL感兴趣，但是代码确实能够工作或者能被修改得工作，我们强烈鼓励你建立一个编译农场成员机器，这样进一步的兼容性可以被确认。

通常，PostgreSQL被期望能在这些 CPU 架构上工作：x86、 x86_64、IA64、Power￾PC、PowerPC 64、S/390、S/390x、Sparc、Sparc 64、ARM、MIPS、MIPSEL和PA-RISC。存在对 M68K、M32R 和 VAX 的代码支持，但是这些架构上并没有近期测试的报告。通常也可以在一个为支持的 CPU 类型上通过使用–disable-spinlocks配置来进行编译，但是性能将会比较差。

PostgreSQL被期望能在这些操作系统上工作： Linux（所有最近的发布）、Win￾dows（Win2000 SP4及以上）、 FreeBSD、OpenBSD、NetBSD、macOS、AIX、HP/UX 和 So￾laris。其他类 Unix 系统可能也可以工作，但是目前没有被测试。在大部分情况下，一个给定操作系统所支持的所有 CPU 架构都能工作。查找下文的Section 16.7来看是否有与你的操作系统相关的信息，特别是使用一个老的系统时更应该这样做。

如果你在一个平台上有安装问题，并且该平台根据最近的编译农场结果已经可以被支持，请将问题报告给[email protected]。如果你有兴趣将PostgreSQL移植到一个新的平台，[email protected]是一个合适的讨论它的地方。

16.7. 平台相关的说明

这一节提供了考虑 PostgreSQL 安装和设置的附加平台相关的话题。确保阅读安装指导，特别是Section 16.2。 同样，检查关于回归测试结果解释的Chapter 33这里没有覆盖的平台不存在平台相关的安装问题。

16.7.1. AIX

PostgreSQL 能在 AIX 上工作，但是正确地安装它却富有挑战性。从4.3.3到6.1的 AIX 被认为是可支持的。你可以使用 GCC 或本地 IBM 编译器xlc。通常，使用最新版本的 AIX 和PostgreSQL 能有所帮助。在编译农场中检查有关已知能工作的 AIX 版本的最新信息。

被支持的 AIX 版本的最小推荐修理级别是：

AIX 4.3.3
Maintenance Level 11 + post ML11 bundle
AIX 5.1
Maintenance Level 9 + post ML9 bundle
AIX 5.2
Technology Level 10 Service Pack 3
AIX 5.3
Technology Level 7
AIX 6.1
Base Level

要检查你当前的修理级别，在AIX 4.3.3 至 AIX 5.2 ML 7中使用 oslevel -r，或者在后面的版本中使用 oslevel -s。

如果你已经在/usr/local中安装了 Readline 或 libz，在你自己的选项之外使用下列con￾figure标志：

--with-includes=/usr/local/include --with-libraries=/usr/local/lib.

16.7.1.1. GCC问题

在 AIX 5.3 上，使用 GCC 编译和运行 PostgreSQL 有一些问题。

你将要使用 GCC 继 3.3.2 之后的一个版本，特别是如果你在使用一个打包好的版本。我们在 4.0.1 上获得了成功。早期版本的问题看起来更多地与 IBM 打包的 GCC 有关，而非 GCC真正的问题，因此如果你自己编译 GCC， 你更有可能使用早期版本的 GCC 取得成功。

16.7.1.2. Unix域套接字崩溃

AIX 5.3 有一个问题是sockaddr_storage定义得不够大。在版本 5.3中，IBM 增加了sockaddr_un（Unix域套接字的地址结构）的尺寸，但是没有相应地增加sockaddr_storage的尺寸。这样做的结果是在 PostgreSQL 中尝试使用 Unix域套接字会导致 libpq 让该数据结构溢出。 TCP/IP 连接工作正常，但是 Unix域套接字不行，这将使回归测试不能工作。

该问题已经被报告给了 IBM，并且已被记录为缺陷报告 PMR29657。如果你升级到 main￾tenance level 5300-03 或更新，将会包括这个修复。一种快速的解决方法是把/usr/in￾clude/sys/socket.h中_SS_MAXSIZE改成 1025。在两种情况中，一旦你得到了修正过的头文件，你都需要重编译 PostgreSQL。

16.7.1.3. Internet地址问题

PostgreSQL 依赖系统的getaddrinfo函数来解析listen_addresses、pg_hba.conf等中的 IP地址。旧版本的 AIX 在这个函数中有各种各样的缺陷。如果你存在与此有关的问题，更新到上文所示的合适的 AIX fix level 将会解决它。

一个用户报告：
当在 AIX 5.3 上实现 PostgreSQL 版本 8.1 时，我们会周期性地碰到问题，在其中统计收集器会“神秘地”无法成功启动。这似乎是在 IPv6 实现中意外行为的结果。看起来 Post￾greSQL 和 IPv6 无法和 AIX 5.3 一起很好地工作。

下面任意一种动作都可以“修复”该问题。

• 删除 localhost 的 IPv6 地址：

+ (as root)
# ifconfig lo0 inet6 ::1/0 delete

• 从网络服务删除 IPv6。AIX 上的/etc/netsvc.conf大概等价于 Solaris/Linux 上的/etc/nsswitch.conf。在 AIX 上的默认值因此是：

hosts=local,bind

将其换成：

hosts=local4,bind4

来使 IPv6 地址的搜索无效。

这实际上是对有关 IPv6 支持不成熟性的问题的一种变通方案，这在 AIX 5.3 发布的过程中有了显著地改进。它可以和 AIX 5.3 一起工作，但是不代表对此问题的一种华丽的解决方案。有报告称该变通方案不仅仅是多余的，还会在 AIX 6.1 上导致问题，在 AIX 6.1 中 IPv6 支持已变得更加成熟。

16.7.1.4. 内存管理

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位进程被限制在 4GB 的内存中，并被使用几种模型之一安排成 256 MB 的段。该默认值允许在堆中低于256 MB，因为它和栈共享一个单独的段。

在plperl的例子中，检查你的 umask 和你的 PostgreSQL 安装中的二进制的权限。这个例子中涉及的二进制是32位的并且被用模式 750 而不是755 安装。由于这种方式的权限设置，只有所有者或拥有组的成员可以载入该库。因为它不是所有人可读的，载入器将该对象放在进程的堆中而不是它应该被放入的共享库段中。

这个问题的“理想的”解决方案是使用 PostgreSQL 的64位编译，但是这不是总是实用的，因为有32位处理器的系统可以编译64位二进制但是却不能运行它。

如果想要一个 32 位二进制，在开始 PostgreSQL 服务器之前将LDR_CNTRL设置MAXDA￾TA=0xn0000000，其中 1 <= n <= 8，并且尝试不同的值以及postgresql.conf设置来找一个
能让你满意的配置。这种LDR_CNTRL的使用告诉 AIX 你希望服务器留出MAXDATA字节给堆，以256 MB 的段分配。当你找到了一个可工作的配置时，ldedit可以被用来修改二进制，这样它们默认使用想要的堆尺寸。PostgreSQL 也可以被重新编译，传递configure LDFLAGS="-Wl,-bmaxdata:0xn0000000"来达到相同的效果。

对于一个 64 位编译，设置OBJECT_MODE为 64 并且传递CC=“gcc -maix64"和LDFLAGS=”-Wl,-bbigtoc"给configure（给xlc的选项可能不同）。如果你省略OBJECT_MODE的输出，你的编译可能会因为链接器错误而失败。当OBJECT_MODE被设置时，它告诉 AIX 的编译工具（如ar、as和ld）默认要处理哪些对象类型。

默认情况下，过量使用页面空间的情况可能会发生。不过我们还没有看到过，当进程用尽内存并且出现了过量使用时 AIX 会杀死进程。我们见到过的最接近于此的是 fork 失败，其原因是系统觉得已经没有足够的内存给另一个进程。和AIX 的很多其他部分一样，如果这成为了一个问题，页面空间分配方法和耗尽内存导致的杀死在系统范围或进程范围是可以配置的。