當您在 PostgreSQL 中發現錯誤時，我們希望收到您的回報。您的錯誤回報在使 PostgreSQL 更加可靠方面扮演著重要的角色，因為即使是最謹慎的處理也無法保證 PostgreSQL 的每個部分都能在每種平台上、每種情況下正常運作。
以下建議旨在協助您形成可以有效處理的錯誤回報。沒有人被要求遵循這些建議，但這樣做通常對每個人都有好處。
我們無法保證立即修復每個錯誤。如果錯誤很明顯、很嚴重或影響很多使用者，很有可能有人會調查它。我們也可能會告訴您更新到較新的版本，以查看該錯誤是否在那裡發生。或者我們可能會決定在我們計劃進行的重大重寫完成之前，無法修復該錯誤。或者，這可能只是太難了，而且議程上有更重要的事情。如果您需要立即的協助，請考慮取得商業支援合約。
在您回報錯誤之前，請閱讀並重新閱讀文件，以驗證您確實可以做您正在嘗試的任何事情。如果從文件中不清楚您是否可以做某事，也請回報；這是文件中的錯誤。如果結果表明程式執行的動作與文件中的說明不同，那就是一個錯誤。這可能包括但不限於以下情況：
程式因致命訊號或作業系統錯誤訊息而終止，這表明程式中存在問題。（一個反例可能是「磁碟已滿」訊息，因為您必須自己修復它。）
程式為任何給定的輸入產生錯誤的輸出。
程式拒絕接受有效的輸入（如文件中所定義）。
程式接受無效的輸入，而沒有通知或錯誤訊息。但請記住，您認為的無效輸入可能就是我們認為的擴充功能或與傳統實務的相容性。
PostgreSQL 無法根據支援平台上的指示編譯、建置或安裝。
此處「程式」指的是任何可執行檔，而不僅僅是後端處理程序。
速度慢或耗用大量資源不一定是錯誤。請閱讀文件或在郵件清單上尋求協助以調整您的應用程式。未能遵守SQL標準也不一定是錯誤，除非明確聲明特定功能的相容性。
在您繼續之前，請檢查 TODO 清單和 FAQ，看看您的錯誤是否已被知悉。如果您無法解碼 TODO 清單上的資訊，請回報您的問題。我們至少可以做的是讓 TODO 清單更清楚。
關於錯誤回報最重要的事情是要說明所有事實，並且僅說明事實。不要推測您認為出了什麼問題、「它似乎做了什麼」或程式的哪個部分有缺陷。如果您不熟悉實作，您可能會猜錯並且對我們沒有任何幫助。即使您熟悉，有根據的解釋是對事實的很好的補充，但不能取代事實。如果我們要修復錯誤，我們仍然必須先親眼看到它發生。回報赤裸裸的事實相對簡單（您可能可以從螢幕上複製並貼上它們），但常常遺漏重要的細節，因為有人認為這無關緊要，或者無論如何都會理解回報。
以下項目應包含在每個錯誤回報中：
重現問題所需之**精確步驟** （從程式啟動開始）。這應該是完整的；僅發送一個不包含先前 CREATE TABLE 和 INSERT 語句的獨立 SELECT 語句是不夠的，如果輸出取決於表格中的資料。我們沒有時間來反向工程您的資料庫綱要，而且如果我們應該自己建立資料，我們可能會錯過問題。
對於 SQL 相關問題，測試案例的最佳格式是一個可以透過 psql 前端執行的檔案，它能展示問題。（請務必確保您的 ~/.psqlrc 啟動檔案中沒有任何內容。）建立此檔案的簡單方法是使用 pg_dump 傾印出設定場景所需的表格宣告和資料，然後新增問題查詢。我們鼓勵您盡可能縮小範例的大小，但這並非絕對必要。如果錯誤可以重現，無論如何我們都會找到它。
如果您的應用程式使用其他用戶端介面，例如 PHP，請嘗試隔離導致錯誤的查詢。我們可能不會設定 Web 伺服器來重現您的問題。無論如何，請記得提供確切的輸入檔案；不要猜測問題發生在「大型檔案」或「中型資料庫」等情況，因為這些資訊太不精確，無法使用。
您得到的輸出。請不要說它「無法運作」或「崩潰」。如果有錯誤訊息，請顯示它，即使您不理解它。如果程式因作業系統錯誤而終止，請說明是哪一個。如果什麼都沒發生，請說明。即使您的測試案例的結果是程式崩潰或其他明顯的事情，它可能不會在我們的平台上發生。最簡單的方法是從終端機複製輸出，如果可能的話。
如果您正在報告錯誤訊息，請取得訊息的最詳細形式。在 psql 中，事先輸入 \set VERBOSITY verbose。如果您要從伺服器日誌中提取訊息，請將執行階段參數 log_error_verbosity 設定為 verbose，以便記錄所有詳細資訊。
在發生致命錯誤的情況下，用戶端報告的錯誤訊息可能不包含所有可用的資訊。請同時查看資料庫伺服器的日誌輸出。如果您沒有保留伺服器的日誌輸出，那麼現在就是開始這樣做的好時機。
您預期的輸出非常重要。如果您只寫「這個命令給我這個輸出。」或「這不是我期望的。」，我們可能會自己執行它，掃描輸出，並認為它看起來沒問題，而且完全符合我們的期望。我們不應該花時間來解碼您的命令背後的確切語義。尤其要避免僅僅說「這不是 SQL 說的/Oracle 做的。」從中挖掘正確的行為SQL這不是一件有趣的事情，而且我們並非都知道所有其他關聯式資料庫的行為方式。（如果您的問題是程式崩潰，您顯然可以省略此項目。）
任何命令行選項和其他啟動選項，包括您從預設值更改的任何相關環境變數或設定檔。同樣，請提供確切的資訊。如果您使用的是在啟動時啟動資料庫伺服器的預先封裝發行版，您應該嘗試找出它是如何完成的。
您所做的任何與安裝說明不同的事情。
PostgreSQL 版本。您可以執行命令 SELECT version(); 來找出您連接的伺服器的版本。大多數可執行程式也支援 --version 選項；至少 postgres --version 和 psql --version 應該可以運作。如果該函數或選項不存在，則您的版本太舊，需要升級。如果您執行的是預先封裝的版本，例如 RPM，請說明，包括套件可能有的任何子版本。如果您談論的是 Git 快照，請提及，包括 commit hash。
如果您的版本低於 17.2，我們幾乎肯定會告訴您升級。每個新版本都有許多錯誤修復和改進，因此您在舊版本 PostgreSQL 中遇到的錯誤很可能已經修復。我們只能為使用較舊版本 PostgreSQL 的網站提供有限的支援；如果您需要的超過我們能提供的，請考慮購買商業支援合約。
平台資訊。這包括核心名稱和版本、C 函式庫、處理器、記憶體資訊等等。在大多數情況下，報告供應商和版本就足夠了，但不要假設每個人都知道「Debian」到底包含什麼，或者每個人都在 x86_64 上執行。如果您有安裝問題，那麼關於您機器上的工具鏈（編譯器、make 等）的資訊也是必要的。
如果您的錯誤報告變得相當冗長，請不要害怕。這是生活中的事實。最好第一次報告所有事情，而不是讓我們從您那裡擠出事實。另一方面，如果您的輸入檔案很大，首先詢問是否有人有興趣調查它是公平的。這是一篇文章，概述了關於報告錯誤的一些更多技巧。
不要花費所有時間來弄清楚輸入中的哪些更改會使問題消失。這可能無助於解決問題。如果事實證明錯誤無法立即修復，您仍然有時間找到並分享您的解決方法。同樣，再次不要浪費時間猜測錯誤為何存在。我們很快就會發現。
在撰寫錯誤報告時，請避免混淆的術語。整個軟體套件稱為「PostgreSQL」，簡稱有時為「Postgres」。如果您專門談論後端程序，請提及，不要只說「PostgreSQL 崩潰」。單個後端程序崩潰與父「postgres」程序崩潰截然不同；當您指的是單個後端程序停止運作時，請不要說「伺服器崩潰」，反之亦然。此外，諸如互動式前端「psql」之類的用戶端程式與後端完全分離。請盡可能具體說明問題是在用戶端還是伺服器端。
一般來說，將錯誤報告發送到錯誤報告郵件清單 <pgsql-bugs@lists.postgresql.org>。請您為您的電子郵件訊息使用一個描述性的主旨，可能是錯誤訊息的一部分。
另一種方法是填寫專案網站上的錯誤報告網頁表單，網址是網站。透過這種方式提交錯誤報告會將其郵寄至<pgsql-bugs@lists.postgresql.org>郵件論壇。
如果您的錯誤報告涉及安全性問題，而且您不希望它立即在公開檔案中顯示，請不要將其發送到pgsql-bugs。安全性問題可以私下報告給<security@postgresql.org>。
請勿將錯誤報告發送到任何使用者郵件論壇，例如<pgsql-sql@lists.postgresql.org>或<pgsql-general@lists.postgresql.org>。這些郵件論壇是用於回答使用者問題的，訂閱者通常不希望收到錯誤報告。更重要的是，他們不太可能修復錯誤。
另外，請不要將報告發送到開發人員郵件論壇<pgsql-hackers@lists.postgresql.org>。這個論壇是用於討論PostgreSQL的開發，如果我們可以將錯誤報告分開處理，那就太好了。如果問題需要更多審查，我們可能會選擇在pgsql-hackers上討論您的錯誤報告。
如果您對文件有疑問，回報問題的最佳地點是文件郵件論壇<pgsql-docs@lists.postgresql.org>。請具體說明您對文件的哪一部分不滿意。
如果您的錯誤是在非支援平台上的可移植性問題，請發送郵件至<pgsql-hackers@lists.postgresql.org>，以便我們（和您）可以共同努力將PostgreSQL移植到您的平台。
由於存在大量垃圾郵件，除非您已訂閱，否則以上所有論壇都將受到審核。 這意味著電子郵件的傳遞會有一些延遲。 如果您想訂閱這些論壇，請訪問https://lists.postgresql.org/ 獲取說明。
如果您在文件中看到任何不正確的內容，與您使用特定功能的經驗不符，或者需要進一步說明，請使用此表格回報文件問題。