2011年7月 6日

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

皆様

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

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


佐藤様

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

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


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

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

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


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

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

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


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

2011/6/29 TAKATSUKA Haruka <harukat@xxxxx>:
>> トランザクション2では不定であるため、
>>  B→C→D→A

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

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

説明の補足になれば。

--

投稿者 xml-rpc : 2011年7月 6日 14:47
役に立ちました?:
過去のフィードバック 平均:(0) 総合:(0) 投票回数:(0)
本記事へのTrackback: http://hoop.euqset.org/blog/mt-tb2006.cgi/104870
トラックバック
コメント
コメントする




画像の中に見える文字を入力してください。