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

Back to archive index

yoku ts. yoku0****@gmail*****
2014年 4月 16日 (水) 23:32:15 JST


yoku0825です。

mroonga_command()のことは心のどこかにとどめて(おけるといいなぁ。。

色々ありがとうございました!


yoku0825


2014年4月16日 22:47 Kouhei Sutou <kou****@clear*****>:

> 須藤です。
>
> 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 mailing list
> groon****@lists*****
> http://lists.sourceforge.jp/mailman/listinfo/groonga-dev
>



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