16.7. 平台相關的說明
這一節提供了考慮 PostgreSQL 安裝和設定的附加平台相關的話題。確定閱讀安裝指導,特别是
第 16.2 節。同樣,檢查關于回歸測試結果解釋的
第 32 章。
這裡沒有覆寫的平台不存在平台相關的安裝問題。
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,在你自己的選項之外使用下列
configure
标志:
--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。如果你更新到 maintenance level 5300-03 或更新,将會包括這個修複。一種快速的解決方法是把
/usr/include/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 實作中意外行為的結果。看起來 PostgreSQL 和 IPv6 無法和 AIX 5.3 一起很好地工作。
下面任意一種動作都可以“修複”該問題。
- 删除 localhost 的 IPv6 位址:
(as root) # ifconfig lo0 inet6 ::1/0 delete
- 從網絡服務删除 IPv6。AIX 上的
大概等價于 Solaris/Linux 上的/etc/netsvc.conf
。在 AIX 上的預設值是以是:/etc/nsswitch.conf
将其換成:hosts=local,bind
來使 IPv6 位址的搜尋無效。hosts=local4,bind4
警告
這實際上是對有關 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
設定為
MAXDATA=0x
n
0000000
,其中 1 <= n <= 8,并且嘗試不同的值以及
postgresql.conf
設定來找一個能讓你滿意的配置。這種
LDR_CNTRL
的使用告訴 AIX 你希望伺服器留出
MAXDATA
位元組給堆,以 256 MB 的段配置設定。當你找到了一個可工作的配置時,
ldedit
可以被用來修改二進制,這樣它們預設使用想要的堆尺寸。PostgreSQL 也可以被重新編譯,傳遞
configure LDFLAGS="-Wl,-bmaxdata:0x
n
0000000"
來達到相同的效果。
對于一個 64 位編譯,設定
OBJECT_MODE
為 64 并且傳遞
CC="gcc -maix64"
和
LDFLAGS="-Wl,-bbigtoc"
給
configure
(給
xlc
的選項可能不同)。如果你省略
OBJECT_MODE
的輸出,你的編譯可能會因為連結器錯誤而失敗。當
OBJECT_MODE
被設定時,它告訴 AIX 的編譯工具(如
ar
as
ld
)預設要處理哪些對象類型。
預設情況下,過量使用頁面空間的情況可能會發生。不過我們還沒有看到過,當程序用盡記憶體并且出現了過量使用時 AIX 會殺死程序。我們見到過的最接近于此的是 fork 失敗,其原因是系統覺得已經沒有足夠的記憶體給另一個程序。和 AIX 的很多其他部分一樣,如果這成為了一個問題,頁面空間配置設定方法和耗盡記憶體導緻的殺死在系統範圍或程序範圍是可以配置的。
參考和資源
“
Large Program Support”. AIX Documentation: General Programming Concepts: Writing and Debugging Programs.
Program Address Space Overview Performance Overview of the Virtual Memory Manager (VMM)”. AIX Documentation: Performance Management Guide.
Page Space Allocation Paging-space thresholds tuning Developing and Porting C and C++ Applications on AIX. IBM Redbook.
16.7.2. Cygwin
PostgreSQL 可以使用 Cygwin 來編譯,它是用于 Windows 的一個類 Linux 環境,但是這種方法不如原生 Windows 編譯(見
第 17 章)并且我們已經不再推薦在 Cygwin 下運作一個伺服器。
在從源代碼編譯時,按照正常安裝過程進行(即
./configure; make
; 等;隻要注意下列 Cygwin 相關的差別:
- 将你的路徑設定為使用 Cygwin 的 bin 目錄并且把它放在 Windows 工具的前面。這将幫助避免很多編譯的問題。
- 不支援
指令;使用 Windows NT、2000 或 XP 上的使用者管理應用來替代。否則,跳過這一步。adduser
-
指令;在 Windows NT、2000 或 XP 上使用 ssh 來模拟 su。否則,跳過這一步。su
- 不支援 OpenSSL。
- 為共享記憶體支援啟動
。要這樣做,輸入指令cygserver
。這個程式在你啟動 PostgreSQL 伺服器或初始化一個資料集簇(/usr/sbin/cygserver &
)時的任何時刻都需要被運作。預設的initdb
配置可能需要被更改(例如增加cygserver
)來防止 PostgreSQL 因為缺少系統資源而失敗。SEMMNS
- 在某些不使用 C 區域的系統上編譯可能會失敗。要修複這個問題,通過在邊以前
把區域設定為 C,并且在安裝完 PostgreSQL 之後把區域恢複成之前的設定。export LANG=C.utf8
- 并行回歸測試(
)可能産生虛假的回歸測試錯誤,這是由于溢出的make check
連接配接緩沖區,它會導緻連接配接拒絕錯誤或挂起。你可以使用listen()
來限制連接配接數:MAX_CONNECTIONS
(在某些系統上你可以有大約 10 個同時連接配接)。make MAX_CONNECTIONS=5 check
可以把
cygserver
PostgreSQL 伺服器安裝為 Windows NT 服務。關于如何這樣做的資訊,請參考包含在 Cygwin 上 PostgreSQL 二進制包中的
README
文檔。它被安裝在目錄
/usr/share/doc/Cygwin
中。
16.7.3. HP-UX
給定合适的系統更新檔級别和編譯工具,PostgreSQL 7.3+ 應該可以工作在運作 HP-UX 10.X 或 11.X 的 Series 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 的支援站點如
ftp://us-ffs.external.hp.com/如果你正在一台 PA-RISC 2.0 機器上編譯并且項使用 GCC 得到 64 位二進制,你必須使用 GCC 的 64 位版本。
如果你正在一台 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
之下的某個地方。如果是這樣,使用
configure
的
--prefix
開關。
在回歸測試中,在幾何測試中可能會有某些低序位差别,這會根據你使用的編譯器和數學庫版本而變化。任何其他錯誤都需要懷疑。
16.7.4. MinGW/原生 Windows
用于 Windows 的 PostgreSQL 可以使用 MinGW 編譯,它是一個用于微軟作業系統的類 Unix 的編譯環境。也可以使用微軟的Visual C++編譯器套件來編譯。MinGW 編譯使用本章中描述的正常編譯系統;而 Visual C++ 編譯的工作完全不同并且在
中描述。後者是一種完全原生的編譯并且沒有像 MinGW 那樣使用額外軟體。在 PostgreSQL 的主網站上有一個現成的安裝器可用。
原生 Windows 移植要求一個 Windows 2000 或更高的 32 或 64 位版本。早期的作業系統沒有足夠的基礎設施(但 Cygwin可以用在它們之上)。類 Unix 的編譯工具 MinGW 和 MSYS(一個 Unix 工具集合,用于運作如
configure
之類的 shell 腳本)可以從
http://www.mingw.org/下載下傳。運作結果二進制兩者都需要,它們隻在建立二進制時需要。
要使用 MinGW 編譯 64 位二進制,從
http://mingw-w64.sourceforge.net/安裝 64 位工具。把它放在
PATH
中的 bin 目錄,并且使用
--host=x86_64-w64-mingw32
選項運作
configure
在你安裝完所有的東西之後,我們建議你在
CMD.EXE
下運作psql,因為 MSYS 控制台有緩沖問題。
16.7.4.1. 在 Windows 上收集崩潰轉儲
如果 PostgreSQL 在 Windows 上崩潰,它有能力産生minidumps,這可以被用來追蹤崩潰發生的原因,這與 Unix 上的核心轉儲相似。這些轉儲可以被使用Windows Debugger Tools或Visual Studio讀取。要啟用在 Windows 上的轉儲生成,可在集簇資料目錄下建立一個名為
crashdumps
的子目錄。轉儲将被寫入到這個目錄,轉儲的名字基于崩潰程序的辨別符和崩潰的目前時間來确定。
16.7.5. Solaris
PostgreSQL 在 Solaris 上得到了很好的支援。你的作業系統越新,你将會碰到更少的問題;細節如下。
16.7.5.1. 要求的工具
你可以使用 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上找找。
16.7.5.2. configure 抱怨一個失敗的測試程式
如果
configure
抱怨一個失敗的測試程式,可能的情況是運作時連結器無法找到某些庫,可能是libz、libreadline或某些其他非标準庫如 libssl。要向它指出正确的位置,在
configure
指令行上設定
LDFLAGS
環境變量,例如:
configure ... LDFLAGS="-R /usr/sfw/lib:/opt/sfw/lib:/usr/local/lib"
更多資訊可見ld手冊頁。
16.7.5.3. 64-位編譯有時會崩潰
在 Solaris 7 和更老的版本上,64-位版本的 libc 有一個有缺陷的
vsnprintf
例程,這導緻 PostgreSQL 中不穩定的核心轉儲。最簡單的已知解決方案是強制 PostgreSQL 使用它自己的
vsnprintf
版本而不是庫中的拷貝。要這樣做,運作
configure
之後編輯一個由
configure
産生的檔案: 在檔案
src/Makefile.global
中将行
LIBOBJS =
改成
LIBOBJS = snprintf.o
(可能有其他檔案已經被列在這個變量中。順序無影響)。然後正常編譯。
16.7.5.4. 為最優性能編譯
在 SPARC 架構上,我們強烈推薦使用 Sun Studio來編譯。嘗試使用
-xO5
優化标志來生成顯著加快的二進制。不要使用任何修改浮點操作和
errno
處理(例如
-fast
)行為的标志。這些标志可能會做出某些非标準 PostgreSQL 行為,例如在日期/時間計算中。
如果你沒有理由要使用 SPARC 上的 64 位二進制,最好用 32 位版本。64 位操作較慢并且 64 位二進制比其 32 位變體要慢。并且在另一方面,AMD64 CPU 家族上的32 位代碼不是原生的,并且這也是問什麼在這個 CPU 族中 32 位代碼要明顯地更慢。
16.7.5.5. 用 DTrace 來跟蹤 PostgreSQL
是的,可以使用 DTrace。詳見
第 28.5 節如果你看到
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
make: *** [postgres] Error 1http://www.postgres.cn/docs/10/installation-platform-notes.html
說明你的 DTrace 安裝太舊,無法處理靜态函數中的探測。你需要 Solaris 10u4 或更新的版本。
本文轉自PostgreSQL中文社群,原文連結: