15.4. 安装过程 #
配置
安装过程的第一步是为你的系统配置源码树,并选择所需选项。这通过运行以下脚本完成:
configure。对于默认安装,只需输入:./configure此脚本会运行一系列测试,确定各个依赖系统的变量的值,并检测操作系统的特殊之处,最后在构建树中创建若干文件来记录结果。你也可以运行
configure时使用源码树之外的目录,以将构建目录单独存放。这种过程也称为 VPATH 构建。方法如下:mkdir build_dircd 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你可以把与体系结构相关的文件安装到与
PREFIX不同的前缀EXEC-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=DIRECTORYPostgreSQL 附带的手册页将安装到这个目录下各自对应的
man子目录中。默认是x。DATAROOTDIR/man--docdir=DIRECTORY设置安装文档文件(不包括 “man” 页)的根目录。这只会为后续选项设置默认值。该选项的默认值是
。DATAROOTDIR/doc/postgresql--htmldir=DIRECTORYPostgreSQL 的 HTML 格式文档将安装到这个目录。默认是
。DATAROOTDIR
注意
为了能把 PostgreSQL 安装到共享安装位置(例如
/usr/local/include),同时又不干扰系统其他部分的名字空间,我们做了特别处理。首先,除非完整展开后的目录名已经包含字符串 “postgres” 或 “pgsql”,否则会自动把字符串 “/postgresql” 追加到datadir、sysconfdir和docdir上。例如,如果你选择/usr/local作为前缀,那么文档会安装到/usr/local/doc/postgresql;但如果前缀是/opt/postgres,那么它会安装到/opt/postgres/doc。客户端接口的公共 C 头文件会安装到includedir中,并且不会污染名字空间。内部头文件和服务器头文件则会安装到includedir下的私有目录中。关于如何访问这些头文件,请参见各接口自己的文档。最后,如果有需要,也会在libdir下创建私有子目录,用于存放动态可加载模块。--with-includes=DIRECTORIESDIRECTORIES是一个以冒号分隔的目录列表,这些目录会被加入编译器搜索头文件的路径中。如果你把可选软件包(如 GNU Readline)安装在非标准位置,就必须使用此选项,并且通常还要使用对应的--with-libraries选项。例如:
--with-includes=/opt/gnu/include:/usr/sup/include。--with-libraries=DIRECTORIESDIRECTORIES是一个以冒号分隔的目录列表,用于搜索库文件。如果你把软件包安装在非标准位置,很可能需要使用这个选项(以及对应的--with-includes)。例如:
--with-libraries=/opt/gnu/lib:/usr/sup/lib。--enable-nls[=LANGUAGES]启用本地语言支持(NLS),也就是以非英语语言显示程序消息的能力。
LANGUAGES是可选的、以空格分隔的语言代码列表,例如--enable-nls='de fr'。(你的列表与实际提供的翻译集合之间的交集会自动计算。)如果你不指定列表,则会安装所有可用的翻译。要使用此选项,需要一个 Gettext API 实现;参见上文。
--with-pgport=NUMBER将
NUMBER设为服务器和客户端的默认端口号。默认值是 5432。端口号以后始终都可以修改,但如果在这里指定,那么服务器和客户端都会编译进同一个默认值,这可能很方便。通常选择非默认值的唯一合理原因,是你打算在同一台机器上运行多个 PostgreSQL 服务器。--with-perl构建 PL/Perl 服务器端语言。
--with-python构建 PL/Python 服务器端语言。
--with-tcl构建 PL/Tcl 服务器端语言。
--with-tclconfig=DIRECTORYTcl 会安装文件
tclConfig.sh,其中包含构建与 Tcl 交互的模块所需的配置信息。通常会在已知位置自动找到此文件,但如果要使用其他版本的 Tcl,可以指定查找它的目录。--with-gssapi构建时支持 GSSAPI 认证。在许多系统上,GSSAPI 系统(通常是 Kerberos 安装的一部分)并不安装在默认搜索的位置(如
/usr/include、/usr/lib),因此除了此选项,还必须使用--with-includes和--with-libraries。configure会检查所需的头文件和库,确保 GSSAPI 安装满足要求,然后才会继续。--with-krb5构建时支持 Kerberos 5 认证。在许多系统上,Kerberos 系统并未安装在默认搜索的位置(如
/usr/include、/usr/lib),因此除了此选项,还必须使用--with-includes和--with-libraries。configure会检查所需的头文件和库,确保 Kerberos 安装满足要求,然后才会继续。--with-krb-srvnam=NAMEKerberos 服务主体的默认名称(GSSAPI 也会使用)。默认值为
postgres。通常没有理由更改,除非使用 Windows 环境,此时必须将其设为大写的POSTGRES。--with-openssl构建时支持 SSL(加密)连接。这要求已安装 OpenSSL 软件包。
configure会检查所需的头文件和库,确保 OpenSSL 安装满足要求,然后才会继续。--with-pam--with-ldap构建时支持 LDAP 认证和连接参数查找(更多信息参见第 31.17 节和第 19.3.8 节)。在 Unix 上,这要求已安装 OpenLDAP 软件包。在 Windows 上,使用默认的 WinLDAP 库。
configure会检查所需的头文件和库,确保 OpenLDAP 安装满足要求,然后才会继续。--without-readline禁止使用 Readline 库(也禁止 libedit)。此选项会禁用 psql 中的命令行编辑和历史记录,因此不建议使用。
--with-libedit-preferred优先使用 BSD 许可的 libedit 库,而不是 GPL 许可的 Readline。只有在两个库都已安装时,该选项才有意义;在那种情况下,默认行为是使用 Readline。
--with-bonjour构建时支持 Bonjour。这要求操作系统支持 Bonjour。建议在 OS X 上启用。
--with-ossp-uuid使用 OSSP UUID 库构建相关组件。具体来说,构建 uuid-ossp模块,它提供生成 UUID 的函数。
--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-integer-datetimes禁用对时间戳和时间间隔的 64 位整数存储支持,改为以浮点数存储日期时间值。浮点日期时间存储是 8.4 之前PostgreSQL发行版的默认方式,但现在已被弃用,因为它无法在完整
timestamp取值范围内支持微秒精度。不过,基于整数的日期时间存储需要 64 位整数类型。因此,在没有这种类型的平台上,或为了与为早期PostgreSQL版本编写的应用保持兼容,可以使用此选项。更多信息参见第 8.5 节。--disable-float4-byval禁用 float4 值的“按值”传递,改为“按引用”传递。此选项会降低性能,但为了兼容用 C 编写并使用“版本 0” 调用约定的旧用户定义函数,可能需要使用它。更好的长期解决办法是更新这些函数,使其使用“版本 1” 调用约定。
--disable-float8-byval禁用 float8 值的“按值”传递,改为“按引用”传递。此选项会降低性能,但为了兼容用 C 编写并使用“版本 0” 调用约定的旧用户定义函数,可能需要使用它。更好的长期解决办法是更新这些函数,使其使用“版本 1” 调用约定。注意,此选项不仅影响 float8,还影响 int8 和 timestamp 等相关类型。在 32 位平台上,默认使用
--disable-float8-byval,且不允许选择--enable-float8-byval。--with-segsize=SEGSIZE设置段大小,单位为 GB。大型表会拆分为多个操作系统文件,每个文件的大小等于段大小。这避免了许多平台上的文件大小限制问题。默认段大小为 1 GB,在所有支持的平台上都是安全的。如果操作系统支持“大文件”(如今大多数系统都支持),可以使用更大的段大小。这有助于减少处理超大表时消耗的文件描述符数量。但应注意,不要选择超出平台和拟用文件系统支持范围的值。你可能要使用的其他工具(如 tar)也可能限制可用的文件大小。建议将此值设为 2 的幂,但这并非硬性要求。注意,更改此值需要执行 initdb。
--with-blocksize=BLOCKSIZE设置块大小,单位为 KB。这是表内存储和 I/O 的单位。默认值 8 KB 适用于大多数情况;在特殊情况下,其他值可能有用。该值必须是 1 到 32(KB)之间的 2 的幂。注意,更改此值需要执行 initdb。
--with-wal-segsize=SEGSIZE设置 WAL 段大小,单位为 MB。这是 WAL 日志中每个文件的大小。调整此大小可能有助于控制 WAL 日志传送的粒度。默认大小为 16 MB。该值必须是 1 到 64(MB)之间的 2 的幂。注意,更改此值需要执行 initdb。
--with-wal-blocksize=BLOCKSIZE设置 WAL 块大小,单位为 KB。这是 WAL 日志内存储和 I/O 的单位。默认值 8 KB 适用于大多数情况;在特殊情况下,其他值可能有用。该值必须是 1 到 64(KB)之间的 2 的幂。注意,更改此值需要执行 initdb。
--disable-spinlocks即使 PostgreSQL 不支持该平台的 CPU 自旋锁,也允许构建成功。缺少自旋锁支持会导致性能不佳;因此,仅应在构建中止并告知平台缺少自旋锁支持时使用此选项。如果在你的平台上构建 PostgreSQL 必须使用此选项,请向 PostgreSQL 开发者报告该问题。
--disable-thread-safety禁用客户端库的线程安全性。这会使 libpq 和 ECPG 程序中的并发线程无法安全地控制各自私有的连接句柄。
--with-system-tzdata=DIRECTORYPostgreSQL 自带了日期和时间操作所需的时区数据库。这个时区数据库实际上与很多操作系统(如 FreeBSD、Linux 和 Solaris)提供的 IANA 时区数据库兼容,因此再次安装它是多余的。使用此选项时,将使用位于
DIRECTORY的、由系统提供的时区数据库,而不是 PostgreSQL 源码发布中自带的那一份。DIRECTORY必须是绝对路径。在某些操作系统上,/usr/share/zoneinfo是一个可能的目录。请注意,安装过程不会检测时区数据是否不匹配或有误。如果你使用该选项,建议运行回归测试,以验证你指定的时区数据能够与 PostgreSQL 正常配合工作。这个选项主要面向那些非常了解其目标操作系统的二进制包发布者。使用该选项的主要优点是,当本地众多夏令时规则中的任何一条发生变化时,PostgreSQL 软件包都无需升级。另一个优点是,如果安装时不需要构建时区数据库文件,那么 PostgreSQL 的交叉编译也会更直接。
--without-zlib禁止使用 Zlib 库。这会禁用 pg_dump 和 pg_restore 对压缩归档的支持。此选项仅用于没有该库的罕见系统。
--enable-debug将所有程序和库编译为带调试符号的版本。这意味着你可以在调试器中运行程序,以分析问题。这会显著增大安装后的可执行文件大小,而且在非 GCC 编译器上,通常还会禁用编译器优化,从而导致变慢。不过,保留这些符号对于处理可能出现的各种问题极其有帮助。目前,只有在你使用 GCC 的情况下,才建议在生产安装中使用该选项。但如果你在做开发工作或运行测试版,就应始终启用它。
--enable-coverage如果使用 GCC,所有程序和库都会在编译时插入代码覆盖率测试所需的检测代码。运行时,它们会在构建目录中生成包含代码覆盖率指标的文件。更多信息参见第 30.4 节。此选项仅用于使用 GCC 进行开发工作时。
--enable-profiling如果使用 GCC,所有程序和库都会编译为可进行性能分析的形式。后端退出时,会创建一个子目录,其中包含用于性能分析的
gmon.out文件。此选项仅用于使用 GCC 进行开发工作时。--enable-cassert在服务器中启用断言检查,用于测试许多“不可能发生”的条件。这对代码开发非常有价值,但这些测试可能会显著拖慢服务器速度。此外,启用这些测试并不一定会增强服务器稳定性!断言检查并未按严重程度分类,因此即使某个 bug 相对无害,只要触发了断言失败,仍会导致服务器重启。该选项不建议用于生产环境,但如果你在做开发工作或运行测试版,就应当启用它。
--enable-depend启用自动依赖跟踪。启用后,makefile 会在任何头文件被修改时,重新构建所有受影响的目标文件。如果你在做开发工作,这很有用;但如果你只是打算编译一次并安装,这只是额外的开销。目前该选项只在 GCC 下有效。
--enable-dtrace编译 PostgreSQL 时支持动态跟踪工具 DTrace。更多信息参见第 27.4 节。
可以设置环境变量
DTRACE来指定dtrace程序。这通常是必要的,因为dtrace一般安装在/usr/sbin下,而该目录可能不在搜索路径中。对于
dtrace程序,可在以下环境变量中指定额外命令行选项:DTRACEFLAGS。在 Solaris 上,要在 64 位二进制文件中包含 DTrace 支持,必须指定DTRACEFLAGS="-64"给 configure。例如,使用 GCC 编译器时:./configure CC='gcc -m64' --enable-dtrace DTRACEFLAGS='-64' ...
使用 Sun 的编译器时:
./configure CC='/opt/SUNWspro/bin/cc -xtarget=native64' --enable-dtrace DTRACEFLAGS='-64' ...
如果你希望使用不同于
configure所选的 C 编译器,可以将环境变量CC设为所选程序。默认情况下,configure会在gcc可用时选择它,否则选择平台默认编译器(通常为cc)。类似地,如有需要,可以使用CFLAGS变量覆盖默认编译器标志。可以在
configure命令行上指定环境变量,例如:./configure CC=/opt/bin/gcc CFLAGS='-O2 -pipe'下面列出可以按这种方式设置的重要变量:
BISONBison 程序
CCC 编译器
CFLAGS传给 C 编译器的选项
CPPC 预处理器
CPPFLAGS传给 C 预处理器的选项
DTRACEdtrace程序的位置DTRACEFLAGS传给
dtrace程序的选项FLEXFlex 程序
LDFLAGS用于链接可执行文件或共享库的选项
LDFLAGS_EX仅用于链接可执行文件的附加选项
LDFLAGS_SL仅用于链接共享库的附加选项
MSGFMT用于本地语言支持的
msgfmt程序PERLPerl 解释器的完整路径名。它将用于确定构建 PL/Perl 所需的依赖。
PYTHONPython 解释器的完整路径名。它将用于确定构建 PL/Python 所需的依赖。此外,这里指定(或以其他方式隐式选择)Python 2 还是 3,决定了可用的 PL/Python 语言变体。更多信息参见第 42.1 节。
TCLSHTcl 解释器的完整路径名。它将用于确定构建 PL/Tcl 所需的依赖,并会被代入 Tcl 脚本中。
XML2_CONFIG用于定位 libxml 安装的
xml2-config程序。
有时,事后补充编译器标志会很有用;原有标志由
configure选定。一个重要的例子是 gcc 的-Werror选项不能包含在以下变量中:CFLAGS(该变量会传给configure),因为它会破坏configure的许多内置测试。要添加此类标志,请将其放入COPT环境变量,再运行make。COPT的内容会被加入以下两组选项:CFLAGS和LDFLAGS;这两组选项原本由以下程序设置:configure。例如,你可以执行:make COPT='-Werror'或者:
export COPT='-Werror'make注意
开发服务器内部代码时,建议使用 configure 选项
--enable-cassert(开启许多运行时错误检查)和--enable-debug(提高调试工具的实用性)。如果使用 GCC,最好使用至少
-O1的优化级别进行构建,因为不使用优化(-O0)会关闭一些重要的编译器警告(例如未初始化变量的使用)。不过,非零优化级别会让调试变得更复杂,因为单步执行编译后的代码时,通常无法与源代码行一一对应。如果你在调试优化后的代码时感到困惑,可以把感兴趣的特定文件用-O0重新编译。一个简单方法是向 make 传递选项:make PROFILE=-O0 file.o。COPT和PROFILE环境变量实际上会被 PostgreSQL 的 makefile 以完全相同的方式处理。用哪个只是个人偏好问题,但开发者常见的习惯是把PROFILE用于一次性的标志调整,而COPT则可能长期保持设置。构建
要开始构建,请输入:
make(记得使用 GNU make。)构建需要几分钟,具体取决于硬件。显示的最后一行应该是:
All of PostgreSQL successfully made. Ready to install.
如果要构建所有可构建的内容,包括文档(HTML 和手册页)及附加模块(
contrib),请改为输入:make world显示的最后一行应该是:
PostgreSQL, contrib, and documentation successfully made. Ready to install.
回归测试
如果希望在安装前测试刚构建的服务器,可以在此时运行回归测试。回归测试是一套测试程序,用于验证 PostgreSQL 是否在你的机器上按开发者预期的方式运行。输入:
make check(不能以 root 身份运行;请使用非特权用户。)第 30 章包含解读测试结果的详细信息。以后任何时候都可以通过执行同一命令来重复此测试。
安装文件
注意
如果正在升级现有系统,请务必阅读第 17.6 节其中包含升级数据库集簇的说明。
要安装 PostgreSQL,请输入:
make install这会把文件安装到步骤 1中指定的目录。请确保你有权限写入该区域。通常这一步需要以 root 身份执行。另一种做法是预先创建目标目录,并安排授予适当权限。
要安装文档(HTML 和手册页),请输入:
make install-docs如果你上面执行的是 world 构建,则改为输入:
make install-world这也会安装文档。
你可以用
make install-strip代替make install,在安装时剥离可执行文件和库中的符号。这会节省一些空间。如果你在构建时启用了调试支持,那么剥离操作实际上会移除调试支持,因此只有在不再需要调试时才应该这样做。install-strip会尽量合理地节省空间,但它并不知道如何从每个可执行文件中去掉所有不需要的字节,所以如果你希望尽可能节省所有磁盘空间,仍需要手工处理。标准安装会提供客户端应用开发以及服务器端程序开发(例如用 C 编写自定义函数或数据类型)所需的全部头文件。(在 PostgreSQL 8.0 之前,后者需要单独执行
make install-all-headers命令,但此步骤现已并入标准安装。)仅客户端安装:. 如果你只想安装客户端应用程序和接口库,可以使用以下命令:
make -C src/bin installmake -C src/include installmake -C src/interfaces installmake -C doc installsrc/bin中有少量仅供服务器使用的二进制文件,不过它们都很小。
卸载:. 要撤销安装,请使用命令 make uninstall。不过,这不会删除任何已创建的目录。
清理:. 安装完成后,你可以使用命令 make clean
从源码树中删除构建产生的文件,以释放磁盘空间。这会保留 configure 程序生成的文件,以便你之后可以用 make 重新构建全部内容。要把源码树重置到发布时的状态,请使用 make distclean。如果你打算在同一个源码树中为多个平台构建,就必须为每个平台执行这一步并重新配置。(另一种做法是为每个平台使用单独的构建树,这样源码树就不会被修改。)
如果你已经执行了一次构建,随后发现 configure 选项有误,或者修改了任何会被 configure 检查的内容(例如软件升级),那么在重新配置和重新构建之前先执行
make distclean 是一个好主意。否则,你对配置选项所做的更改可能不会传播到所有需要它们的地方。