一些迴歸測試涉及故意無效的輸入值。錯誤訊息可能來自 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。

一些系統對 pow() 和 exp() 的錯誤處理機制與當前 PostgreSQL 程式碼期望的機制不同。

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

因此，如果您看到排序差異，這通常不是什麼大問題，除非查詢確實有一個 ORDER BY 子句，而您的結果違反了它。不過，仍然請報告它，以便我們可以在該特定查詢中新增 ORDER BY 子句，以消除未來版本中的錯誤“失敗”。

您可能會想，為什麼我們不明確地對所有迴歸測試查詢進行排序以一勞永逸地解決這個問題。原因是這樣做會使迴歸測試的用處減少而不是增加，因為它們傾向於只測試產生排序結果的查詢計劃型別，而忽略那些不產生排序結果的型別。

如果 errors 測試在 select infinite_recurse() 命令處導致伺服器崩潰，則意味著平臺對程序堆疊大小的限制小於 max_stack_depth 引數指示的值。這可以透過在更高的堆疊大小限制下執行伺服器來解決（建議使用 4MB，預設值為 max_stack_depth）。如果您無法做到這一點，一種替代方法是減小 max_stack_depth 的值。

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

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

diff results/random.out expected/random.out

應該只會產生一兩行差異。除非“random”測試反覆失敗，否則您不必擔心。

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