| PostgreSQL 9.3.1 中文手册 | ||||
|---|---|---|---|---|
| 上一页 | 上一级 | 章 15. 源码安装 | 下一页 | |
这部分提供额外的关于PostgreSQL的安装和设置的特定平台的问题。 一定要阅读安装说明，尤其是第 15.2 节。 另外，检查 第 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。
如果你在/usr/local中已经安装了Readline或者libz， 在你自己的选项外，请使用以下的configure选项： --with-includes=/usr/local/include --with-libraries=/usr/local/lib
在AIX 5.3上，使用GCC时PostgreSQL的编译以及运行存在一些问题。
您想要使用之后的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地址。
| 警告 |
这的确是IPv6支持的不成熟问题的解决方法， 这在AIX 5.3版本中有明显改善。 该方法在AIX 5.3版本中被实施，但并不是一个优雅的解决问题的办法。 报道称这种解决方法不仅是不必要的，而且会在AIX 6.1上导致问题， 其中IPv6的支持日渐成熟。 |
AIX关于内存管理方式上有些特别。 你可以有很多倍MB的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位进程被限制了4GB的内存消耗在段大小为256MB时使用一些模型中的一个。 默认允许少于256 MB在堆与栈共享一个段。
在上面的createlang的例子中， 检查你的PostgreSQL安装中的umask和二进制文件的权限。 该示例中的二进制文件是32位的并且以权限750而不是755的模式安装。 因为权限被设置成这种模式， 只有进程组中的所有者或成员才可以加载库。 因为它不是所有人可读的， 加载器将对象放入进程堆中而不是它应该放置的共享库段中。
此问题的"理想"解决方案是使用64位的PostgreSQL编译， 但事实并非总是可行的，因为32位处理器系统可以编译， 但不能运行64位的二进制文件。
如果需要32位二进制文件，在启动PostgreSQL服务器之前 设置LDR_CNTRL为MAXDATA=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将杀死该进程。 最接近这一点的是我们所看到的交叉失败，因为系统认为没有足够的内存用于另一个进程。 像许多其他的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编译(参阅第 16 章)， 并且不再推荐在Cygwin下运行服务器。
当从源码进行编译时，按照正常的安装程序进行（也就是./configure;make）， 注意下面的Cygwin的特殊差异：
设定你的环境变量path，将Cygwin的bin目录设置在Windows应用之前。这有助于避免编译问题。
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失败。
在某些locale不是C的系统上编译可能会失败。 为了解决这个问题，在编译之前通过执行export LANG=C.utf8设置locale到C， 然后，在你安装完PostgreSQL之后，再将它设置回之前的内容。
由于listen()积压队列溢出，
平行回归测试（make check）会产生伪回归测试失败，
导致连接拒绝错误或挂起。
你可以使用make变量MAX_CONNECTIONS限制连接数，因此：
make MAX_CONNECTIONS=5 check
在某些系统上你最多可以有10个并发连接。
可以将cygserver和PostgreSQL服务安装成Windows NT的服务。 关于如何做的信息，请参阅包含在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和Itanium的GCC二进制可以从 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和GCC的C编译器，那么当你运行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++编译工作完全不同，在第 16 章中描述。 它完全是一种本地编译，并且没有使用像MinGW的额外软件。 现成的安装程序可以从PostgreSQL的网站上获得。
本地Windows端口需要32或64位版本的Windows 2000或更高版本。早期操作系统 没有足够的基础设施（但Cygwin可能被使用）。 MinGW，类Unix编译工具，以及MSYS，这些Unix工具集合 在运行像configure这样的shell脚本时是需要的， 可以从http://www.mingw.org/下载。 两者在运行生成的二进制文件时不需要; 他们只在创建二进制文件时需要。
使用MinGW编译64位的二进制文件时，安装来自http://mingw-w64.sourceforge.net/的64位工具集， 将其bin目录放在PATH中， 并在运行configure命令时，指定--host=x86_64-w64-mingw选项。
您已经安装了一切之后，建议您在CMD.EXE下运行psql， MSYS控制台有缓冲问题。
如果PostgreSQL在Windows上崩溃，有可能产生minidumps可用于跟踪崩溃的原因， 类似于在Unix上的core dump。这些dump可以使用Windows调试器工具或者Visual Studio读取。 为了让Windows上Dump生成功能有效， 需要在集群数据目录里创建名为crashdumps的子目录。 Dump文件之后将被写入到该目录，基于崩溃进程的识别符和崩溃的当前时间保证dump文件名称的唯一。
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。
当您编译PostgreSQL支持OpenSSL的时候，你可能会得到以下文件中的编译错误：
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不稳定的core dump。
最简单的已知的解决方法是强制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。参阅 第 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或更高版本。