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

[Tatsuo Ishii]

石井です．

> 井久保です。
> 
> # ほとんど、しくみ分科会な内容で、ごめんなさい
> 
> 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 は、この２番目の方法を採用している
> はずです。

そうでしたっけ？私の理解では，PostgreSQLではロックを取りにいったときに
デッドロック検出ルーチンを起動するタイマーをセットし，ロックが取れれば
その時点でタイマーをキャンセル，そうでなければタイマーがエキスパイアし
てデッドロック検出ルーチンが起動される，というふうになっていて，定期的
にチェックルーチンを起動はしていなかったと思うのですが．
--
Tatsuo Ishii