如何使 PostgreSQL 不記錄特定錯誤？
錯誤：在字元 13 處檢測到死鎖
我的 PG 日誌充滿了這些，但問題是，我已經在我的應用程序中處理了它（經過多年的挫折）。我檢測到它們並重複，直到它們通過。因此，我不再有任何理由看到這些特定的“錯誤”，他們現在唯一完成的就是掩蓋剩餘的實際錯誤！
因此，我想知道是否有某種方法可以防止 PG 專門記錄那些“檢測到死鎖”的錯誤。我不希望其他具有相同“意義”的錯誤也被壓制；只有那些，因為我知道它們發生並且已經處理它們。
我在手冊中找不到任何這樣的指令。
log_min_messages並且log_min_error_statement都太通用了，如果我更改它們，可能會抑制我尚未弄清楚如何處理的其他錯誤。這些死鎖實際上被認為/稱為“錯誤”的事實讓我感到不舒服。即使我確實處理過它們，但在現實生活中似乎完全不可能*避免它們。*遲早，通常當很多事情同時/並行執行時，它們會發生。但是再一次，我的程式碼檢測到它並一遍又一遍地等待並重複查詢，所以我不再認為這些是應該記錄的錯誤。
我希望這不是不可能的，除非我從“純”文本日誌切換到 CSV 日誌，然後將其導入我的數據庫並以這種方式排除這些錯誤。看起來這種錯誤日誌應該是基於明文文件的，而eventlog（Windows）就像一個笑話。（不可能從中導航/提取任何有用的東西。）
edata->output_to_server您可以通過選擇性地設置為 false來編寫一個使用 emit_log_hook 來抑制消息的擴展。它必須用 C 語言編寫並編譯，這並非易事（尤其是在 Windows 上）。這是使用 emit_log_hook的範例。
您可以編寫自己的 shell 腳本來查看新錯誤並排除您已經知道的其他錯誤。但是恕我直言，死鎖錯誤是錯誤。死鎖可能是由未索引的外鍵或觸發器引起的。您可以首先確保所有外鍵都已編入索引。但是您還需要查看死鎖涉及哪些表以及這些表具有哪些觸發器。Postgres 在改變表觸發器方面似乎不像 Oracle 那樣挑剔，但是直接更改其底層表的觸發器很可能是死鎖的可能來源。或者兩個表，每個表都有一個觸發器來更改另一個表，這與任何猜測一樣好。你真的應該想解決根本問題，然後你的應用程序會更快，你可以尋找其他需要改進的地方。