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/
