某些迴歸測試涉及有意輸入無效的值。 錯誤訊息可能來自 PostgreSQL 程式碼，也可能來自主機平台系統常式。 在後一種情況下，訊息可能會因平台而異，但應反映類似的資訊。 這些訊息的差異將導致“失敗”的迴歸測試，可以透過檢查來驗證。

如果您針對以 C 以外的定序順序地區設定初始化的伺服器執行測試，則可能會因為排序順序而產生差異，並導致後續失敗。 迴歸測試套件已設定為透過提供備用結果檔案來處理此問題，這些檔案共同處理大量地區設定。

當使用臨時安裝方法時，若要以不同的地區設定執行測試，請在 make 指令行上傳遞適當的地區設定相關環境變數，例如

make check LANG=de_DE.utf8

（迴歸測試驅動程式會取消設定 LC_ALL，因此無法使用該變數來選擇地區設定。）若要不使用任何地區設定，請取消設定所有地區設定相關的環境變數（或將它們設定為 C），或使用以下特殊調用

make check NO_LOCALE=1

當針對現有安裝執行測試時，地區設定設定由現有安裝決定。 若要變更它，請透過將適當的選項傳遞給 initdb 來以不同的地區設定初始化資料庫叢集。

一般來說，建議嘗試在生產環境中想要的地區設定中執行迴歸測試，因為這會執行實際將在生產環境中使用的地區設定和編碼相關程式碼部分。 根據作業系統環境，您可能會遇到失敗，但至少您會知道在執行實際應用程式時會發生哪些特定於地區設定的行為。

大多數日期和時間結果都取決於時區環境。 參考檔案是針對時區 America/Los_Angeles 產生的，如果沒有使用該時區設定執行測試，則會出現明顯的失敗。 迴歸測試驅動程式將環境變數 PGTZ 設定為 America/Los_Angeles，這通常可以確保正確的結果。

有些測試涉及從表格欄位計算 64 位元浮點數 (double precision)。已經觀察到在涉及 double precision 欄位的數學函數的結果上存在差異。float8 和 geometry 測試特別容易在不同平台之間，甚至在不同編譯器最佳化設定下產生微小差異。需要人工目測比較才能確定這些差異的實際意義，這些差異通常位於小數點右邊第 10 位。

有些系統將負零顯示為 -0，而另一些系統僅顯示 0。

有些系統以不同於目前 PostgreSQL 程式碼所預期的方式，針對 pow() 和 exp() 發出錯誤訊號。

您可能會看到相同的資料列以不同於預期檔案中出現的順序輸出的情況。在大多數情況下，嚴格來說，這不是一個錯誤。大多數迴歸測試腳本都沒有那麼講究，會為每個 SELECT 使用 ORDER BY，因此根據 SQL 規範，它們的結果資料列排序沒有明確定義。實際上，由於我們在相同的軟體上對相同的資料執行相同的查詢，因此我們通常在所有平台上獲得相同的結果排序，因此缺少 ORDER BY 不是問題。但是，有些查詢確實表現出跨平台的排序差異。在針對已安裝的伺服器進行測試時，排序差異也可能是由非 C 地區設定或非預設參數設定引起的，例如 work_mem 或規劃器成本參數的自訂值。

因此，如果您看到排序差異，除非查詢確實有違反結果的 ORDER BY，否則不必擔心。但是，請務必回報它，以便我們可以在該特定查詢中添加 ORDER BY，以消除未來版本中虛假的“失敗”。

您可能想知道為什麼我們不顯式地對所有迴歸測試查詢進行排序，以徹底解決這個問題。原因是這樣做會使迴歸測試的用處變小，而不是更大，因為它們會傾向於執行產生排序結果的查詢計畫類型，而不包括那些不產生排序結果的查詢計畫類型。

如果 errors 測試導致伺服器在 select infinite_recurse() 指令崩潰，則表示平台對處理程序堆疊大小的限制小於 max_stack_depth 參數所指示的大小。可以通過在較高的堆疊大小限制下執行伺服器來解決這個問題（建議使用預設的 max_stack_depth 值時使用 4MB）。如果您無法做到這一點，另一種方法是降低 max_stack_depth 的值。

在支援 getrlimit() 的平台上，伺服器應自動選擇一個安全的 max_stack_depth 值；因此，除非您手動覆蓋了這個設定，否則這種故障是一個可回報的錯誤。

random 測試腳本旨在產生隨機結果。在極少數情況下，這會導致迴歸測試失敗。輸入

diff results/random.out expected/random.out

應該只產生一行或幾行的差異。除非隨機測試重複失敗，否則您不必擔心。

在針對現有安裝執行測試時，某些非預設參數設定可能會導致測試失敗。例如，更改 enable_seqscan 或 enable_indexscan 等參數可能會導致計畫變更，從而影響使用 EXPLAIN 的測試結果。