[ 永遠的UNIX > PostgreSQL7.0手冊-管理員手冊-33. 數據庫恢復 34. 蛻變測試 ]

[ 永遠的UNIX::UNIX技術資料的寶庫 ] GB | BIG5

首頁 > 數據庫 > 其它 > 正文

PostgreSQL7.0手冊-管理員手冊-33. 數據庫恢復 34. 蛻變測試

編譯：何偉平 laser@zhengmai.com.cn (2001-04-21 22:50:30)

第三十三章.　數據庫恢復
本節需要有人來寫．願做志願者嗎？（譯注：在（升級）安裝，配置和磁盤存儲等章節有一些相關內容可以參考，不過確實缺乏災難恢復的材料。:(）　

--------------------------------------------------------------------------------

第三十四章.　蛻變測試
內容　
蛻變測試環境　
蛻變測試過程　
蛻變分析　
平台相關的比較文件　
蛻變測試指導和分析．
PostgreSQL　蛻變測試是由一套復雜完整的測試，用來測試嵌入在　PostgreSQL　裡的的SQL實現．它同時測試標準　SQL　操作和　PostgreSQL　的擴展SQL．　
蛻變測試有兩種不同的運行方式："串行"方式和"並行"方式．串行方式順序運行每個測試腳本，而並行方式同時啟動多個服務器進程以並行運行多組測試．並行測試使我們對進程內部通訊和鎖的正確工作有足夠的信心．另一個主要區別是串行方式測試過程使用一套已經安裝了的　postmaster，而並行測試過程測試一套已經制作完成但是還沒有安裝的系統．（並行測試腳本實際上安裝到一個臨時目錄然在那裡啟動一個私有的　postmaster．）　

有一些正確安裝並且具有完整功能的　PostgreSQL　可能會在蛻變測試中失效，這些主要是因為浮點數的形式和時區支持的問題．目前的測試只是簡單的用　"diff"　算法進行評估，因而對一些細小的系統區別很敏感．當一項測試報告"failed"（"失敗"）時，只要檢查一下預期和實際的結果，你就會發現區別區別並不大．　

蛻變測試最初是由　Jolly　Chen　和　Andrew　Yu　開發的，並且由　Marc　Fournier　和　Thomas　Lockhart　做了大量的修改/封裝。從　PostgreSQLv6.1　開始，每個官方發布的版本都帶有蛻變測試．　

蛻變測試環境
下面的蛻變測試做了如下假設　（除注明的以外）：　
命令是　Unix-兼容的．見下面的注釋．
除了注明的以外，使用的是缺省值．
postgres　用戶是　Postgres　超級用戶．
源文件路徑是　/usr/src/pgsql　（也可以是其他路徑）．
運行時間路徑是　/usr/local/pgsql　（其他路徑也可能）．

通常，蛻變測試應該以　postgres　用戶身份運行，因為　'src/test/regress'　目錄和子目錄是由　postgres　所有的．如果你要以其他用戶身份運行蛻變測試，那該用戶應該對目錄　'src/test/regress'　有寫權限．　
以前必須把系統時區設置為　PST　運行　postmaster，不過現在不需要這樣了。你可以在你自己的正常的　postmaster　配置裡運行蛻變測試。測試腳本將設置　PGTZ　環境變量以確保與時區無關的測試將產生預期的結果。不過，你的系統必須提供對　PST8PDT　時區的庫支持，否則時區無關測試將失敗。要証實你的系統的確包括這個支持，鍵入：　

setenv　TZ　PST8PDT
date
上面的　"date"　命令應該返回當前系統在　PST8PDT　時區的時間．如果　PST8PDT　的數據庫不可用，那你的系統應該以　GMT　返回時間．如果　PST8PDT　時區不可獲得，你可以顯式設置時區規則：　
setenv　PGTZ　PST8PDT7,M04.01.0,M10.05.03
蛻變測試的目錄布局如下：　
表　34-1.　目錄布局　
　　　
　
　目錄　描述　
目錄　描述　
input　利用　make　all　將　.source　文件轉換成的　'sql'　子目錄裡面的一些　.sql　文件　
output　利用　make　all　將　.source　文件轉換成的在　expected　子目錄裡面的　.out　文件　
sql　用執行蛻變測試的　.sql　文件　
expected　代表我們*期望看到*的結果的　.out　文件　　
results　表示結果的*實際*樣子的　.out　文件同時還用表拷貝測試的臨時存儲空間　
tmp_check　並行測試腳本創建的臨時安裝目錄　

--------------------------------------------------------------------------------
--------------------------------------------------------------------------------

蛻變測試過程
下面命令在　RedHat　Linux　v　4.2　上用　bash　shell　測試過．除了注明的外，它們應該可以在大多數系統上工作．象　ps　和　tar　這樣的命令在不同平台上的參數可能有較大的不同．根據常識　使用這些命令．　
Postgres　蛻變測試　
用下面命令制作蛻變測試所需要的文件：　
　　　　　　　　　　　　cd　/usr/src/pgsql/src/test/regress
　　　　　　　　　　　　gmake　clean
　　　　　　　　　　　　gmake　all
如果是你第一次運行測試，你不需要鍵入　"gmake　clean"　．如果這是你第一次運行蛻變測試，你可以忽略　"gmake　clean"．　
這個步驟把一個帶有　PostgreSQL　的　C　程序編譯成共享庫．本地化的　SQL　腳本和輸出比較文件同樣也為測試而創建．本地化把源文件裡的宏替換為絕對路徑名和用戶名．　

如果你想使用"串行"測試過程（它測試一個已經安裝的　postmaster），先確保　postmaster　已經運行了，可以在一個窗口裡鍵入　

　　　　　　　　　　　　postmaster
或者通過鍵入下面命令把　postmaster　守護運行在台　
　　　　　　　　　　　　cd
　　　　　　　　　　　　nohup　postmaster　>　regress.log　2>&1　&
者可能更好一些，因為蛻變測試日志將會相當長（　在下Postgres　7.0　裡，60K左右），如果出錯了，你可以查看這些日志．　
注意：不要以　root　身份運行　postmaster．
運行蛻變測試．對串行測試，鍵入　
　　　　　　　　　　　　cd　/usr/src/pgsql/src/test/regress
　　　　　　　　　　　　gmake　runtest
對並行測試，鍵入　
　　　　　　　　　　　　cd　/usr/src/pgsql/src/test/regress
　　　　　　　　　　　　gmake　runcheck
串行測試使用你的已經在運行的　postmaster　運行測試腳本．並行測試將進行一次完整的　Postgres安裝，把　postgres　安裝到一個臨時目錄裡，然在那裡運行一個自己的　postmaster，再運行測試腳本．最它會卸載自己的　postmaster　（不過臨時目錄不會自動刪除）．　
你將在屏幕上（和輸出文件　./regress.out）獲取一系列標明哪項測試通過和那些失敗的輸出．請注意因為平台相關的變化，有些測試"失敗"是很正常的．參閱下一節獲取關那些失敗是真正重要的描述．　

有些測試，尤其是　"numeric"，可能要花相當長的時間，尤其是在慢的平台上．請保持耐心．　

在測試和檢查結果完成，鍵入　

　　　　　　　　　　　　cd　/usr/src/pgsql/src/test/regress
　　　　　　　　　　　　gmake　clean
以回收測試使用的臨時磁盤空間，如果你運行了一個串行測試，還要鍵入　
　　　　　　　　　　　　dropdb　regression

--------------------------------------------------------------------------------
--------------------------------------------------------------------------------

蛻變分析
實際測試結果在　./results　目錄裡的文件裡．這些結果會與　./expected　目錄裡的預期結果用　'diff'進行對比．任何區別都為你保存在　./regression.diffs　裡。（或者如果你願意地話，你可以自己手工運行diff）　
這些文件可能不能精確地匹配．測試腳本把任何區別當作“失敗”報告，“失敗”　的測試的失敗原因可能是因為微小的跨平台的錯誤信息，數學庫，或輸出格式等的差別．這類"失敗"　並不表明　Postgres　有問題．　

因此，有必要對每個“失敗”的測試的實際差別進行檢查，以發現這是否是一個真正的問題。下面的段落會試著提供一些判斷這些區別的重要與否的指導。　

錯誤信息差別
有一些蛻變測試涉及到有意的非法輸入值．錯誤信息可能會來自　Postgres　代碼或來自主機平台系統路徑．對者，信息可能在平台之間區別比較大，但應該反映相似的信息．這些信息上的差別將會導致一個"失敗"的蛻變測試，我們可以通過檢查文件發現這一點．
日期和時間差別
大多數日期和時間結果依賴時區環境變量。參考文件是為時區　PST8PDT　（伯克利，加州）準備的，因而如果測試沒有設置為那個時區是顯然會失敗的。蛻變測試的驅動器把環境變量　PGTZ　設置為　PST8PDT　以保証正確的測試。　
如果你在改為夏時制的日切日或者該天的前天或者天測試時，在　"timestamp"　測試裡的一些查詢可能失敗．這些查詢假設昨天午夜，今天午夜和明天午夜之間的間隔是精確的　24　小時...　如果是夏時制開始或結束的日切日，這些（假設）是錯的．　

有些系統不能接受我們推薦的顯式設置時區的語法；在這樣的機器上你可能要用不同的　PGTZ　設置。　

有些使用舊的時區庫的系統在對　PDT　1970　年前的時間使用夏時制時會出毛病，導致　PDT　1970年以前的時間顯示為　PST。這會導致在測試結果裡的本地化區別。

浮點數差別
有些測試涉及到對表中的數據列進行　64位　（float8）計算的問題．我們觀察了涉及到　計算　float8　字段的數學函數的結果的差別．float8　和　geometry（幾何類型）測試尤其容易在不同平台之間產生小差別。這時需要肉眼對這些差別進行比較，以判斷這些差別究竟有多大，我們發現是在小數點右邊10位數。　
有些系統在　pow()　和　exp()　出錯時產生的信號與目前　Postgres　代碼裡期望的機制不一樣．

多邊形差別
有些測試涉及到關加州奧克蘭/伯克利街區圖的地形數據（譯注：原文是'date'，懷疑是'data'）．這些地圖數據是用多邊形表達的，多邊形的頂點使用一對　float8　數據表示的（數字緯度和經度）．一開始，先創建一些表再把地理數據裝入，然創建一些用多邊形相交的操作符（##）聯合的兩個表的視圖，最對視圖進行選擇操作．對比平台不同產生的差異，差異發生在小數點右邊第二位和第三位以．出現問題的　SQL　語句是下面幾條：　
　　　　　　　　　　QUERY:　SELECT　*　from　street;
　　　　　　　　　　QUERY:　SELECT　*　from　iexit;
隨機數差別
在　random.out　裡至少有一個測試會產生隨機結果．這會導致回歸測試中的隨機測試失敗（可能每五次到十次出現一次）．鍵入　
　　　　　　　　　　diff　results/random.out　expected/random.out
會產生僅僅一行或幾行差別．你不必擔心這些，除非隨機測試總是失敗．（另一方面，如果在多次蛻變測試中隨機測試從來不失敗，你可能也要擔心．）
“預期的”文件
./expected/*.out　文件是從最早的單個的由　Jolly　Chen　提供的　expected.input　文件修改出來的．為不同開發平台生成的這些文件的更新版本在經過仔細（？）的檢查代替了原先的．許多這樣的開發機運行著在　Ix86　硬件上的　Unix　OS　的變種　（FreeBSD，Linux等）．最初的　expected.input　文件是在一台使用　postgres5-1.02a5.tar.gz　源碼樹的　SPARC　Solaris　2.4　系統上生成的．我們將它與在一台　I386　Solaris　2.4　系統上生成的文件進行對比，發現只有多邊形浮點數小數點右邊第三位數有差別（參閱文）．最初的　sample.regress.out　文件來自　Jolly　Chen　構建的　postgres-1.01　版本，我們在這裡一起附上以供參考．該文件可能是在一台　DEC　ALPHA　機器上創建的，因為　postgres-1.01　版本的Makefile.global　文件裡有　PORTNAME=alpha.

--------------------------------------------------------------------------------
--------------------------------------------------------------------------------

平台相關的比較文件
因為一些測試天生會產生平台相關的結果，我們提供了一個方法以支持平台相關的結果比較文件。通常，一套文件可用多個平台；而不是為每個平台提供一套獨立的比較文件，因此存在一個定義選用哪個比較文件的映射文件。所以，要消除某特定平台的虛假的測試“失敗”，你必須選擇或者制作一個結果文件的變種，然往映射文件裡加一行，即是"resultmap"。　
映射文件裡的每行都有下面形式　

　　　　　　　　　　　　　　　　testname/platformnamepattern=comparisonfilename
測試名稱只是特定蛻變測試模塊的名稱。平台名稱模式是一個　expr(1)　風格的模式（也就是說，一個開頭帶有顯式^錨符號的規則表達式）。它與　config.guess　打印的平台名匹配。比較文件名是替換結果比較文件。　
例如：int2　蛻變測試包括一個有意的超過　int2　范圍的數值的輸入。產生的錯誤信息是平台相關的；我們的參考平台顯示　

　　　　ERROR:　　pg_atoi:　error　reading　"100000":　Numerical　result　out　of　range
但是相當多其他　Unix　平台顯示　
　　　　ERROR:　　pg_atoi:　error　reading　"100000":　Result　too　large
因此，我們提供一個比較文件的變種，int2-too-large.out，該文件包含這樣的錯誤信息的寫法。要消除在　HPPA　平台上的虛假“錯誤”信息，resultmap　包括　
　　　　　　　　　　　　　　　　int2/hppa=int2-too-large
這樣將在　config.guess　的輸出以　'hppa'　開始的任何機器上觸發。其他　resultmap　裡的行選擇對應其他平台合適的比較文件。

--------------------------------------------------------------------------------
(http://www.fanqiang.com) 進入【UNIX論壇】

相關文章

===更多相關===

★ 樊強制作歡迎分享 ★