PostgreSQL 9.3.1 中文手册 | ||||
---|---|---|---|---|
Prev | Up | Chapter 15. 源码安装 | Next |
这部分提供额外的关于PostgreSQL的安装和设置的特定平台的问题。 一定要阅读安装说明,尤其是Section 15.2。 另外,检查 Chapter 30有关回归测试结果的说明。
此处未覆盖的平台没有已知的特定平台安装问题。
PostgreSQL工作在AIX上,但正确安装它具有挑战性。 支持AIX 4.3.3到6.1版本。 您可以使用GCC或本机IBM编译器xlc。 一般情况下,采用近期的AIX版本和PostgreSQL有所帮助。 检查bulid farm获得最新的信息,其中AIX版本是众所周知的。
推荐的最小修复水平支持的AIX版本是:
Maintenance Level 11 + post ML11 bundle
Maintenance Level 9 + post ML9 bundle
Technology Level 10 Service Pack 3
Technology Level 7
Base Level
查看当前补丁级别,使用AIX 4.3.3到AIX 5.2 ML7中的 oslevel -r,或者更高版本的 oslevel -s。
除你自己之外请使用以下的configure标志, 如果你在/usr/local: --with-includes=/usr/local/include --with-libraries=/usr/local/lib中已经安装了Readline或者libz:
在AIX 5.3上,PostgreSQL的编译以及使用GCC运行有一些问题。
您将要使用GCC随后到3.3.2的版本,特别是如果你使用一个预先包装的版本。 我们在4.0.1时有很大成功。比起GCC的实际问题来说,早期版本问题似乎与IBM包装GCC有更大关系, 因此,如果你自己编译GCC,关于GCC早期版本你很可能成功。
AIX 5.3有问题,其中sockaddr_storage没有被定义为足够大。 在5.3版本中,IBM增加sockaddr_un的大小, Unix域套接字地址结构,但并没有相应地增加sockaddr_storage的大小。 这一结果是尝试使用Unix域套接字与PostgreSQL导致libpq溢出的数据结构。 TCP/IP连接工作正常,但不是Unix域套接字,以防止工作着的回归测试。
这个问题报道给IBM,并且作为bug报告PMR29657进行记录。 如果您升级到维护级别5300-03或更高版本,这将包括此修复程序。 一个快速解决方法是改变/usr/include/sys/socket.h中的 _SS_MAXSIZE到1025。在这两种情况下, 一旦你有修正的头文件,则要重新编译PostgreSQL。
PostgreSQL依赖于系统的getaddrinfo
函数解析listen_addresses,pg_hba.conf中的IP地址,
较旧版本的AIX已经划分出这个函数中的bug。
如果您有关于这些设置的问题,
更新到上面显示的相应的AIX补丁级别应特别注意。
一个用户报告:
当在AIX 5.3上实现PostgreSQL版本8.1的时候, 我们周期性地遇到了问题, 其中统计收集器可能"诡秘的"不会成功。 这似乎是IPv6实行中意外行为的结果。 它看起来像PostgreSQL和IPv6在AIX 5.3中不能很好地结合。
任何下面操作"修复"这个问题。
删除本地主机的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地址。
Warning |
这的确是有关IPv6支持不成熟问题的解决方法, 这在AIX 5.3版本发布期间有明显改善。 它在AIX 5.3版本进行工作,但并不代表优雅的解决问题的办法。 报道称这种解决方法不仅是不必要的,而且会在AIX 6.1上导致问题, 其中IPv6的支持也日渐成熟。 |
AIX关于内存管理方式上有些特别。 你可以有很多倍的千兆字节RAM免费的服务器, 但是当运行应用程序时,仍然有内存或地址空间不足的错误。 createlang导致不寻常错误的例子。 比如,作为PostgreSQL安装的所有者运行:
-bash-3.00$ createlang plperl template1 createlang: language installation failed: ERROR: could not load library "/opt/dbs/pgsql748/lib/plperl.so": A memory address is not in the address space for the process.
作为PostgreSQL安装的非拥有者进行运行:
-bash-3.00$ createlang plperl template1 createlang: language installation failed: ERROR: could not load library "/opt/dbs/pgsql748/lib/plperl.so": Bad address
另一个例子是在PostgreSQL服务器日志中内存不足的错误, 与每个内存分配接近或者大于256 MB。
所有这些问题的总体原因是默认bittedness并且使用服务器进程的内存模型。 默认情况下,所有的在AIX上编译的二进制文件是32位。 这不依赖于使用的硬件类型或内核。 这些32位进程是使用一些模型之一将4 GB内存限制为256 MB的段大小。 默认允许堆内小于256 MB,因为它共享单独的段与堆栈。
在支持createlang的情况下, 上面检查你的PostgreSQL安装中的umask和二进制文件的权限。 参与该示例中的二进制文件分别为32位和安装模式是750而不是755。 因为权限被以这种方式设置, 只有进程组中的所有者或成员才可以加载库。 因为它不是被所有人可读的, 加载器将对象置入过程堆而不是共享库段,它放置在那里。
此问题的"理想"解决方案是使用64位PostgreSQL编译, 但事实并非总是可行的,因为32位处理器系统可以进行, 但不能运行64位二进制文件。
如果需要32位二进制, 设置LDR_CNTRL到MAXDATA=0xn0000000, 其中1 <= n <= 8,启动PostgreSQL服务器之前,尝试不同的值并且设置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将杀死进程, 最接近这一点的是我们所看到的是交叉失败,因为系统决定没有足够的内存用于另一个进程。 像许多其他的AIX部分,如果这产生问题,那么 分页空间分配方法及内存不足杀进程在系统或进程范围基础上是可配置。
"Large Program Support", AIX Documentation: General Programming Concepts: Writing and Debugging Programs.
"Program Address Space Overview", AIX Documentation: General Programming Concepts: Writing and Debugging Programs.
"Performance Overview of the Virtual Memory Manager (VMM)", AIX Documentation: Performance Management Guide.
"Page Space Allocation", AIX Documentation: Performance Management Guide.
"Paging-space thresholds tuning", AIX Documentation: Performance Management Guide.
Developing and Porting C and C++ Applications on AIX, IBM Redbook.
PostgreSQL可以使用Cygwin,Windows的类Linux环境进行编译, 但该方法不如本地Windows编译(参阅Chapter 16), 并且不再推荐在Cygwin下运行服务器。
当从源码进行编译时,按照正常的安装程序进行(也就是./configure;make), 注意下面的Cygwin特殊差异:
在Windows功能之前使用Cygwin bin目录设置你的路径。这有助于避免编译问题。
GNU make命令称为make而不是gmake。
不支持adduser命令;在Windows NT,2000或者XP上使用适当的用户管理应用。否则,忽略这一步。
不支持su命令;在Windows NT,2000或者XP上使用ssh模拟su。否则,忽略这一步。
不支持OpenSSL。
为了共享内存支持开启cygserver。 要做到这一点,输入命令/usr/sbin/cygserver&。 这个程序需要运行于任何时候, 你启动PostgreSQL服务器或初始化一个数据库集群 (initdb)。 可能需要改变默认cygserver配置(例如,增加SEMMNS)以避免 由于缺乏系统资源而导致的PostgreSQL失败。
在某些系统上编译可能会失败,它使用的语言环境不是C。 为了解决这个问题,在编译之前通过执行export LANG=C.utf8设置区域到C, 并且,你已经安装完PostgreSQL之后,设置它返回到以前的设置。
平行回归测试(make check)可以产生伪回归测试失败,
由于listen()
积压队列溢出,这会导致连接拒绝错误或挂起。
你可以使用make变量MAX_CONNECTIONS限制连接数,因此:
make MAX_CONNECTIONS=5 check
在某些系统上你最多可以有10个并发连接。
可能安装cygserver和作为Windows NT服务的PostgreSQL服务器。 关于如何做的信息,请参阅包含Cygwin上的PostgreSQL二进制包的README文档。 它被安装在目录/usr/share/doc/Cygwin中。
PostgreSQL 7.3+应该在运行HP-UX 10.X或者11.X的系列700/800 PA-RISC机器上工作, 给予相应的系统补丁级别和编译工具。 至少有一个开发者经常在HP-UX 10.20上测试。 并且,我们在HP-UX 11.00和11.11上有成功安装的报道。
除了PostgreSQL源代码发布外,您将需要GNU make(HP make不能执行), 以及GCC或HP的完整ANSI C 编译器。 如果你打算从Git 源代码而不是发布包编译,你还需要Flex(GNU lex)和Bison (GNU yacc)。我们建议确保你是最新的HP补丁。至少,如果你正在HP-UX 11.11上编译64位二进制文件,您可能需要PHSS_30966 (11.11)或 者后继补丁,否则initdb可能会挂起:
PHSS_30966 s700_800 ld(1) and linker tools cumulative patch
一般原则,你应该使用当前的libc和ld/dld补丁程序,以及编译器补丁, 如果你正在使用HP C编译器。 请参阅HP支持网站,比如http://itrc.hp.com和 ftp://us-ffs.external.hp.com/免费的最新补丁副本。如果你正在PA-RISC 2.0的机器上编译,并希望 使用GCC的64位二进制文件,你必须使用GCC的64位版本。HP-UX PA-RISC的GCC二进制和Itanium可以从 http://www.hp.com/go/gcc获得。不要忘了在同一时间安装binutils。
如果你想在PA-RISC 2.0机器上编译,并且在PA-RISC 1.1机器上编译二进制,你需要声明CFLAGS 中的+DAportable。
如果你在HP-UX Itanium机器上进行编译,你将需要带有依赖包或者继承补丁的最新HP ANSI C编译器。
PHSS_30848 s700_800 HP C Compiler (A.05.57)
PHSS_30849 s700_800 u2comp/be/plugin library Patch
如果你有HP的C编译器和GCC,那么当你运行configure时,可能想要明确选择使用的编译器。
./configure CC=cc
对于HP的C编译器,或者
./configure CC=gcc
GCC。如果你忽略这些设置,那么如果它有选择的话,configure将选择gcc。
缺省安装目标位置是/usr/local/pgsql,你可能想要在/opt下改变一些内容。 如果这样,使用--prefix切换configure。
在回归测试中,可能有一些几何测试中的低阶位数差异,这取决于您使用的编译器和数学库版本的不同而不同。 任何其他错误都是令人怀疑的。
PostgreSQL已在MIPS r8000,r10000 (ip25和ip27)以及r12000(ip35)处理器成功运行, 运行在IRIX 6.5.5m, 6.5.12, 6.5.13和6.5.26与MIPSPro编译器版本7.30, 7.3.1.2m, 7.3和7.4.4m。
您将需要MIPSPro完整ANSI C编译器。尝试与GCC编译存在问题。
这是关于使用函数返回某种结构的众所周知的GCC bug(不固定为3.0版本)。
此错误会影响功能,如inet_ntoa
, inet_lnaof
, inet_netof
, inet_makeaddr
,
和semctl
。它被认为是固定的,迫使代码链接使用libgcc的那些函数,但是这并没有被测试过。
MIPSPro编译器的7.4.1m版本产生错误代码是已知的。当尝试启动数据库时,现象是"无效主节点记录"。 版本7.4.4m可行;中间版本的状态是不确定的。
有可能是编译问题,如下:
cc-1020 cc: ERROR File = pqcomm.c, Line = 427 The identifier "TCP_NODELAY" is undefined. if (setsockopt(port->sock, IPPROTO_TCP, TCP_NODELAY,
一些版本包括在sys/xti.h中的TCP定义, 因此在src/backend/libpq/pqcomm.c和 src/interfaces/libpq/fe-connect.c中添加#include <sys/xti.h> 是必要的。如果你遇到这类问题,请让我们知道,以便于我们可以制定合适的修复。
在回归测试中,可能有一些几何测试中的低阶位数的差异,依赖于你使用的FPU。 任何其他的错误都值得怀疑。
Windows下的PostgreSQL可以使用MinGW,微软操作系统的类Unix编译环境,或者使用 微软的Visual C++编译器套件编译。 MinGW的编译版本采用本章中描述的正常编译系统; Visual C++编译工作完全不同,并且在Chapter 16中描述。 它完全是一种本地编译,并且没有使用像MinGW的额外软件。 现成的安装程序可以从PostgreSQL的网站上获得。
本地Windows端口需要Windows 2000或更高的32或64位版本。早期操作系统 没有足够的基础设施(但Cygwin可以使用这些信息)。 MinGW,类Unix编译工具,以及MSYS,Unix工具集合 需要运行类似于configure的shell脚本, 可以从http://www.mingw.org/下载。 两者都不需要运行生成的二进制文件; 他们只需要创建二进制文件。
要使用MinGW编译64位二进制文件,安装来自http://mingw-w64.sourceforge.net/的64位工具集, 将其bin目录放在PATH中, 并运行--host=x86_64-w64-mingw选项的configure命令。
您已经安装了一切之后,建议您在CMD.EXE下运行psql, 作为MSYS控制台有缓冲问题。
如果PostgreSQL在Windows崩溃,有可能产生minidumps可用于跟踪崩溃的原因, 类似于在Unix上的核心转储。这些转储可以使用Windows调试器工具或者Visual Studio读取。 为了启动Windows上的转储, 创建名为集群数据目录里的crashdumps的子目录。 转储将被写入到该目录,连同基于崩溃进程识别符和崩溃当前时间的唯一名称。
PostgreSQL可以在SCO UnixWare 7和SCO OpenServer 5上编译。在OpenServer上, 你可以使用OpenServer Development Kit或者Universal Development Kit。 然而,可能需要一些调整,正如下面描述的。
你应该找到你的SCO Skunkware CD的副本。 Skunkware CD附带UnixWare 7和OpenServer 5当前版本。 Skunkware包括可从互联网获得的许多流行程序的准备安装版本。 例如,gzip, gunzip, GNU Make, Flex和Bison。 对于UnixWare 7.1,这个光盘现在标有"开放式许可软件补充",如果你没有这个光盘, 可以从http://www.sco.com/skunkware/获得。
Skunkware有UnixWare和OpenServer的不同版本。 请确保您安装了您的操作系统的正确版本,除非另有说明如下。
在UnixWare 7.1.3及以上,包含在UDK CD上的GCC编译器作为GNU Make。
您需要使用GNU make程序,位于Skunkware CD。默认情况下,它作为/usr/local/bin/make安装。 为了避免混淆SCO make程序,你可能需要重命名GNUmake为gmake。
由于UnixWare 7.1.3及以上,GNU Make程序是UDK CD的OSTK部分, 并且位于/usr/gnu/bin/gmake。
Readline库在Skunkware CD上。但它不包括在UnixWare 7.1 Skunkware CD上。如果你有UnixWare 7.0.0或者7.0.1 Skunkware CD,您可以从那里安装。 否则,尝试http://www.sco.com/skunkware/。
缺省情况下,Readline安装在/usr/local/lib和 /usr/local/include。 然而,没有帮助的情况下PostgreSQL configure程序不能找到, 如果你安装Readline,那么使用configure的下列选项:
./configure --with-libraries=/usr/local/lib --with-includes=/usr/local/include
如果你正在OpenServer上使用新的通用开发Kit (UDK)编译器,你需要声明UDK库的位置:
./configure --with-libraries=/udk/usr/lib --with-includes=/udk/usr/include
将上面这些与Readline选项放在一起:
./configure --with-libraries="/udk/usr/lib /usr/local/lib" --with-includes="/udk/usr/include /usr/local/include"
缺省情况下,PostgreSQL手册页安装在/usr/local/pgsql/man。 缺省UnixWare不能查阅手册页,为了可用查看你需要修改/etc/default/man中的MANPATH 变量,比如:
MANPATH=/usr/lib/scohelp/%L/man:/usr/dt/man:/usr/man:/usr/share/man:scohelp:/usr/local/man:/usr/local/pgsql/man
在OpenServer上,需要投入一些额外研究形成可用手册页,因为它不同于其他的平台。 目前,PostgreSQL根本不安装。
对于先于发布OpenUnix 8.0.0(UnixWare 7.1.2)的编译器,包括7.1.1b功能补充, 你可能需要在CFLAGS或者CC环境变量中指定-Xb。 这个指示是编译tuplesort.c中引用内联功能的一个错误。 显然,有7.1.2(8.0.0)编译器及以上的变化。
对于线程,你必须在所有使用libpq的程序上使用-Kpthread。
libpq使用pthread_*
调用,
其中只有-Kpthread/-Kthread标志可用。
PostgreSQL在Solaris上有很好的支持。更新操作系统越多,您将遇到越少的问题; 详细信息请参见下面。
您可以使用GCC或Sun的编译器套件进行编译。为更好的代码优化, 在SPARC架构上强烈推荐Sun的编译器。当推荐使用GCC 2.95.1; GCC 2.95.3或更高版本的时候,我们已经听到问题报告。 如果您正在使用Sun的编译器,请注意不要选择/usr/ucb/cc;而使用 /opt/SUNWspro/bin/cc。
您可以从http://www.oracle.com/technetwork/server-storage/solarisstudio/downloads/下载Sun Studio。 许多GNU工具都集成到Solaris 10上,或者它们目前在Solaris companion CD上。 如果你喜欢Solaris旧版本的包,你可以从http://www.sunfreeware.com中找到这些工具。 如果你喜欢源码,可以参阅http://www.gnu.org/order/ftp.html。
当您使用OpenSSL编译PostgreSQL的时候,你可能会得到以下文件中的编译错误:
src/backend/libpq/crypt.c
src/backend/libpq/password.c
src/interfaces/libpq/fe-auth.c
src/interfaces/libpq/fe-connect.c
这是因为在标准的/usr/include/crypt.h头部以及OpenSSL所提供的头文件之间有命名空间冲突。
升级您的OpenSSL安装到版本0.9.6a修复了这个问题。Solaris 9和上面有OpenSSL的较新版本。
如果configure抱怨失败的测试程序, 这可能是运行时链接程序无法找到一些库的情况, 可能libz, libreadline或一些其他非标准库如libssl。 为了指向正确的位置,在configure命令行上设置LDFLAGS环境变量。 比如:
configure ... LDFLAGS="-R /usr/sfw/lib:/opt/sfw/lib:/usr/local/lib"
参阅ld手册页获取更多详情。
在Solaris 7以及更高版本,64位版本的libc中有一个vsnprintf
程序,
从而导致PostgreSQL中不稳定的核心转储。
最简单的已知的解决方法是强制PostgreSQL使用vsnprintf
自己的版本,而不是库副本。
要做到这一点,运行configure之后
编辑configure产生的文件:
src/Makefile.global中,
更改行
LIBOBJS =
读取
LIBOBJS = snprintf.o
(可能还有其他在这个变量中已经列出的文件。顺序无关紧要。)然后编译照常。
SPARC架构上,强烈推荐Sun Studio编译。尝试使用-xO5优化 标志产生显著快速的二进制文件。不要使用 任何的标志修改浮点运算的行为以及errno处理(例如, -fast)。这些标志可以提高一些日期/时间计算中的PostgreSQL不规范行为。
如果您没有理由在SPARC上使用64位二进制文件,更喜欢32位版本。64位运算速度较慢, 并且64位二进制比32位更慢。另一方面,在AMD64 CPU族中的32位代码不是本地的, 这就是为什么32位代码在这个CPU族中显著慢的原因。
是的,有可能使用DTrace。参阅 Section 27.4获取更多信息。 你也可以通过文章https://blogs.oracle.com/robertlor/entry/user_level_dtrace_probes_in 查找更多的信息。
如果您看到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 gmake: *** [postgres] Error 1
您的DTrace安装太旧而不能处理静态函数的探测。你需要Solaris 10u4或更高版本。