[pgcluster: 229] Re: デッドロックもしくはそれに類似した症状について

[Wataru Oguro]

oguroです。お世話になります。

>大量に同じSQL文が書かれているだけなので、単一トランザクションを例示する
>だけで良かったのではないですか？
>
以前、その方法で提示した際にこちらの意図がうまく伝わらなく、現象を確認い
ただくまでに時間がかかっておりましたので、今回はこのような方法で提示した
次第です。
私の説明不足が原因にもかかわらずこのような方法を取り、申し訳ありませんで
した。
以後気をつけたいと思います。

>このトランザクションには、PGclusterから見ると、やっかいな問題が２つあり
>ます。
>・実はlock tableがトランザクション監視対象に入っていない
>・上記をfixしても、実はlock tableとselectがロックで競合して、それで止ま
>る。
>
>このうち、下の件は意外にやっかいですが、トランザクションの設計方針を変え
>る事で回避可能のようです。
>
>・lock tableするのを、selectより先にする。
>・lock tableのレベルを下げる（例えば、exclusive modeとか）
>  
>
なるほど。。
現在のバージョンではlock tableが監視対象外ということは、谷田様のパッチを
適用しない場合はlock tableを含むトランザクションでは同様の症状が発生する
可能性があるということですね。

例えば、

・グループA
　|__ユーザ１
|__ユーザ２

というように、グループAの中にユーザが2つ登録されているとします。
あるアプリケーションが、システムに同時にログインできる人数を制限している
として、グループAに同時1ユーザの制限があるとします。

接続数の把握のために、testテーブルを

test(
　 グループ名 varchar(20) ,
　 接続数 integer
)

といった設計にしているとします。
だれもシステムにログインしていない状態のtestテーブルのレコードは、

グループA 0

となっています。
この時、ユーザ１とユーザ２が同時にログインしようとした場合、自分の所属す
るグループ名をkeyに現在の接続数を取得しますが、ユーザ１とユーザ２が同時
に現在の接続数を取得すると、両ユーザともログインできる事になってしまいます。
そこで、selectもロックするようにlock tableを発行して、その時点でのテーブ
ルのデータを元にチェックを行い、接続数を変更してトランザクションを終了し
ます。

上記のようなケースですと、ロックモードを下げることができないので、トラン
ザクション設計で逃げることができないと思っています。

在庫管理DB等も同じような問題を抱えると思うのですが、lock tableが監視対象
になれば解決かな。。。。と勝手なことを思っていたりします。