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

[Tatsuo Ishii]

石井です．

> ただし、分類としては、やはり２番目の方に入ると思います。
> １番目の方法は、常にWFGを維持して、ロックを取る瞬間にWFGをチェックし、
> デッドロックの状態を最初から起こさない方法です。

この方法では，WFGをチェックするためにWFGにロックをかけることになるので，
そこがボトルネックになってしまうような気がしますが...

そうすると，結局のところまずはロックを取ってみて，それが取れればもちろ
んデッドロックの可能性はなし，そうでなければデッドロックかもしれないの
で，そのときにはじめてWFGをチェックする，という方法しかないような気が
します．そうすると結局PostgreSQLが今採用している方法に落ち着くことにな
るのでは？

> 「定期的」という書き方がよくなかったようですが、２番目の方法は、
> ロック取得とは別のきっかけで、WFGのルーチンを動作させるという
> つもりでした。

> ふーむ。ただ、無差別にWFGを動かすよりは、もっとデッドロックの可能性の
> 高いところで動かしているわけですね。
> 
> ということは、時間のかかるトランザクションが多くて、かつ、ロックの
> 競合がある場合に、deadlock_timeout のパラメーターが効いてくるという
> ことですね。

はい，まさにその通りで，同時100とか200以上の接続が常にあるような環境で
は deadlock_timeout を大きくしないとてきめんパフォーマンスが劣化します．
--
Tatsuo Ishii