2. 程式人生 > >PostgreSQL高併發單行更新發生死鎖 2015

PostgreSQL高併發單行更新發生死鎖 2015

阿新 • • 發佈：2019-01-19
這麼簡單的一條SQL，100個併發時居然會發生死鎖，太不可思議了。
發生死鎖的SQL
update_smallrange.sql:
  1. \setrandom id 1 10000
  2. update maintb set name = 'aaaaa12345' where id=:id;

服務端日誌：
點選(此處)摺疊或開啟
  1. < 2015-01-16 20:56:44.189 CST >錯誤: 檢測到死鎖
  2. < 2015-01-16 20:56:44.189 CST >詳細資訊: 程序4880等待在事務 4074284上的ShareLock; 由程序4910阻塞.
  3. 程序4910等待在事務 4080369上的ShareLock;
    由程序4880阻塞.
  4. 程序 4880: update maintb set name = 'aaaaa12345' where id=9692;
  5. 程序 4910: update maintb set name = 'aaaaa12345' where id=9692;
  6. < 2015-01-16 20:56:44.189 CST >提示: 詳細資訊請檢視伺服器日誌.
  7. < 2015-01-16 20:56:44.189 CST >語句: update maintb set name = 'aaaaa12345' where id=9692;
從日誌中可以看出，2個程序更新同一行記錄時發生了死鎖。
但是我的case也不是每次再現，之前測試的時候幾乎100%的
再現概率，但是過了幾天，相同的環境卻一次也沒再現過。

今天偶然翻了下社群的郵件列表，發現這是個已知的BUG。
http://www.postgresql.org/message-id/[email protected]

這個BUG報告中的錯誤訊息有兩種，其中一種和我的是一樣的
死鎖錯誤1：

點選(此處)摺疊或開啟

  1. 2014-07-30 09:41:54 PDT PID:4729 XID:25780 ERROR: deadlock detected
  2. 2014-07-30 09:41:54 PDT PID:4729 XID:25780 DETAIL: Process 4729 waits for ShareLock on transaction 25779;
    blocked by process 4727.
  3. 2014-07-30 09:41:54 PDT PID:4729 XID:25780 HINT: See server log for query details.
  4. 2014-07-30 09:41:54 PDT PID:4729 XID:25780 STATEMENT: UPDATE "z8z6px927zu6qzzbnb5ntgghxg"."access_grants" ag SET last_issued=DEFAULT FROM "z8z6px927zu6qzzbnb5ntgghxg"."oauth_clients" oc WHERE oc.id = ag.client_id AND ag.entity_name = 'user' AND ag.entity_id = 129 AND oc.client_id = '3hp45h9d4f9wwtx7cvpus6rdb4s5kb9f' RETURNING ag.id

死鎖錯誤2：

點選(此處)摺疊或開啟

  1. 2014-07-30 09:41:56 PDT PID:4739 XID:25806 ERROR: deadlock detected
  2. 2014-07-30 09:41:56 PDT PID:4739 XID:25806 DETAIL: Process 4739 waits for ExclusiveLock on tuple (1,98) of relation 16553 of database 16385; blocked by process 4738.
  3. 2014-07-30 09:41:56 PDT PID:4739 XID:25806 HINT: See server log for query details.

這個BUG在9.3.x(9.3.4和9.3.5)上會存在，9.0和9.1等早期版本沒有問題。用我們公司的術語說就是LevelDown了。
點選(此處)摺疊或開啟 
  1. I think this is a regression as we only see the behavior under
postgres 9.3.x (reproduced locally on 9.3.4 and 9.3.5 in a VMWare VM
running Ubuntu 11.04, but also evident in 9.3.3 on Amazon RDS). I am
unable to reproduce in the earlier versions I've been able to test against
(9.0.something and 9.1.9).

好訊息是已經有這個BUG的Patch出來了，相信下次的PG版本釋出會解決這個問題。

