[pgsql-jp: 40856] Re: デッドロックについて

[nozawakz ＠ nttdata.co.jp]

皆様

お世話になっております。野沢です。

お礼のご返事が遅れてしまい申し訳ありません。


佐藤様
＞deadlock_timeout パラメータは、デッドロックが発生しないようにアプリケー
＞ションの作り込みを行った上で、無駄なデッドロックの検出処理を実行しない
＞ように増やすものです。

認識誤っておりました。
ご指摘いただき、ありがとうございました。


高塚様
＞# 後から気づきましたが、
＞# WHERE句で条件付けていないなら「断じてテーブルロックすべきだ」
＞# と言うべきですね。テーブル全体を SELECT FOR UPDATE して得をする
＞# ことはなさそうです。

DBでの処理では目標TPSが出ないため、
メモリ上での処理に変更致しました。

PostgreSQLでは性能ボトルネックとなっているのが
どこであるのか解析が困難である印象があります。
Oracleでのbuffer busy waits待機イベントのようなログが
PostgreSQLでも出力できればいいのですが。。


板垣様
＞行のロック順序が常には同じにならない理由は、
＞Postgres が追記型であることも関連しています。

アドバイス頂きましたとおり、
最初の内はデッドロックせず、
しばらく経ってからデッドロックが発生いたしました。

追記型アーキテクチャによる弊害は
DB容量サイジング（vacuum実行までの容量を加える）でもありましたが、
他にもありそうで、怖いですね。


________________________________________
差出人: pgsql-jp-bounces ＠ ml.postgresql.jp [pgsql-jp-bounces ＠ ml.postgresql.jp] は Itagaki Takahiro [itagaki.takahiro ＠ gmail.com] の代理
送信日時: 2011年6月29日 18:38
宛先: PostgreSQL Japanese Mailing List
件名: [pgsql-jp: 40832] Re:       デッドロックについて

2011/6/29 TAKATSUKA Haruka <harukat ＠ postgresql.jp>:
>> トランザクション２では不定であるため、
>>　 B→C→D→A

> SELECT FOR UPDATE の一文の動作自体が、各行を順に行ロックしていく、
> というもので、他のトランザクションと並行で動作していきます。

行のロック順序が常には同じにならない理由は、
Postgres が追記型であることも関連しています。
最初は A→B→C→D の物理順で並んでいても、更新すると
順序が入れ替わる場合があるため、ちょうど入れ替わった
タイミングでデッドロックが発生したんだと思います。

説明の補足になれば。

--
Itagaki Takahiro