2022-10-12 20:23:27 KST [40P01] [11983 (4)] ... ERROR: deadlock detected
2022-10-12 20:23:27 KST [40P01] [11983 (5)] ... DETAIL: Process 11983 waits for ShareLock on transaction 12179793; blocked by process
11893.
Process 11893 waits for ShareLock on transaction 12179803; blocked by process 12027.
Process 12027 waits for ExclusiveLock on tuple (1881,5) of relation 17109 of database 16384; blocked by process 11983.
Process 11983: update B set ... where id=$1
Process 11893: update A set ... where a=$1 and b=$2
Process 12027: update B set ... where id=$1
2022-10-12 20:23:27 KST [40P01] [11983 (6)] ... HINT: See server log for query details.
2022-10-12 20:23:27 KST [40P01] [11983 (7)] ... CONTEXT: while locking tuple (1881,5) in relation "B"
2022-10-12 20:23:27 KST [40P01] [11983 (8)] ... STATEMENT: update B set ... where id=$1
我在 PostgreSQL 中發現了一個死鎖日志。A 和 B 是不相關的表。為了解決這個問題，我們提出了幾個問題。
- 為什么行程 11983 正在等待行程 11893？
- 行程 12027 是否使用共享鎖，即使它是一個更新陳述句？
- 如何找到 tuple(1881, 5) 的實際資料？
uj5u.com熱心網友回復：
你的第一個問題無法回答。一些鎖被??同一事務中的先前陳述句獲取，并且鎖一直保持到事務結束。您必須查看您的應用程式代碼以找出在這些事務中執行了哪些其他陳述句。
關于你的第二個問題：行程正在等待事務上的共享鎖，這是 PostgreSQL 在等待行鎖時的習慣做法。行鎖并不是永久保存在鎖表中，而是在事務結束時釋放，所以等待事務結束才是正確的做法。
關于第三個問題：
SELECT * FROM b WHERE ctid = '(1881,5)';
如果同時更新或洗掉了該行，那可能什么也找不到。
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/537426.html
上一篇：查詢在sql中查找最新記錄