[pgsql-jp: 37829] Re: UPDATE が集中するとデッドロックが発生する

[ISHIDA Akio]

石田です。

06/12/20 に maya<maya ＠ negeta.com> さんは書きました:
> maya です。
>
> > 片岡さんがおっしゃっているのは、2つのクエリが別のプランを
> > 選択した場合で、今回のケースでは2つのクエリがWHERE句も
> > 含めて一緒とのことなので、別のプランを選択することは
> > 無いように思います。
>
> ロック順が不定なら、プランが同じでも競合しないでしょうか？
>
> ただ私としては、「このクエリをなんとかする」ということだけ
> でなく、「範囲が重なる複数行の更新が並行する」という場合に
> MVCC をどうしたらよいか、という汎用的な点も考えていました。
> # 単体の UPDATE 文が並行するだけでデッドロックが起こること
> # が驚きだったので。
>

そうですね。私も起こらないと思っていたので驚きでした。

とりあえず似た状況をpgbenchで作ってみたら再現しました。

$ pgbench -i
した後に、
=> update accounts set bid = (aid + 1) / 1000 + 1;
=> CREATE INDEX accounts_bid_key on accounts (bid);
=> vacuum analyze;
=> explain update accounts set abalance = bid where bid = 1;
                                    QUERY PLAN
----------------------------------------------------------------------------------
 Bitmap Heap Scan on accounts  (cost=10.32..1487.67 rows=950 width=102)
   Recheck Cond: (bid = 1)
   ->  Bitmap Index Scan on accounts_bid_key  (cost=0.00..10.32
rows=950 width=0)
         Index Cond: (bid = 1)
(4 rows)

で、pgbench に実行させるファイルを作って実行してみました。
----
$ cat deadlock.sql
begin;
update accounts set abalance = bid where bid = 1;
end;
$ pgbench -c2 -f deadlock.sql
starting vacuum...end.
Client 1 aborted in state 1: ERROR:  deadlock detected
DETAIL:  Process 29855 waits for ShareLock on transaction 1817;
blocked by process 29854.
Process 29854 waits for ShareLock on transaction 1818; blocked by process 29855.
transaction type: Custom query
----

興味があるので時間を見てもうすこし調べて
みたいと思います。

>
> > もしまだ原因に興味がおありであれば、実行したのはどのような
> > クエリで、また explain でどのようなプランが選択されたのか
> > おしえていただけないでしょうか。
>
> 以下のようになります。
>
> Query:
> update table1 set filed1=field2 where field3=13
>
> Explain:
> Bitmap Heap Scan on table1  (cost=22.24..3367.41 rows=1497 width=54)
>   Recheck Cond: (field3 = 13)
>   ->  Bitmap Index Scan on table1_index1  (cost=0.00..22.24 rows=1497 width=0)
>         Index Cond: (field3 = 13)
>
>
> --
> | maya <maya ＠ negeta.com> |
>


-- 
ISHIDA Akio <iakio ＠ mono-space.net/ishida ＠ cycleof5th.com>