當您在 PostgreSQL 中發現錯誤時，我們希望得到您的反饋。您的錯誤報告在提高 PostgreSQL 的可靠性方面起著重要作用，因為即使是最細緻的注意也無法保證 PostgreSQL 的所有部分都能在所有平臺、所有情況下正常工作。
以下建議旨在幫助您編寫易於處理的錯誤報告。沒有人強制要求遵循這些建議，但這樣做通常對每個人都有益。
我們無法保證立即修復所有錯誤。如果錯誤顯而易見、至關重要或影響許多使用者，那麼很可能有人會進行調查。也可能我們會告訴您更新到新版本以檢視錯誤是否仍然存在。或者我們可能會決定在計劃進行的重大重寫完成之前無法修復該錯誤。或者它可能太難了，而且議程上還有更重要的事情。如果您需要立即獲得幫助，請考慮購買商業支援合同。
在報告錯誤之前，請仔細閱讀文件，以確認您嘗試的操作確實是允許的。如果文件中不清楚您是否可以執行某項操作，也請報告；這是文件中的錯誤。如果事實證明程式的操作與文件不符，那就是一個錯誤。這可能包括但不限於以下情況：
程式以致命訊號或作業系統錯誤訊息終止，這些訊息會指向程式中的問題。（例如，“磁碟已滿”訊息可能不是一個反例，因為您需要自己解決。）
程式對任何給定輸入產生錯誤的輸出。
程式拒絕接受有效輸入（根據文件定義）。
程式在沒有通知或錯誤訊息的情況下接受無效輸入。但請記住，您認為的無效輸入可能是我們認為的擴充套件或與傳統實踐的相容性。
PostgreSQL 在支援的平臺上未能根據說明進行編譯、構建或安裝。
此處“程式”指的是任何可執行檔案，而不僅僅是後端程序。
執行緩慢或佔用大量資源不一定是錯誤。請閱讀文件或在郵件列表中尋求有關調整應用程式的幫助。不遵守SQL標準也不一定是錯誤，除非明確聲明瞭對特定功能的相容性。
在繼續之前，請檢查 TODO 列表和 FAQ，看看您的錯誤是否已知。如果您無法解讀 TODO 列表中的資訊，請報告您的問題。我們至少可以做的是讓 TODO 列表更清晰。
關於錯誤報告最重要的一點是陳述所有事實，並且只陳述事實。不要猜測您認為哪裡出錯了，“它似乎做了什麼”，或者程式的哪個部分有故障。如果您不熟悉實現，您很可能會猜錯，無濟於事。即使您熟悉，有根據的解釋也是事實的絕佳補充，但不能替代事實。如果我們打算修復錯誤，我們仍然需要先自己看到它發生。報告純粹的事實相對直接（您可能可以從螢幕上覆制貼上），但由於有人認為細節不重要或報告會被理解，因此常常會遺漏重要的細節。
每次錯誤報告都應包含以下內容：
從程式啟動開始，重現問題的確切步驟。這應該是自包含的；僅傳送一個裸露的 SELECT 語句而不傳送前面的 CREATE TABLE 和 INSERT 語句是不夠的，因為輸出可能取決於表中的資料。我們沒有時間來逆向工程您的資料庫模式，如果我們必須自己建立資料，我們可能會錯過問題。
對於 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 快照，請說明，包括提交雜湊。
如果您的版本低於 18.0，我們幾乎肯定會告訴您升級。每個新版本都有許多錯誤修復和改進，因此您在舊版本 PostgreSQL 中遇到的錯誤很可能已經被修復了。我們只能為使用舊版本 PostgreSQL 的站點提供有限的支援；如果您需要我們無法提供的幫助，請考慮購買商業支援合同。
平臺資訊。這包括核心名稱和版本、C 庫、處理器、記憶體資訊等。在大多數情況下，提供供應商和版本資訊就足夠了，但不要假設每個人都知道“Debian”具體包含什麼，或者每個人都在 x86_64 上執行。如果您遇到安裝問題，那麼您機器上的工具鏈（編譯器、make 等）的資訊也是必需的。
如果您的錯誤報告變得相當冗長，請不要害怕。這是生活的一部分。第一次報告所有內容比我們不得不費力擠出事實要好。另一方面，如果您的輸入檔案很大，您可以先詢問是否有人有興趣研究一下。這裡有一篇 文章，其中概述了更多關於報告錯誤的技巧。
不要花所有時間來弄清楚輸入中的哪些更改會導致問題消失。這可能無助於解決問題。如果事實證明該錯誤無法立即修復，您仍然有時間找到並分享您的解決方案。此外，再說一遍，不要浪費時間猜測錯誤存在的原因。我們會很快找出原因的。
在編寫錯誤報告時，請避免使用含糊不清的術語。整個軟體包稱為“PostgreSQL”，有時簡稱為“Postgres”。如果您具體談論的是後端程序，請說明，不要只說“PostgreSQL 崩潰了”。單個後端程序的崩潰與父“postgres”程序的崩潰是截然不同的；如果您是指單個後端程序崩潰，請不要說“伺服器崩潰了”，反之亦然。此外，客戶端程式，例如互動式前端“psql”，與後端完全分開。請儘量具體說明問題是在客戶端還是伺服器端。
一般來說，請將錯誤報告發送到錯誤報告郵件列表 <pgsql-bugs@lists.postgresql.org>。我們要求您為電子郵件訊息使用描述性的主題，可能包含錯誤訊息的一部分。
另一種方法是填寫專案 網站上提供的錯誤報告 Web 表單。以這種方式提交錯誤報告會將其傳送到 <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/ 獲取說明。
如果您在文件中看到任何不正確、與您在特定功能上的實際體驗不符或需要進一步澄清的內容，請使用 此表單 來報告文件問題。