[pgsql-jp: 33161] Re: PostgreSQL カンファレンスお礼および MySQL のデータが壊れる件

[井久保 寛明]

井久保です。

# ほとんど、しくみ分科会な内容で、ごめんなさい

On Mon, 07 Jun 2004 23:22:27 +0900 (JST)
Tatsuo Ishii <t-ishii＠sra.co.jp> wrote:

> > > 私の理解では，ロックの待ちグラフを作って，その中に閉ループが含まれてい
> > > るかどうか調べる，という方法をPostgreSQLは採用していたと思うのですが，
> > > 他のデッドロックの検出方法というと，どういうのがあるのでしょう？
> > 最後は「タイムアウト」というのもあるようです．
> 
> それはもしかして deadlock_timeout 絡みのタイマーのことですか？あれは，
> ロック待グラフを使ったデッドロック検出アルゴリズムの起動タイマーのこと
> で，デッドロックの検出アルゴリズムの一部ではありません．つまり，ロック
> を取りに行き，deadlock_timeout で設定した時間内にロックが取れないとき
> に始めてデッドロック検出ルーチンが走る仕掛けになっています．これは，無
> 駄にデッドロック検出処理を動かさないための考慮です．

デッドロックの扱いに関して、DBMSとしては２つのポリシーがあります。
(1) デッドロックをまじめに検出する
(2) デッドロックを起こさないようにする or 起きてきても勝手に回避するような
    仕組みをいれておく

(1) のデッドロックをまじめに検出する方法が、石井さんの書かれた閉路検出を
行う Wait For Graph (以下 WFG)です。教科書レベルだとこの方法しか見たこと
ないです。
# そんなに本を読んでいる人間ではないですが...。
利点は、完全にデッドロックを検出できることで、欠点は、ロックのリソースが
多くなりすぎるとグラフが大きくなり非常に重たくなることです。

WTG も２通り使い方があります。
1つ目は、常にWFGを管理し、ロックをとるときに閉路を作らないか常にチェック
する方法。2つ目は、デッドロックを検出するための WFG のチェックルーチンを
定期的に実行する方法です。PostgreSQL は、この２番目の方法を採用している
はずです。
# まだ、このあたりのソースコードは読んでいないですが...


(2) のデッドロックを起こさないようにする or 起きてきても勝手に回避する
ような仕組みの１つが、三谷さんが書いたタイムアウトを使う方法です。

つまり、一定時間以上経過したトランザクションは、必ずロールバックする
という方法です。この方法は、WFG のような非常に重たいものを動かさなくて
いいというメリットがあります。デメリットは、皆さんお気づきだと思います
が、時間がかかるトランザクションがアボートされてしまいます。

(2) の別の方法で、タイムスタンプを利用するものがあります。
これも２つのアプローチに別れます。
１つは、ロックを取る際に、自分より新しい(後に始まった)トランザクションが
ロックを保持していたら待ち、自分より古いトランザクションがロックを保持し
ている場合は、そこであきらめてアボートするという方法です。

もう１つは逆で、自分より新しい(後に始まった)トランザクションが自分がとり
たいロックを保持していたら、ロックを持っているトランザクションを強制
アボートさせて自分がそのロックを取る。自分より古いトランザクションが
ロックを保持していたら開放されるまで待つという方法。

タイムスタンプの場合、どちらの方法にしても、古いトランザクションを優先
することで、WFGでいうところの閉路を作らなくします。


手元の資料ですぐに出てきたのはこんな感じです。

アプリケーションエンジニアレベルでは、デッドロックは起こさないように
システム設計が可能ですから、理不尽にトランザクションがアボートする(2)の
アプローチより、現在 PostgreSQL のとっている WFG で定期的にチェックする
アプローチで、システムでデッドロックが起きないことを確認したら
deadlock_timeout の時間を大きくして、チューニングの１つとするというのが
いいのかなというのが、現在の私の個人的な意見です。


ちなみに、OSレベルのデッドロック取り扱いのポリシーとしては、
ただしく設計すればデッドロックなんて起きないんだから、デッドロック
検出なんてしないという選択をしていたりします。

---
井久保 寛明 (Hiroaki Ikubo)
ＮＴＴデータ先端技術 (株) オープンソース技術部
E-mail: ikubo＠intellilink.co.jp (E-mail: ikuboh＠nttdata.co.jp)