某些迴歸測試涉及故意無效的輸入值。錯誤訊息可能來自 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 位元浮點數（倍精度）。已經觀察到涉及 倍精度 欄位數學函數的結果存在差異。 float8 和 geometry 測試尤其容易在不同平台，甚至使用不同的編譯器最佳化設定下，產生微小的差異。需要人工比對來確定這些差異的實際意義，這些差異通常出現在小數點右邊第 10 位。

某些系統將負零顯示為 -0，而其他系統僅顯示 0。

某些系統發出 pow() 和 exp() 錯誤的方式，與目前 PostgreSQL 程式碼預期的方式不同。

您可能會看到相同的資料列以與預期檔案中不同的順序輸出的差異。在大多數情況下，嚴格來說這不是錯誤。大多數迴歸測試腳本並不像為每個 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 的測試結果。