序列化例外：還有誰參與？

當作爲SERIALIZABLE隔離級別的事務失敗時，是否有辦法知道哪個連接（即事務）涉及整個流程？序列化例外：還有誰參與？

我正在處理會計數據庫。我知道我們應該重試交易，這就是我們所做的。我遇到了一個問題，即事務必須在繁忙的系統上運行10次才能成功。

這裏應該有一個嚴重的問題。我想知道是否有一個配置參數允許系統在異常詳細信息中告訴失敗中涉及的其他連接。

關於SSI的Postgresql維基沒有這種信息。

非常感謝。

編輯1：

我推日誌DEBUG5水平沒有運氣。

所以我決定看看代碼。序列化衝突檢測在src/backend/storage/lmgr/predicate.c中完成，其中註定要失敗的事務標記爲SXACT_FLAG_DOOMED標誌。

我只是添加elog（...）調用與DEBUG1級別，編譯代碼並試一試。

這是有趣的，因爲現在它顯示我是這樣的：

2014-11-28 09:52:47 CET [9888]: [1-1] db=postgres,user=postgres DEBUG: 00000: 
SERIALIZABLE TX on Connection [12864] is marked DOOMED by SERIALIZABLE TX on Connection [9888]

現在我有積木明白髮生了什麼事情。

來源

2014-11-24 Olivier MATROT

在解決了這個問題之後，您應該考慮將編輯作爲答案編寫，無論現在還是之後。 SO社區可能會發現您在故障排除中添加的代碼非常有用。這對PostgreSQL本身也可能是一個有用的貢獻，可能作爲一個新的日誌記錄選項。 – 2014-11-28 09:09:59

我會盡快做到這一點。 – 2014-11-28 12:45:47

您可以在PostgreSQL黑客名單中關注此主題的討論：http://www.postgresql.org/message-id/[email protected] – 2014-12-02 14:38:21

首先看PostgreSQL的主日誌文件。在我的盒子裏，它在/ var/log/postgresql下。

之後，有一個lot of options用於記錄和錯誤報告。您可以記錄連接嘗試，並且可以記錄每個SQL語句。你應該能夠把服務器的功能放在一起。

我想你應該閱讀大部分鏈接的文檔。某些選項對服務器吞吐量有重大影響。

來源

2014-11-24 13:13:29

我會嘗試查看日誌記錄選項，重現問題並回來報告我的發現。 – 2014-11-24 17:44:11

我將日誌推送到了DEBUG5級別，希望它能讓我看到一些有趣的事情。沒有運氣。 – 2014-11-28 08:57:49

序列化例外：還有誰參與？

回答

相關問題