相關推薦

PostgreSQL高併發單行更新發生死鎖 2015

這麼簡單的一條SQL，100個併發時居然會發生死鎖，太不可思議了。發生死鎖的SQLupdate_smallrange.sql: \setrandom id 1 10000 update maintb set name = 'aaaaa12345' where id=:i

[think in java2] java 併發發生死鎖的條件

1、互斥條件：      任務使用的資源中至少一個是不能共享的。 2、至少有一個任務它必須持有一個資源且正在等待獲取一個當前被別的任務持有的資源。 3、資源不能被任務搶佔，任務必須把資源釋放當作普通事件。 4、必須有迴圈等待，這是，一個任務等待其他任務所持有的資源，後者又在

高併發程式設計 volatile 和 加鎖 解決快取不一致

因為程式執行都在cpu中，但是如果沒有快取記憶體，cpu大部分的時間都用來了讀取記憶體的資料。 從而Cpu有 快取記憶體，在執行指令前，會把相關需要的資料提前拷貝到cpu，運算完成後在刷回記憶體裡。   快取記憶體主要提前快取資料到cpu，等cpu運算完成後把結果返回給主存

分析一個在高併發下的財務支付鎖的問題

在工作專案中，會遇到一些php併發訪問去修改一個數據問題，如果這個資料不加鎖，就會造成資料的錯誤。下面將分析一個財務支付鎖的問題。希望對大家有所幫助。   1，在沒有應用鎖機制的情況下 1.1 財務支付簡化版本程式碼 <!--?php  /** 

實戰Java高併發程式設計（四、鎖的優化及注意事項）

在多核時代，使用多執行緒可以明顯地提升系統的效能。但事實上，使用多執行緒會額外增加系統的開銷。對於單任務或單執行緒的應用來說，其主要資源消耗在任務本身。對於多執行緒來說，系統除了處理功能需求外，還需要維護多執行緒環境特有的資訊，如執行緒本身的元資料，執行緒的排程，執行緒上下文的切換等。 4.1有

Java 多執行緒高併發 3.3 — Semaphore 共享鎖使用

Semaphore 是共享鎖的一種，字面上意思就是訊號量鎖 顧名思義，一個可以共享的鎖，可以讓多個執行緒共享同一把鎖，例如同一條馬路可以讓 4 臺車同時並行跑，相當於可以讓 4 個執行緒共享一把鎖，臨

SQL SERVER發生死鎖檢測語句

sql server資料庫發生死鎖採用如下SQL語句進行檢索： select object_name(resource_associated_entity_id) as tableName, request_session_id as pid from sys.

發生死鎖的執行緒dump日誌

注意日誌裡面的紅色加粗的日誌 "Thread-1" prio=6 tid=0x000000000d3d3000 nid=0x3414 waiting for monitor entry [0x000000000cc5f000]    java.lang.Thread.Sta

又踩.NET Core的坑：在同步方法中呼叫非同步方法Wait時發生死鎖(deadlock)

之前在將 Memcached 客戶端 EnyimMemcached 遷移 .NET Core 時被這個“坑”坑的刻骨銘心（詳見以下連結），當時以為只是在建構函式中呼叫非同步方法（注：這裡的非同步方法都是指基於Task的）才會出線死鎖（deadlock）問題。 StackExchange.Redis

C++：高併發佇列（含雙鎖[隊頭鎖，隊尾鎖]）

最近再做一個高併發的伺服器處理程式，伺服器要用多執行緒處理大資料量計算，然後將計算結果封裝成訊息放入佇列中，然後另起幾個執行緒專門負責處理訊息佇列中的訊息分發給不同客戶端，這樣瓶頸就出來了，N多執行緒都在頻繁鎖訊息佇列，這樣導致隊裡的利用效率下降一半，無論是入隊還是出隊都要

update 時發生死鎖

報錯資訊： org.springframework.dao.CannotAcquireLockException:  ### Error updating database.  Cause: com.mysql.jdbc.exceptions.jdbc4.MySQLTrans

資料庫發生死鎖，處理方式。

資料庫型別：oracle 查詢死鎖的程序id SELECT l.session_id sid,s.serial#,l.locked_mode 鎖模式,l.oracle_username 登入使用者,l.os_user_name 登入機器使用者名稱,s.machine 機器名,s.termin

高併發架構系列：分散式鎖的由來、特點及Redis分散式鎖的實現詳解

標題Redis記憶體回收機制 Redis的記憶體回收主要圍繞以下兩個方面： 1.Redis過期策略 刪除過期時間的key值 2.Redis淘汰策略 記憶體使用到達maxmemory上限時觸發記憶體淘汰資料 Redis的過期策略和記憶體淘汰策略不是一件事，實際研發中不要弄混淆了

如何實現一個程式快速發生死鎖

遇到一個問題，如何快速發生死鎖，特意總結一下。 1、 死鎖的定義： 死鎖的定義：死鎖是指兩個或兩個以上的程序在執行過程中，由於競爭資源或者由於彼此通訊而造成的一種阻塞的現象，若無外力作用，它們將無法推進下去，此時稱系統處於死鎖狀態或系統產生了死鎖，這些永遠在互相等待的程序成為死鎖程序。

如何實現一個程序快速發生死鎖

其它 一段時間 sync 出了 -type 如果 inf for int 遇到一個問題，如何快速發生死鎖，特意總結一下。 1、死鎖的定義： 死鎖的定義：死鎖是指兩個或兩個以上的進程在執行過程中，由於競爭資源或者由於彼此通信而造成的一種阻塞的現象，若無外力作用，它們將無法推進

java高併發實戰（九）——鎖的優化和注意事項

由於之前看的容易忘記，因此特記錄下來，以便學習總結與更好理解，該系列博文也是第一次記錄，所有有好多不完善之處請見諒與留言指出，如果有幸大家看到該博文，希望報以參考目的看瀏覽，如有錯誤之處，謝謝大家指出與留言。這裡只是講解下鎖優化思路以及方法的總結，具體技術深究以後慢慢補充一、

資料庫以及執行緒發生死鎖的原理及必要條件，如何避免死鎖

（1）互斥條件：一個資源每次只能被一個程序使用。  （2）請求與保持條件：一個程序因請求資源而阻塞時，對已獲得的資源保持不放。  （3）不可剝奪條件：程序已獲得的資源，在末使用完之前，不能強行剝奪。  （4）迴圈等待條件：若干程序之間形成一種頭尾相接的迴圈等待資源關係。 ​避免死鎖：  死鎖的預防是通過破壞

多執行緒死鎖經典案例，必定會發生死鎖

        Java執行緒死鎖是一個經典的多執行緒問題，因為不同的執行緒都在等待根本不可能被釋放的鎖，從而導致所有的任務都無法繼續完成。換言之只要互相等待對方釋放鎖就有可能出現死鎖。下面將用一個簡單的例子加以說明，如有問題，請多多指教。        某日AB兩位壯士各獲

java兩種經典死鎖例子，Lock發生死鎖案列

第一種synchronized方式死鎖：執行緒thread1先獲取鎖locka，然後在同步塊裡巢狀競爭鎖lockb。而執行緒thread2先獲取鎖lockb，然後在同步塊裡巢狀競爭鎖locka（此時已經被執行緒thread1擁有，而thread1在等待lockb，而loc

根據進程數，資源數判斷是否發生死鎖

tle 就會 資源 需要 運行 line ask itl 請求 假設系統中有M個可用資源，N個進程，設每個進程需要的資源數位W。請問哪些情況可能死鎖那些不會死鎖為什麽 M=2，N=2，W=1M=3，N=2，W=2M=3，N=2，W=3M=5，N=3，W=2M=6，N=3，