[groonga-dev,02228] Re: MroongaストレージモードでINSERT, DELETEが競合してクラッシュ

Back to archive index

Kouhei Sutou kou****@clear*****
2014年 4月 16日 (水) 22:47:55 JST


須藤です。

In <CAHB5oTN9+Bdsk2gAKY8++c3sDDdFSKELMDAaW=7GjY6****@mail*****>
  "[groonga-dev,02226] Re: MroongaストレージモードでINSERT, DELETEが競合してクラッシュ" on Wed, 16 Apr 2014 15:50:33 +0900,
  "yoku ts." <yoku0****@gmail*****> wrote:

>> ロックして他のINSERTの処理とかを同時に動かないようにしても、
>> storage_truncate()した後は他の全部のコネクションで該当テーブ
>> ルをオープンし直さないといけないんです。作りなおしているので、
>> 古い削除済みのテーブルをオープンしたままだとクラッシュするん
>> です。
> 
> (  д ) ?  ? なんと。。

あぁ、すみません。これは別プロセスで同じGroongaのデータベー
スを開いているときでした。Mroongaは同じプロセスで開いている
ので大丈夫でした。

> 取り急ぎ、Mroonga 4.01に↓のパッチを当てて、DELETEでクラッシュしなくなるのを確認しますた。
> https://github.com/mroonga/mroonga/commit/952ae823056a6edff7dac75edcac9b273f831b17

よかったです!

> ところで、パッチ前の状態でも(もちろん、パッチ後の状態でも) INSERTしながらTRUNCATEしてもクラッシュはしませんでした。
> たぶん、sql/sql_truncate.ccのhandler_truncateがopen_and_lock_tables()を呼んでいるから、
> こっちはテーブルレベルロックになって、Mroongaのレイヤーから同士のアクセスは競合しないのだろうなぁと思っています。

なるほど!
とするとユーザーが明示的にロックする必要はないですね。便利!

> mroonga_command()やgroongaコマンドからの直接アクセスだと、
> これが問題になる(TRUNCATE中にさわるとクラッシュする)可能性がある…という感じですよね?(たぶん

そうですね。mroonga_command()はロックのチェックはしていない
ので同じプロセスから同じGroongaのデータベースを開いている
Mroongaでも落ちますね。


-- 
須藤 功平 <kou****@clear*****>
株式会社クリアコード <http://www.clear-code.com/> (03-6231-7270)

Groongaサポート:
  http://groonga.org/ja/support/
パッチ採用はじめました:
  http://www.clear-code.com/recruitment/
コードリーダー育成支援はじめました:
  http://www.clear-code.com/services/code-reader/




groonga-dev メーリングリストの案内
Back to archive index