Kouhei Sutou
kou****@clear*****
2013年 9月 17日 (火) 21:51:43 JST
須藤です。 In <BAY17****@phx*****> "[groonga-dev,01778] Re: FW: mroonga適用テーブルへの「WHERE IN 多数」クエリでエラー" on Mon, 16 Sep 2013 21:57:51 +0900, Kimura A <a.kim****@live*****> wrote: > 未解決ですが経過報告します。 ありがとうございます！ > 現時点で、最も小さなテーブル構成で問題の再現を確認できたのは以下のケースです。 おぉ、だいぶ絞りこめてきましたね！ INSERTシェルとSELECTシェルを提供してもらえないでしょうか！？ こちらでも試してみたいと思います。 > ただ、このやり方にもどうも問題がありそうです。 > それというのも、このproductsテーブル（45400件でエラーの再現を確認できたときのもの）をテキストファイルにダンプして、 > > ・productsテーブルを削除 > ・テキストファイルからproductsテーブルをインポート > ・cronからSELECTシェルを二重実行 > > としてみても、エラーが再現しないんですよね。 > ダンプしたデータ自体にはエラーを再現する条件が備わっていない（ように見える）、ということです。 なるほど。 とすると、INSERTシェルも同時に実行することが条件みたいですね。 > さらに試みに、このインポートしたproductsテーブルに対して追加的に5分間のINSERTシェルと二重SELECTを交互に実行するという実験もやってみました。 > すると1度目は計49600件になった段階で早々とエラーが再現したのですが、もう1度productsテーブルを消してインポートし直した状態から試すと、今度は計345300件になるまで続けてもエラーは再現しませんでした。 タイミングによっておかしくなるということがわかるので、INSERT と二重SELECTが混ざるとレースコンディションが起きていそうです。 > 以上のように、再現条件の不確かさに悩まされ続けているのが現状です。 > 引き続き、フィールドを減らしての再現実験は続けてみるつもりですが、「エラーが発生したテーブルをダンプ→削除→インポートしてもエラーが再現しない」という問題をどう考えていいものかがわかりません。 INSERTが問題の発生に影響していることが確実、ということがわか ると思います！ -- 須藤 功平 <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/commit-comment.html
