From kadir.tokyo ＠ gmail.com Fri Feb 1 10:59:17 2008 From: kadir.tokyo ＠ gmail.com (Kadir Tokyo) Date: Fri, 1 Feb 2008 10:59:17 +0900 Subject: [Senna-dev 757] =?iso-2022-jp?b?ImludmFsaWQgb2JqZWN0IGFzc2lnbmVkIGluIHF1ZXJ5Ig==?= =?iso-2022-jp?b?GyRCJCw9UE5PJDUkbCRrN28bKEI=?= Message-ID: はじめて投稿させて頂きます。KTと申します。 よろしくお願いします。 過去ログを検索しても該当するものが見当たらなかったため、 ご存知の方がいらっしゃればと思い、投稿させて頂きました。 本番環境を、tritonn1.0.8バイナリ版（mysql5.0.51+senna1.0.9） にバージョンアップしたところ、NOTICEレベルで以下のsennaログが 頻発するようになりました。 ---------------------------------------------------------------------------------------- 01/30:18:55:50.214700|n|115| invalid object assigned in query 01/30:18:55:50.218086|n|115| invalid object assigned in query 01/30:18:57:36.603948|n|120| invalid object assigned in query 01/30:18:57:36.608632|n|120| invalid object assigned in query ・・・・ ---------------------------------------------------------------------------------------- Mecabは使用せず、ngram(デフォルトのバイグラム)のみです。 更新バッチと検索が被ったときに出るかと疑いましたが、 更新のないときも出力されます。 全文検索クエリは、800Mほどのテーブルに対して、 900MのSENNAインデックスを使う次のものです。 select * from A where match(acol, bcol) against ('xxx' in boolean mode) and flag = 1 order by ccol; senna_2indパラメータを使用していますが、 force index句は使用していません。 上記NOTICEログは気にしないでもよろしいのでしょうか。それとも 回避すべきなのでしょうか。 ご教授頂けたらと思います。 よろしくお願い致します。 全文検索できなくなったわけではなく、一見問題なさそうに 見えましたが、見知らぬところでユーザ影響があるといけないので、 念のため以前のバージョンに切り戻しました。 From ikdttr ＠ gmail.com Fri Feb 1 20:14:07 2008 From: ikdttr ＠ gmail.com (Tetsuro IKEDA) Date: Fri, 1 Feb 2008 20:14:07 +0900 Subject: [Senna-dev 758] =?iso-2022-jp?b?VHJpdG9ubiAxLjAuOSAbJEIlaiVqITwlOSROJCpDTiRpGyhC?= =?iso-2022-jp?b?GyRCJDsbKEI=?= Message-ID: こんにちは。池田＠Tritonnプロジェクトです。 Tritonn 1.0.9をリリースしましたのでお知らせさせていただきます。 今回もLinux x86/x86_64向けのtarballバイナリとRPMバイナリ、ソースを一式リリースしております。以下のURLよりお試し下さい。 http://sourceforge.jp/projects/tritonn/ 今回は2ind機能の不具合の修正を行った他、セキュリティ面での修正による緊急リリースが行われたMySQL 5.0.51aに対応したこと、Senna 1.1.0に対応したことがリリースの特徴になります。 ※これらの事情を鑑み、Tritonn 1.0.9へのアップグレードを推奨いたします。 【Tritonn 1.0.9のソフトウェア構成バージョン】 * MySQL 5.0.51a * Senna 1.0.10 * MeCab 0.96 * mecab-ipadic 2.7.0-20070801 【変更点とバグ修正】 * 2ind機能をONにしてFORCE INDEXを使用した場合の不具合を修正。 詳細にご興味のある方は、tritonn-devメーリングリストへご登録下さい。 http://lists.sourceforge.jp/mailman/listinfo/tritonn-dev よろしくお願いいたします。 From kazuhiko ＠ fdiary.net Sat Feb 2 06:34:47 2008 From: kazuhiko ＠ fdiary.net (Kazuhiko) Date: Fri, 01 Feb 2008 22:34:47 +0100 Subject: [Senna-dev 759] Re: =?iso-2022-jp?b?VHJpdG9ubiAxLjAuOSAbJEIlaiVqITwlOSROJCobKEI=?= =?iso-2022-jp?b?GyRCQ04kaSQ7GyhC?= In-Reply-To: References: Message-ID: <47A39077.3040203@fdiary.net> かずひこです。 Tetsuro IKEDA wrote: > Tritonn 1.0.9をリリースしましたのでお知らせさせていただきます。 さっそく、 http://prdownloads.sourceforge.jp/tritonn/29198/tritonn-1.0.9-mysql-5.0.51a.tar.gz からダウンロードしたtarballをビルドしようとしたのですが、 libmysqld/Makefile.amで @SENNA_INCLUDES@ @MECAB_INCLUDES@ が抜けていて、ビルドが通りません。 他にも、 http://svn.sourceforge.jp/svnroot/tritonn/tags/tritonn-1.0.9-mysql-5.0.51/ と比較して #ifdef ENABLE_SENNA がなくなっている箇所が結構あるのが気になりました。 あと、senna suiteが失敗したので、その記録を添付しておきます。 （環境はMandriva Linux 2008.0/i586） お知らせだけで申し訳ないのですが、どうぞよろしくお願いします。 かずひこ -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: senna_suite.log 型: text/x-log サイズ: 3233 バイト 説明: 無し URL: http://lists.sourceforge.jp/mailman/archives/senna-dev/attachments/20080201/e985ca76/attachment.bin From ikdttr ＠ gmail.com Sun Feb 3 11:05:56 2008 From: ikdttr ＠ gmail.com (Tetsuro IKEDA) Date: Sun, 3 Feb 2008 11:05:56 +0900 Subject: [Senna-dev 760] Re: =?iso-2022-jp?b?VHJpdG9ubiAxLjAuOSAbJEIlaiVqITwlOSROJCobKEI=?= =?iso-2022-jp?b?GyRCQ04kaSQ7GyhC?= In-Reply-To: <47A39077.3040203@fdiary.net> References: <47A39077.3040203@fdiary.net> Message-ID: かずひこさん、こんにちは！　池田です。 libmysqld... またもや（＞＜　すみません。。 早速tritonn-1.0.9a?の準備をします。 --suite=sennaでsenna_kwicが失敗しているのは、 たぶんsenna-1.0.9以下とリンクしているためだと思われます。 あの(失敗している)テストケースは、senna-1.0.9以下に含まれる snippet APIの不具合に関するレグレッションテストで、 senna-1.1.0にて修正されている（というのを確認する）です。 宜しくお願いいたします。 08/02/02 に Kazuhiko さんは書きました: > かずひこです。 > > Tetsuro IKEDA wrote: > > Tritonn 1.0.9をリリースしましたのでお知らせさせていただきます。 > > さっそく、 > http://prdownloads.sourceforge.jp/tritonn/29198/tritonn-1.0.9-mysql-5.0.51a.tar.gz > からダウンロードしたtarballをビルドしようとしたのですが、 > libmysqld/Makefile.amで > @SENNA_INCLUDES@ @MECAB_INCLUDES@ > が抜けていて、ビルドが通りません。 > > 他にも、 > http://svn.sourceforge.jp/svnroot/tritonn/tags/tritonn-1.0.9-mysql-5.0.51/ > と比較して > #ifdef ENABLE_SENNA > がなくなっている箇所が結構あるのが気になりました。 > > あと、senna suiteが失敗したので、その記録を添付しておきます。 > （環境はMandriva Linux 2008.0/i586） > > お知らせだけで申し訳ないのですが、どうぞよろしくお願いします。 > かずひこ > -------------- next part -------------- > テキスト形式以外の添付ファイルを保管しました... > ファイル名: senna_suite.log > 型: text/x-log > サイズ: 3233 バイト > 説明: 無し > URL: http://lists.sourceforge.jp/mailman/archives/senna-dev/attachments/20080201/e985ca76/attachment.bin > _______________________________________________ > Senna-dev mailing list > Senna-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/senna-dev > バグ報告方法：http://qwik.jp/senna/bug_report.html > From kazuhiko ＠ fdiary.net Mon Feb 4 07:14:37 2008 From: kazuhiko ＠ fdiary.net (Kazuhiko) Date: Sun, 03 Feb 2008 23:14:37 +0100 Subject: [Senna-dev 761] Re: =?iso-2022-jp?b?VHJpdG9ubiAxLjAuOSAbJEIlaiVqITwlOSROJCobKEI=?= =?iso-2022-jp?b?GyRCQ04kaSQ7GyhC?= In-Reply-To: References: <47A39077.3040203@fdiary.net> Message-ID: <47A63CCD.2020201@fdiary.net> かずひこです。 Tetsuro IKEDA wrote: > libmysqld... またもや（＞＜　すみません。。 > > 早速tritonn-1.0.9a?の準備をします。 お手数をおかけします。m(_ _)m もしリリース予告みたいなのがあれば、事前のビルドとtest suiteの実行くらい はお手伝いできると思います。tarballを用意とかでなく、例えば「...ブランチ をチェックアウトしてテストしてね」程度で十分ですので。 > --suite=sennaでsenna_kwicが失敗しているのは、 > たぶんsenna-1.0.9以下とリンクしているためだと思われます。 > > あの(失敗している)テストケースは、senna-1.0.9以下に含まれる > snippet APIの不具合に関するレグレッションテストで、 > senna-1.1.0にて修正されている（というのを確認する）です。 あ、確かに。テスト環境のsennaは1.0.9のままでした。ごめんなさい。 テストといえば、make testで実行される通常のテストが、fulltext関連でfail になります。例えば、mysql-5.0.51-tritonn-1.0.8でmake test-forceすると、 mysql-test-run in default mode: *** Failing the test(s): blackhole ctype_latin1_de fulltext fulltext2 fulltext_cache fulltext_left_join fulltext_multi fulltext_order_by ndb_restore_different_endian_data query_cache rpl_trigger sp type_enum となりましたが、仕様なのか失敗なのかわかりにくく（fulltext_*はともかく、 blackholeとかctype_latin1_deとか）、不安になります。 これはどうなるのが理想的でしょうか？ * 元のMySQLとの違いがわかるのでt/もr/もこのままでいい * テストが通るようにt/はそのままでr/だけ書き換える * fulltextインデックスをすべてusing no sennaに書き換えて、テストがとおる ようにする どうぞよろしくお願いします。 かずひこ From ikdttr ＠ gmail.com Mon Feb 4 14:35:58 2008 From: ikdttr ＠ gmail.com (Tetsuro IKEDA) Date: Mon, 4 Feb 2008 14:35:58 +0900 Subject: [Senna-dev 762] Re: =?iso-2022-jp?b?VHJpdG9ubiAxLjAuOSAbJEIlaiVqITwlOSROJCobKEI=?= =?iso-2022-jp?b?GyRCQ04kaSQ7GyhC?= In-Reply-To: <47A63CCD.2020201@fdiary.net> References: <47A39077.3040203@fdiary.net> <47A63CCD.2020201@fdiary.net> Message-ID: こんにちは。池田@Tritonnです。 先週リリースさせていただいたTritonn 1.0.9なのですが、 かずひこさんからのご指摘がありましたように、MySQLのconfigure時に --with-embedded-serverを指定するとビルドが通らない不具合が ありましたので、修正版をアップロードさせていただきました。 これはMySQLのソースにlibmysqldディレクトリ用のpatchが 適用されていなかったためで、Tritonnバイナリでは--with-embedded-serverを 指定していないことから、既にリリース済みのバイナリには影響ありません。 従いまして、以下の2つのソースファイルのみ修正版をアップロードさせていただきました。 ファイル名 日付 チェックサム MySQL-5.0.51a-tritonn.1.0.9.src.rpm 2008-02-04 14:24 e1575c6e1674a3e89f88e37f1782ff76 tritonn-1.0.9-mysql-5.0.51a.tar.gz 2008-02-04 14:21 9ba40d4e07db4d6483e63ecf70e1c10c ソース配布版をご利用いただいている方々はお手数ではありますが、 ファイルの再取得をお願いいたします。 ご不便をおかけいたしますが、よろしくお願いいたします。 また、Tritonnをソースからビルドした場合の回帰テストの実行と 判定方法について新たなドキュメントを書きましたので、 ソースからビルドされる方はこちらもごらんいただければ幸いです。 http://qwik.jp/tritonn/regression_test.html よろしくおねがいいたします。 08/02/04 に Kazuhiko さんは書きました: > かずひこです。 > > Tetsuro IKEDA wrote: > > > libmysqld... またもや（＞＜　すみません。。 > > > > 早速tritonn-1.0.9a?の準備をします。 > > お手数をおかけします。m(_ _)m > もしリリース予告みたいなのがあれば、事前のビルドとtest suiteの実行くらい > はお手伝いできると思います。tarballを用意とかでなく、例えば「...ブランチ > をチェックアウトしてテストしてね」程度で十分ですので。 > > > --suite=sennaでsenna_kwicが失敗しているのは、 > > たぶんsenna-1.0.9以下とリンクしているためだと思われます。 > > > > あの(失敗している)テストケースは、senna-1.0.9以下に含まれる > > snippet APIの不具合に関するレグレッションテストで、 > > senna-1.1.0にて修正されている（というのを確認する）です。 > > あ、確かに。テスト環境のsennaは1.0.9のままでした。ごめんなさい。 > > テストといえば、make testで実行される通常のテストが、fulltext関連でfail > になります。例えば、mysql-5.0.51-tritonn-1.0.8でmake test-forceすると、 > > mysql-test-run in default mode: *** Failing the test(s): blackhole > ctype_latin1_de fulltext fulltext2 fulltext_cache fulltext_left_join > fulltext_multi fulltext_order_by ndb_restore_different_endian_data > query_cache rpl_trigger sp type_enum > > となりましたが、仕様なのか失敗なのかわかりにくく（fulltext_*はともかく、 > blackholeとかctype_latin1_deとか）、不安になります。 > これはどうなるのが理想的でしょうか？ > > * 元のMySQLとの違いがわかるのでt/もr/もこのままでいい > * テストが通るようにt/はそのままでr/だけ書き換える > * fulltextインデックスをすべてusing no sennaに書き換えて、テストがとおる > ようにする > > どうぞよろしくお願いします。 > かずひこ > > _______________________________________________ > Senna-dev mailing list > Senna-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/senna-dev > バグ報告方法：http://qwik.jp/senna/bug_report.html > From ntakei ＠ sios.com Mon Feb 4 19:04:46 2008 From: ntakei ＠ sios.com (=?ISO-2022-JP?B?GyRCSXAwZjU5OVQbKEI=?=) Date: Mon, 4 Feb 2008 19:04:46 +0900 (JST) Subject: [Senna-dev 763] =?iso-2022-jp?b?GyRCRkNEaiROGyhCU1FMGyRCSjgkRxsoQk15U1FM?= =?iso-2022-jp?b?GyRCJCxNbiRBJF4kORsoQg==?= Message-ID: <20080204185152.1761.NTAKEI@sios.com> はじめまして。武井と申します。 RHEL上にてtritonn-1.0.2、mysql-4.1.22、senna-1.0.4を構築して使用して おります。ソースから特定の操作をしたときに、MySQLが落ちるエラーが 起こります。 色々な情報をネットで探しましたが、いまだに解決方法がわかりません。 何卒解決方法をご教示の程宜しくお願いします。 ■発生状況 1.元のデータをダンプしたファイルの先頭に、ダンプした各テーブルの DELETE文を記述し、下記のようなSQLを書きます。 ----------------- #データ削除SQLの追記 delete from hoge1; delete from hoge2; delete from hoge3; delete from hoge4; delete from hoge5; #ダンプデータの挿入 insert into hoge1('aaa','bbb','ccc','ddd'),('aaa','bbb','ccc','ddd')... insert into hoge2('aaa','bbb','ccc','ddd'),('aaa','bbb','ccc','ddd')... ----------------- 上記のInsert文の1行のサイズは最大342,744byte、SQL文全体でのサイズは 345,890byteです。 2.上記のようなファイルをmysqlコマンドで実行します。すると下記のような エラーが標準出力に表示され、MySQLが落ちてしまいます。 ERROR 2013 (HY000) at line 1: Lost connection to MySQL server during query そのときmsqlログでは下記のようなログを吐きました。 mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=8388600 read_buffer_size=131072 max_used_connections=2 max_connections=100 threads_connected=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 225791 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xb1c2b00 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0x8451d8, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x8144d83 0x2ba0d1 0x836d716 0x81a5849 0x815a0ba 0x815f695 0x815fb38 0x81616a9 0x4f45c2db 0x4f3b612e New value of fp=(nil) failed sanity check, terminating stack trace! Please read http://dev.mysql.com/doc/mysql/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved stack trace is much more helpful in diagnosing the problem, so please do resolve it Trying to get some variables. Some pointers may be invalid and cause the dump to abort... thd->query at 0xab2a7a0 = delete from t_pdf_tag thd->thread_id=3 The manual page at http://www.mysql.com/doc/en/Crashing.html contains information that should help you find out what is causing the crash. sennaをインストールしないmysql4.1.22では、上記エラーは起こりません。 またdelete文ではなく、truncate文に変更してファイルを実行した場合、 エラーは起こりませんでした。 以上、宜しくお願い申し上げます。 From te.ikeda ＠ jpta.scs.co.jp Mon Feb 4 19:25:42 2008 From: te.ikeda ＠ jpta.scs.co.jp (Tetsuro IKEDA) Date: Mon, 04 Feb 2008 19:25:42 +0900 Subject: [Senna-dev 764] Re: =?iso-2022-jp?b?GyRCRkNEaiROGyhCU1FMGyRCSjgkRxsoQk15U1FM?= =?iso-2022-jp?b?GyRCJCxNbiRBJF4kORsoQg==?= In-Reply-To: <20080204185152.1761.NTAKEI@sios.com> References: <20080204185152.1761.NTAKEI@sios.com> Message-ID: <20080204192301.0A63.TE.IKEDA@jpta.scs.co.jp> こんにちは。池田と申します。 武井さん、バグ報告ありがとうございます。 エラーログにstacktraceが出ていると思うのですが、 お手数ですが下記のページを参考にresolve_stack_dumpを実行した 結果を送っていただけませんでしょうか？ E.1.4. スタックトレースの使用 http://dev.mysql.com/doc/refman/4.1/ja/using-stack-trace.html お手数をおかけして恐縮ですが、よろしくお願いいたします。 > はじめまして。武井と申します。 > > RHEL上にてtritonn-1.0.2、mysql-4.1.22、senna-1.0.4を構築して使用して > おります。ソースから特定の操作をしたときに、MySQLが落ちるエラーが > 起こります。 > > 色々な情報をネットで探しましたが、いまだに解決方法がわかりません。 > 何卒解決方法をご教示の程宜しくお願いします。 > > > ■発生状況 > 1.元のデータをダンプしたファイルの先頭に、ダンプした各テーブルの > DELETE文を記述し、下記のようなSQLを書きます。 > > ----------------- > #データ削除SQLの追記 > delete from hoge1; > delete from hoge2; > delete from hoge3; > delete from hoge4; > delete from hoge5; > > #ダンプデータの挿入 > insert into hoge1('aaa','bbb','ccc','ddd'),('aaa','bbb','ccc','ddd')... > insert into hoge2('aaa','bbb','ccc','ddd'),('aaa','bbb','ccc','ddd')... > ----------------- > > 上記のInsert文の1行のサイズは最大342,744byte、SQL文全体でのサイズは > 345,890byteです。 > > > 2.上記のようなファイルをmysqlコマンドで実行します。すると下記のような > エラーが標準出力に表示され、MySQLが落ちてしまいます。 > > ERROR 2013 (HY000) at line 1: Lost connection to MySQL server during > query > > そのときmsqlログでは下記のようなログを吐きました。 > > mysqld got signal 11; > This could be because you hit a bug. It is also possible that this binary > or one of the libraries it was linked against is corrupt, improperly built, > or misconfigured. This error can also be caused by malfunctioning hardware. > We will try our best to scrape up some info that will hopefully help diagnose > the problem, but since we have already crashed, something is definitely wrong > and this may fail. > > key_buffer_size=8388600 > read_buffer_size=131072 > max_used_connections=2 > max_connections=100 > threads_connected=2 > It is possible that mysqld could use up to > key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 225791 K > bytes of memory > Hope that's ok; if not, decrease some variables in the equation. > > thd=0xb1c2b00 > Attempting backtrace. You can use the following information to find out > where mysqld died. If you see no messages after this, something went > terribly wrong... > Cannot determine thread, fp=0x8451d8, backtrace may not be correct. > Stack range sanity check OK, backtrace follows: > 0x8144d83 > 0x2ba0d1 > 0x836d716 > 0x81a5849 > 0x815a0ba > 0x815f695 > 0x815fb38 > 0x81616a9 > 0x4f45c2db > 0x4f3b612e > New value of fp=(nil) failed sanity check, terminating stack trace! > Please read http://dev.mysql.com/doc/mysql/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. > Resolved stack trace is much more helpful in diagnosing the problem, so please do resolve it > Trying to get some variables. > Some pointers may be invalid and cause the dump to abort... > thd->query at 0xab2a7a0 = delete from t_pdf_tag > thd->thread_id=3 > The manual page at http://www.mysql.com/doc/en/Crashing.html contains > information that should help you find out what is causing the crash. > > > sennaをインストールしないmysql4.1.22では、上記エラーは起こりません。 > またdelete文ではなく、truncate文に変更してファイルを実行した場合、 > エラーは起こりませんでした。 > > 以上、宜しくお願い申し上げます。 > > _______________________________________________ > Senna-dev mailing list > Senna-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/senna-dev > バグ報告方法：http://qwik.jp/senna/bug_report.html ------------------------------ Tetsuro IKEDA Sumisho Computer Systems, Corp. http://www.scs.co.jp/mysql/ ------------------------------ From kazuhiko ＠ fdiary.net Tue Feb 5 06:01:23 2008 From: kazuhiko ＠ fdiary.net (Kazuhiko) Date: Mon, 04 Feb 2008 22:01:23 +0100 Subject: [Senna-dev 765] Re: =?iso-2022-jp?b?VHJpdG9ubiAxLjAuOSAbJEIlaiVqITwlOSROJCobKEI=?= =?iso-2022-jp?b?GyRCQ04kaSQ7GyhC?= In-Reply-To: References: <47A39077.3040203@fdiary.net> <47A63CCD.2020201@fdiary.net> Message-ID: <47A77D23.7070106@fdiary.net> こんにちは、かずひこです。 Tetsuro IKEDA wrote: > 先週リリースさせていただいたTritonn 1.0.9なのですが、 > かずひこさんからのご指摘がありましたように、MySQLのconfigure時に > --with-embedded-serverを指定するとビルドが通らない不具合が > ありましたので、修正版をアップロードさせていただきました。 無事にビルドできて、mecab, senna の各テストが通ることを確認しました。 どうもありがとうございました。 かずひこ From ikdttr ＠ gmail.com Tue Feb 5 10:39:46 2008 From: ikdttr ＠ gmail.com (Tetsuro IKEDA) Date: Tue, 5 Feb 2008 10:39:46 +0900 Subject: [Senna-dev 766] Re: =?iso-2022-jp?b?VHJpdG9ubiAxLjAuOSAbJEIlaiVqITwlOSROJCobKEI=?= =?iso-2022-jp?b?GyRCQ04kaSQ7GyhC?= In-Reply-To: References: <47A39077.3040203@fdiary.net> <47A63CCD.2020201@fdiary.net> Message-ID: たびたびすみません、池田＠Tritonnです。 以下のソース修正版のアップロードですが、 ファイル名を変更した方が良いという声もあり、 以下のファイル名で再アップロードさせていただきました。 - MySQL-5.0.51a-tritonn.1.0.9a.src.rpm - tritonn-1.0.9a-mysql-5.0.51a.tar.gz http://sourceforge.jp/projects/tritonn/files/ お騒がせして済みません。。 08/02/04 に Tetsuro IKEDA さんは書きました: > こんにちは。池田@Tritonnです。 > > 先週リリースさせていただいたTritonn 1.0.9なのですが、 > かずひこさんからのご指摘がありましたように、MySQLのconfigure時に > --with-embedded-serverを指定するとビルドが通らない不具合が > ありましたので、修正版をアップロードさせていただきました。 > > これはMySQLのソースにlibmysqldディレクトリ用のpatchが > 適用されていなかったためで、Tritonnバイナリでは--with-embedded-serverを > 指定していないことから、既にリリース済みのバイナリには影響ありません。 > > 従いまして、以下の2つのソースファイルのみ修正版をアップロードさせていただきました。 > > ファイル名 日付 チェックサム > MySQL-5.0.51a-tritonn.1.0.9.src.rpm 2008-02-04 > 14:24 e1575c6e1674a3e89f88e37f1782ff76 > tritonn-1.0.9-mysql-5.0.51a.tar.gz 2008-02-04 > 14:21 9ba40d4e07db4d6483e63ecf70e1c10c > > ソース配布版をご利用いただいている方々はお手数ではありますが、 > ファイルの再取得をお願いいたします。 > > ご不便をおかけいたしますが、よろしくお願いいたします。 > > また、Tritonnをソースからビルドした場合の回帰テストの実行と > 判定方法について新たなドキュメントを書きましたので、 > ソースからビルドされる方はこちらもごらんいただければ幸いです。 > > http://qwik.jp/tritonn/regression_test.html > > よろしくおねがいいたします。 > > 08/02/04 に Kazuhiko さんは書きました: > > かずひこです。 > > > > Tetsuro IKEDA wrote: > > > > > libmysqld... またもや（＞＜　すみません。。 > > > > > > 早速tritonn-1.0.9a?の準備をします。 > > > > お手数をおかけします。m(_ _)m > > もしリリース予告みたいなのがあれば、事前のビルドとtest suiteの実行くらい > > はお手伝いできると思います。tarballを用意とかでなく、例えば「...ブランチ > > をチェックアウトしてテストしてね」程度で十分ですので。 > > > > > --suite=sennaでsenna_kwicが失敗しているのは、 > > > たぶんsenna-1.0.9以下とリンクしているためだと思われます。 > > > > > > あの(失敗している)テストケースは、senna-1.0.9以下に含まれる > > > snippet APIの不具合に関するレグレッションテストで、 > > > senna-1.1.0にて修正されている（というのを確認する）です。 > > > > あ、確かに。テスト環境のsennaは1.0.9のままでした。ごめんなさい。 > > > > テストといえば、make testで実行される通常のテストが、fulltext関連でfail > > になります。例えば、mysql-5.0.51-tritonn-1.0.8でmake test-forceすると、 > > > > mysql-test-run in default mode: *** Failing the test(s): blackhole > > ctype_latin1_de fulltext fulltext2 fulltext_cache fulltext_left_join > > fulltext_multi fulltext_order_by ndb_restore_different_endian_data > > query_cache rpl_trigger sp type_enum > > > > となりましたが、仕様なのか失敗なのかわかりにくく（fulltext_*はともかく、 > > blackholeとかctype_latin1_deとか）、不安になります。 > > これはどうなるのが理想的でしょうか？ > > > > * 元のMySQLとの違いがわかるのでt/もr/もこのままでいい > > * テストが通るようにt/はそのままでr/だけ書き換える > > * fulltextインデックスをすべてusing no sennaに書き換えて、テストがとおる > > ようにする > > > > どうぞよろしくお願いします。 > > かずひこ > > > > _______________________________________________ > > Senna-dev mailing list > > Senna-dev ＠ lists.sourceforge.jp > > http://lists.sourceforge.jp/mailman/listinfo/senna-dev > > バグ報告方法：http://qwik.jp/senna/bug_report.html > > > -- Tritonn http://qwik.jp/tritonn/ hatena http://d.hatena.ne.jp/mir/ twitter http://twitter.com/_mir_ From ntakei ＠ sios.com Tue Feb 5 13:41:34 2008 From: ntakei ＠ sios.com (=?ISO-2022-JP?B?GyRCSXAwZjU5OVQbKEI=?=) Date: Tue, 5 Feb 2008 13:41:34 +0900 (JST) Subject: [Senna-dev 767] Re: =?iso-2022-jp?b?GyRCRkNEaiROGyhCU1FMGyRCSjgkRxsoQk15U1FM?= =?iso-2022-jp?b?GyRCJCxNbiRBJF4kORsoQg==?= In-Reply-To: <20080204192301.0A63.TE.IKEDA@jpta.scs.co.jp> References: <20080204185152.1761.NTAKEI@sios.com> <20080204192301.0A63.TE.IKEDA@jpta.scs.co.jp> Message-ID: <20080205134008.B626.NTAKEI@sios.com> 池田様 武井です。下記のような感じでよろしいでしょうか。 宜しくお願い致します。 x8144d83 handle_segfault + 643 0x2ba0d1 (?) 0x836d716 mi_delete_all_rows + 326 0x81a5849 _Z12mysql_deleteP3THDP13st_table_listP4ItemP11st_sql_listym + 2057 0x815a0ba _Z21mysql_execute_commandP3THD + 2794 0x815f695 _Z11mysql_parseP3THDPcj + 373 0x815fb38 _Z16dispatch_command19enum_server_commandP3THDPcj + 1096 0x81616a9 handle_one_connection + 2153 0x4f45c2db _end + 1190049507 0x4f3b612e _end + 1189369142 On Mon, 04 Feb 2008 19:25:42 +0900 Tetsuro IKEDA wrote: > こんにちは。池田と申します。 > > 武井さん、バグ報告ありがとうございます。 > > エラーログにstacktraceが出ていると思うのですが、 > お手数ですが下記のページを参考にresolve_stack_dumpを実行した > 結果を送っていただけませんでしょうか？ > > E.1.4. スタックトレースの使用 > http://dev.mysql.com/doc/refman/4.1/ja/using-stack-trace.html > > お手数をおかけして恐縮ですが、よろしくお願いいたします。 > > > > > はじめまして。武井と申します。 > > > > RHEL上にてtritonn-1.0.2、mysql-4.1.22、senna-1.0.4を構築して使用して > > おります。ソースから特定の操作をしたときに、MySQLが落ちるエラーが > > 起こります。 > > > > 色々な情報をネットで探しましたが、いまだに解決方法がわかりません。 > > 何卒解決方法をご教示の程宜しくお願いします。 > > > > > > ■発生状況 > > 1.元のデータをダンプしたファイルの先頭に、ダンプした各テーブルの > > DELETE文を記述し、下記のようなSQLを書きます。 > > > > ----------------- > > #データ削除SQLの追記 > > delete from hoge1; > > delete from hoge2; > > delete from hoge3; > > delete from hoge4; > > delete from hoge5; > > > > #ダンプデータの挿入 > > insert into hoge1('aaa','bbb','ccc','ddd'),('aaa','bbb','ccc','ddd')... > > insert into hoge2('aaa','bbb','ccc','ddd'),('aaa','bbb','ccc','ddd')... > > ----------------- > > > > 上記のInsert文の1行のサイズは最大342,744byte、SQL文全体でのサイズは > > 345,890byteです。 > > > > > > 2.上記のようなファイルをmysqlコマンドで実行します。すると下記のような > > エラーが標準出力に表示され、MySQLが落ちてしまいます。 > > > > ERROR 2013 (HY000) at line 1: Lost connection to MySQL server during > > query > > > > そのときmsqlログでは下記のようなログを吐きました。 > > > > mysqld got signal 11; > > This could be because you hit a bug. It is also possible that this binary > > or one of the libraries it was linked against is corrupt, improperly built, > > or misconfigured. This error can also be caused by malfunctioning hardware. > > We will try our best to scrape up some info that will hopefully help diagnose > > the problem, but since we have already crashed, something is definitely wrong > > and this may fail. > > > > key_buffer_size=8388600 > > read_buffer_size=131072 > > max_used_connections=2 > > max_connections=100 > > threads_connected=2 > > It is possible that mysqld could use up to > > key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 225791 K > > bytes of memory > > Hope that's ok; if not, decrease some variables in the equation. > > > > thd=0xb1c2b00 > > Attempting backtrace. You can use the following information to find out > > where mysqld died. If you see no messages after this, something went > > terribly wrong... > > Cannot determine thread, fp=0x8451d8, backtrace may not be correct. > > Stack range sanity check OK, backtrace follows: > > 0x8144d83 > > 0x2ba0d1 > > 0x836d716 > > 0x81a5849 > > 0x815a0ba > > 0x815f695 > > 0x815fb38 > > 0x81616a9 > > 0x4f45c2db > > 0x4f3b612e > > New value of fp=(nil) failed sanity check, terminating stack trace! > > Please read http://dev.mysql.com/doc/mysql/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. > > Resolved stack trace is much more helpful in diagnosing the problem, so please do resolve it > > Trying to get some variables. > > Some pointers may be invalid and cause the dump to abort... > > thd->query at 0xab2a7a0 = delete from t_pdf_tag > > thd->thread_id=3 > > The manual page at http://www.mysql.com/doc/en/Crashing.html contains > > information that should help you find out what is causing the crash. > > > > > > sennaをインストールしないmysql4.1.22では、上記エラーは起こりません。 > > またdelete文ではなく、truncate文に変更してファイルを実行した場合、 > > エラーは起こりませんでした。 > > > > 以上、宜しくお願い申し上げます。 > > > > _______________________________________________ > > Senna-dev mailing list > > Senna-dev ＠ lists.sourceforge.jp > > http://lists.sourceforge.jp/mailman/listinfo/senna-dev > > バグ報告方法：http://qwik.jp/senna/bug_report.html > > ------------------------------ > Tetsuro IKEDA > Sumisho Computer Systems, Corp. > http://www.scs.co.jp/mysql/ > ------------------------------ > > _______________________________________________ > Senna-dev mailing list > Senna-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/senna-dev > バグ報告方法：http://qwik.jp/senna/bug_report.html ・‥…━━━━━━━━━━━━━━━━━━━━━━━…‥ 　サイオステクノロジー株式会社 　　　Webソリューション部 　　　ネットデザイングループ 　　　武井　宜行 　　　〒105-0001　 東京都港区虎ノ門4-1-28　虎ノ門タワーズ 　　　TEL：03-6860-5127 　　　FAX：03-6860-5135 　　　http://www.sios.com/ ・‥…━━━━━━━━━━━━━━━━━━━━━━━…‥ From ikdttr ＠ gmail.com Tue Feb 5 15:51:10 2008 From: ikdttr ＠ gmail.com (Tetsuro IKEDA) Date: Tue, 5 Feb 2008 15:51:10 +0900 Subject: [Senna-dev 768] Re: =?iso-2022-jp?b?GyRCRkNEaiROGyhCU1FMGyRCSjgkRxsoQk15U1FM?= =?iso-2022-jp?b?GyRCJCxNbiRBJF4kORsoQg==?= In-Reply-To: <20080205134008.B626.NTAKEI@sios.com> References: <20080204185152.1761.NTAKEI@sios.com> <20080204192301.0A63.TE.IKEDA@jpta.scs.co.jp> <20080205134008.B626.NTAKEI@sios.com> Message-ID: こんにちは。池田です。 見たところ、tritonn-1.0.7で修正したバグと関連がありそうです。 http://qwik.jp/tritonn/ChangeLog.html#mysql-5_0_45-tritonn-1_0_7 mysql-4.1.22をお使いということで恐縮なのですが、 tritonn-1.0.7以上( with mysql-5.0系）をお試しいただけますでしょうか？ 宜しくお願いいたします。 08/02/05 に 武井宜行 さんは書きました: > 池田様 > > 武井です。下記のような感じでよろしいでしょうか。 > > 宜しくお願い致します。 > > x8144d83 handle_segfault + 643 > 0x2ba0d1 (?) > 0x836d716 mi_delete_all_rows + 326 > 0x81a5849 _Z12mysql_deleteP3THDP13st_table_listP4ItemP11st_sql_listym + 2057 > 0x815a0ba _Z21mysql_execute_commandP3THD + 2794 > 0x815f695 _Z11mysql_parseP3THDPcj + 373 > 0x815fb38 _Z16dispatch_command19enum_server_commandP3THDPcj + 1096 > 0x81616a9 handle_one_connection + 2153 > 0x4f45c2db _end + 1190049507 > 0x4f3b612e _end + 1189369142 > > > On Mon, 04 Feb 2008 19:25:42 +0900 > Tetsuro IKEDA wrote: > > > こんにちは。池田と申します。 > > > > 武井さん、バグ報告ありがとうございます。 > > > > エラーログにstacktraceが出ていると思うのですが、 > > お手数ですが下記のページを参考にresolve_stack_dumpを実行した > > 結果を送っていただけませんでしょうか？ > > > > E.1.4. スタックトレースの使用 > > http://dev.mysql.com/doc/refman/4.1/ja/using-stack-trace.html > > > > お手数をおかけして恐縮ですが、よろしくお願いいたします。 > > > > > > > > > はじめまして。武井と申します。 > > > > > > RHEL上にてtritonn-1.0.2、mysql-4.1.22、senna-1.0.4を構築して使用して > > > おります。ソースから特定の操作をしたときに、MySQLが落ちるエラーが > > > 起こります。 > > > > > > 色々な情報をネットで探しましたが、いまだに解決方法がわかりません。 > > > 何卒解決方法をご教示の程宜しくお願いします。 > > > > > > > > > ■発生状況 > > > 1.元のデータをダンプしたファイルの先頭に、ダンプした各テーブルの > > > DELETE文を記述し、下記のようなSQLを書きます。 > > > > > > ----------------- > > > #データ削除SQLの追記 > > > delete from hoge1; > > > delete from hoge2; > > > delete from hoge3; > > > delete from hoge4; > > > delete from hoge5; > > > > > > #ダンプデータの挿入 > > > insert into hoge1('aaa','bbb','ccc','ddd'),('aaa','bbb','ccc','ddd')... > > > insert into hoge2('aaa','bbb','ccc','ddd'),('aaa','bbb','ccc','ddd')... > > > ----------------- > > > > > > 上記のInsert文の1行のサイズは最大342,744byte、SQL文全体でのサイズは > > > 345,890byteです。 > > > > > > > > > 2.上記のようなファイルをmysqlコマンドで実行します。すると下記のような > > > エラーが標準出力に表示され、MySQLが落ちてしまいます。 > > > > > > ERROR 2013 (HY000) at line 1: Lost connection to MySQL server during > > > query > > > > > > そのときmsqlログでは下記のようなログを吐きました。 > > > > > > mysqld got signal 11; > > > This could be because you hit a bug. It is also possible that this binary > > > or one of the libraries it was linked against is corrupt, improperly built, > > > or misconfigured. This error can also be caused by malfunctioning hardware. > > > We will try our best to scrape up some info that will hopefully help diagnose > > > the problem, but since we have already crashed, something is definitely wrong > > > and this may fail. > > > > > > key_buffer_size=8388600 > > > read_buffer_size=131072 > > > max_used_connections=2 > > > max_connections=100 > > > threads_connected=2 > > > It is possible that mysqld could use up to > > > key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 225791 K > > > bytes of memory > > > Hope that's ok; if not, decrease some variables in the equation. > > > > > > thd=0xb1c2b00 > > > Attempting backtrace. You can use the following information to find out > > > where mysqld died. If you see no messages after this, something went > > > terribly wrong... > > > Cannot determine thread, fp=0x8451d8, backtrace may not be correct. > > > Stack range sanity check OK, backtrace follows: > > > 0x8144d83 > > > 0x2ba0d1 > > > 0x836d716 > > > 0x81a5849 > > > 0x815a0ba > > > 0x815f695 > > > 0x815fb38 > > > 0x81616a9 > > > 0x4f45c2db > > > 0x4f3b612e > > > New value of fp=(nil) failed sanity check, terminating stack trace! > > > Please read http://dev.mysql.com/doc/mysql/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. > > > Resolved stack trace is much more helpful in diagnosing the problem, so please do resolve it > > > Trying to get some variables. > > > Some pointers may be invalid and cause the dump to abort... > > > thd->query at 0xab2a7a0 = delete from t_pdf_tag > > > thd->thread_id=3 > > > The manual page at http://www.mysql.com/doc/en/Crashing.html contains > > > information that should help you find out what is causing the crash. > > > > > > > > > sennaをインストールしないmysql4.1.22では、上記エラーは起こりません。 > > > またdelete文ではなく、truncate文に変更してファイルを実行した場合、 > > > エラーは起こりませんでした。 > > > > > > 以上、宜しくお願い申し上げます。 > > > > > > _______________________________________________ > > > Senna-dev mailing list > > > Senna-dev ＠ lists.sourceforge.jp > > > http://lists.sourceforge.jp/mailman/listinfo/senna-dev > > > バグ報告方法：http://qwik.jp/senna/bug_report.html > > > > ------------------------------ > > Tetsuro IKEDA > > Sumisho Computer Systems, Corp. > > http://www.scs.co.jp/mysql/ > > ------------------------------ > > > > _______________________________________________ > > Senna-dev mailing list > > Senna-dev ＠ lists.sourceforge.jp > > http://lists.sourceforge.jp/mailman/listinfo/senna-dev > > バグ報告方法：http://qwik.jp/senna/bug_report.html > > > ・‥…━━━━━━━━━━━━━━━━━━━━━━━…‥ > サイオステクノロジー株式会社 > Webソリューション部 > ネットデザイングループ > 武井　宜行 > 〒105-0001　 東京都港区虎ノ門4-1-28　虎ノ門タワーズ > TEL：03-6860-5127 > FAX：03-6860-5135 > http://www.sios.com/ > ・‥…━━━━━━━━━━━━━━━━━━━━━━━…‥ > > _______________________________________________ > Senna-dev mailing list > Senna-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/senna-dev > バグ報告方法：http://qwik.jp/senna/bug_report.html > -- Tritonn http://qwik.jp/tritonn/ hatena http://d.hatena.ne.jp/mir/ twitter http://twitter.com/_mir_ From morita ＠ razil.jp Wed Feb 6 01:32:09 2008 From: morita ＠ razil.jp (morita ＠ razil.jp) Date: Wed, 6 Feb 2008 01:32:09 +0900 Subject: [Senna-dev 769] Re: =?iso-2022-jp?b?ImludmFsaWQgb2JqZWN0IGFzc2lnbmVkIGluIHF1ZXJ5?= =?iso-2022-jp?b?IhskQiQsPVBOTyQ1JGwkazdvGyhC?= In-Reply-To: References: Message-ID: <20080205163209.GA3437@epepe.com> 森と申します。よろしくお願いします。 このメッセージはboolean クエリの解釈に失敗した場合に出力されます。 booleanモードでは、http://qwik.jp/senna/query.html に書かれている 書式に従ってクエリをパースしますが、不正なクエリを受け取って パースに失敗すると、メッセージをsennaログに出力し、該当部分を無視します。 パースに失敗するのは、単語の先頭が'*'であった場合や、 クエリの末尾が'('であった場合などです。 例えば以下のようなクエリが該当します。 match(acol, bcol) against ('(*^_^*)' in boolean mode) 文字列としてこれを検索したい場合には、boolean modeを使用しないか、 match(acol, bcol) against ('"(*^_^*)"' in boolean mode) のように二重引用符で括る方法があります。 このようなメッセージが頻発するのであれば、クエリの書式がユーザさんに あまり理解されてないのかも知れないですね。。 >>> Kadir Tokyo さんは書きました： > はじめて投稿させて頂きます。KTと申します。 > よろしくお願いします。 > > 過去ログを検索しても該当するものが見当たらなかったため、 > ご存知の方がいらっしゃればと思い、投稿させて頂きました。 > > 本番環境を、tritonn1.0.8バイナリ版（mysql5.0.51+senna1.0.9） > にバージョンアップしたところ、NOTICEレベルで以下のsennaログが > 頻発するようになりました。 > ---------------------------------------------------------------------------------------- > 01/30:18:55:50.214700|n|115| invalid object assigned in query > 01/30:18:55:50.218086|n|115| invalid object assigned in query > 01/30:18:57:36.603948|n|120| invalid object assigned in query > 01/30:18:57:36.608632|n|120| invalid object assigned in query > ・・・・ > ---------------------------------------------------------------------------------------- > > Mecabは使用せず、ngram(デフォルトのバイグラム)のみです。 > 更新バッチと検索が被ったときに出るかと疑いましたが、 > 更新のないときも出力されます。 > 全文検索クエリは、800Mほどのテーブルに対して、 > 900MのSENNAインデックスを使う次のものです。 > select * from A > where match(acol, bcol) against ('xxx' in boolean mode) > and flag = 1 > order by ccol; > > senna_2indパラメータを使用していますが、 > force index句は使用していません。 > > 上記NOTICEログは気にしないでもよろしいのでしょうか。それとも > 回避すべきなのでしょうか。 > ご教授頂けたらと思います。 > > よろしくお願い致します。 > > > > > 全文検索できなくなったわけではなく、一見問題なさそうに > 見えましたが、見知らぬところでユーザ影響があるといけないので、 > 念のため以前のバージョンに切り戻しました。 > _______________________________________________ > Senna-dev mailing list > Senna-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/senna-dev > バグ報告方法：http://qwik.jp/senna/bug_report.html > -- morita From morita ＠ razil.jp Wed Feb 6 01:58:48 2008 From: morita ＠ razil.jp (morita ＠ razil.jp) Date: Wed, 6 Feb 2008 01:58:48 +0900 Subject: [Senna-dev 770] Re: =?iso-2022-jp?b?Tk9UGyRCOCE6dyROJF8kcjlUJCYkSBsoQkFORA==?= =?iso-2022-jp?b?GyRCOCE6dyRLJEokQyRGJDckXiQmN28kSyREJCQkRhsoQg==?= In-Reply-To: <479F28E5.4030402@razil.jp> References: <20d51430801290120l5faf0748jb50d27f8a0ed2ea3@mail.gmail.com> <479EF3B7.3090300@razil.jp> <20d51430801290208w74e39844tcb8db37455d492a1@mail.gmail.com> <479F28E5.4030402@razil.jp> Message-ID: <20080205165848.GA4077@epepe.com> 石川さん。はじめまして。森と申します。 ご指摘ありがとうございます! Sennaも「-を単独で使用した場合は空の結果を返す」という仕様に修正します。 近々リリース予定のSenna1.1.1に反映したいと思います。 >>> Tasuku SUENAGA さんは書きました： > 末永です。 > > なるほど、ユーザからの入力としてクエリが発生する可能性がある、 > ということですね。 > ０件ヒット、検討してみます。 > > 一応補足＆蛇足ですが、 > > NOT MATCH (cols) AGAINST ('*D+ ××× ○○○' IN BOOLEAN MODE) > > と書くことで同等の効果を得ることはできると思います。 > って、 > > MATCH (cols) AGAINST ('*D+ -××× -○○○' IN BOOLEAN MODE) > と同等になっていないですね。 > NOT MATCH (cols) AGAINST ('××× ○○○' IN BOOLEAN MODE) > だと同等になりますね。 > > Ikumi Ishikawa さんは書きました: > > 石川です。 > > 返信ありがとうございます！ > > > >> 純粋な興味なんですが、 > >> MATCH (cols) AGAINST ('*D+ -××× -○○○' IN BOOLEAN MODE) > >> のようなクエリを発行する用途ってどういったものなんでしょうか。 > > 現象として確認しているのみですので、特にシステムとして上記のようなクエリが発生する確率は低そうです。 > > > >> 一応、 > >> NOT MATCH (cols) AGAINST ('*D+ ××× ○○○' IN BOOLEAN MODE) > >> と書くことで同等の効果を得ることはできると思います。 > > 説明が足りず、すいません。あと、ありがとうございます。 > > NOT検索のみ指定したばあいは、０件で帰ってきて欲しかったんです。。。 > > NOT検索のみですと、クエリが遅くなるとおもいますので。 > > > > 今は、アプリケーションでNOT検索のみの場合は結果を強制的に０件にするように > > しているのですが、やっぱり気になっていましたので、質問させていただきました。 > > > > > > > > 08/01/29 に Tasuku SUENAGA さんは書きました: > >> 末永です。 > >> > >> 一番最初に指定された「-」は無視されるというのが > >> 現在のSennaの仕様です。 > >> MySQLオリジナルのMATCH AGAINSTの仕様とはズレているようですね。 > >> > >> 純粋な興味なんですが、 > >> MATCH (cols) AGAINST ('*D+ -××× -○○○' IN BOOLEAN MODE) > >> のようなクエリを発行する用途ってどういったものなんでしょうか。 > >> 最終的にどういうクエリを発行するのかの情報があれば、 > >> もっと突っ込んだアドバイスが出来るかもしれません。 > >> > >> 一応、 > >> NOT MATCH (cols) AGAINST ('*D+ ××× ○○○' IN BOOLEAN MODE) > >> と書くことで同等の効果を得ることはできると思います。 > >> > >> Ikumi Ishikawa さんは書きました: > >>> はじめまして。石川と申します。 > >>> > >>> 過去ログをいろいろと拝見させていただいたのですが、該当のものがなかったため、 > >>> 質問させていただきます。 > >>> > >>> [環境1] > >>> MySQL-5.0.41 > >>> tritonn-1.0.3 > >>> senna-1.0.7 > >>> [環境2] > >>> MySQL-5.0.51 > >>> tritonn-1.0.8 > >>> senna-1.0.9 > >>> 環境1,2ともに現象が発生します > >>> > >>> [現象] > >>> SELECT COUNT(foo) FROM bar WHERE MATCH(○○○) AGAINST('*D+ -×××' IN BOOLEAN MODE); > >>> > >>> 上記のようなNOT検索のみを指定したSQLを発行すると、「-」の演算子が無視されて、 > >>> （この場合だと「*D+」のプラグマがあるので、）AND検索になってしまいます。 > >>> > >>> また、('*D+ -××× -○○○' IN BOOLEAN MODE)という形でSQLを発行すると、 > >>> 先頭の「-」演算子のみが無視されてしまい、×××の結果から○○○を除いた結果が検索されます。 > >>> > >>> MySQLのBOOLEAN MODEの仕様を調べたところ、 > >>> http://dev.mysql.com/doc/refman/5.0/en/fulltext-boolean.html > >>> （-の項のNOTE:の部分です。） > >>> なんとなく「単独で使用した場合は空の結果を返す」というようなことが書いてあるような気がします。（すいません曖昧で。。。） > >>> > >>> 現象はSennaの仕様なのでしょうか？ > >>> ご教授いただけたらと思います。 > >>> > >>> よろしくお願いいたします。 > >>> > >>> _______________________________________________ > >>> Senna-dev mailing list > >>> Senna-dev ＠ lists.sourceforge.jp > >>> http://lists.sourceforge.jp/mailman/listinfo/senna-dev > >>> バグ報告方法：http://qwik.jp/senna/bug_report.html > >> --- > >> Tasuku SUENAGA > --- > Tasuku SUENAGA > > _______________________________________________ > Senna-dev mailing list > Senna-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/senna-dev > バグ報告方法：http://qwik.jp/senna/bug_report.html > -- morita From nottegra ＠ gmail.com Wed Feb 6 15:13:24 2008 From: nottegra ＠ gmail.com (Ikumi Ishikawa) Date: Wed, 6 Feb 2008 15:13:24 +0900 Subject: [Senna-dev 771] Re: =?iso-2022-jp?b?Tk9UGyRCOCE6dyROJF8kcjlUJCYkSBsoQkFORA==?= =?iso-2022-jp?b?GyRCOCE6dyRLJEokQyRGJDckXiQmN28kSyREJCQkRhsoQg==?= In-Reply-To: <20080205165848.GA4077@epepe.com> References: <20d51430801290120l5faf0748jb50d27f8a0ed2ea3@mail.gmail.com> <479EF3B7.3090300@razil.jp> <20d51430801290208w74e39844tcb8db37455d492a1@mail.gmail.com> <479F28E5.4030402@razil.jp> <20080205165848.GA4077@epepe.com> Message-ID: <20d51430802052213s358e03b5w3f91116dd8b39c99@mail.gmail.com> 森さん、末永さん。 石川です。 返信が遅くなりまして、ごめんなさい。 > Sennaも「-を単独で使用した場合は空の結果を返す」という仕様に修正します。 > 近々リリース予定のSenna1.1.1に反映したいと思います。 ありがとうございます！ これからもよろしくお願いいたします！ 08/02/06 に morita ＠ razil.jp さんは書きました: > > 石川さん。はじめまして。森と申します。 > > ご指摘ありがとうございます! > > Sennaも「-を単独で使用した場合は空の結果を返す」という仕様に修正します。 > 近々リリース予定のSenna1.1.1に反映したいと思います。 > > > > >>> Tasuku SUENAGA さんは書きました： > > 末永です。 > > > > なるほど、ユーザからの入力としてクエリが発生する可能性がある、 > > ということですね。 > > ０件ヒット、検討してみます。 > > > > 一応補足＆蛇足ですが、 > > > NOT MATCH (cols) AGAINST ('*D+ ××× ○○○' IN BOOLEAN MODE) > > > と書くことで同等の効果を得ることはできると思います。 > > って、 > > > MATCH (cols) AGAINST ('*D+ -××× -○○○' IN BOOLEAN MODE) > > と同等になっていないですね。 > > NOT MATCH (cols) AGAINST ('××× ○○○' IN BOOLEAN MODE) > > だと同等になりますね。 > > > > Ikumi Ishikawa さんは書きました: > > > 石川です。 > > > 返信ありがとうございます！ > > > > > >> 純粋な興味なんですが、 > > >> MATCH (cols) AGAINST ('*D+ -××× -○○○' IN BOOLEAN MODE) > > >> のようなクエリを発行する用途ってどういったものなんでしょうか。 > > > 現象として確認しているのみですので、特にシステムとして上記のようなクエリが発生する確率は低そうです。 > > > > > >> 一応、 > > >> NOT MATCH (cols) AGAINST ('*D+ ××× ○○○' IN BOOLEAN MODE) > > >> と書くことで同等の効果を得ることはできると思います。 > > > 説明が足りず、すいません。あと、ありがとうございます。 > > > NOT検索のみ指定したばあいは、０件で帰ってきて欲しかったんです。。。 > > > NOT検索のみですと、クエリが遅くなるとおもいますので。 > > > > > > 今は、アプリケーションでNOT検索のみの場合は結果を強制的に０件にするように > > > しているのですが、やっぱり気になっていましたので、質問させていただきました。 > > > > > > > > > > > > 08/01/29 に Tasuku SUENAGA さんは書きました: > > >> 末永です。 > > >> > > >> 一番最初に指定された「-」は無視されるというのが > > >> 現在のSennaの仕様です。 > > >> MySQLオリジナルのMATCH AGAINSTの仕様とはズレているようですね。 > > >> > > >> 純粋な興味なんですが、 > > >> MATCH (cols) AGAINST ('*D+ -××× -○○○' IN BOOLEAN MODE) > > >> のようなクエリを発行する用途ってどういったものなんでしょうか。 > > >> 最終的にどういうクエリを発行するのかの情報があれば、 > > >> もっと突っ込んだアドバイスが出来るかもしれません。 > > >> > > >> 一応、 > > >> NOT MATCH (cols) AGAINST ('*D+ ××× ○○○' IN BOOLEAN MODE) > > >> と書くことで同等の効果を得ることはできると思います。 > > >> > > >> Ikumi Ishikawa さんは書きました: > > >>> はじめまして。石川と申します。 > > >>> > > >>> 過去ログをいろいろと拝見させていただいたのですが、該当のものがなかったため、 > > >>> 質問させていただきます。 > > >>> > > >>> [環境1] > > >>> MySQL-5.0.41 > > >>> tritonn-1.0.3 > > >>> senna-1.0.7 > > >>> [環境2] > > >>> MySQL-5.0.51 > > >>> tritonn-1.0.8 > > >>> senna-1.0.9 > > >>> 環境1,2ともに現象が発生します > > >>> > > >>> [現象] > > >>> SELECT COUNT(foo) FROM bar WHERE MATCH(○○○) AGAINST('*D+ -×××' IN BOOLEAN MODE); > > >>> > > >>> 上記のようなNOT検索のみを指定したSQLを発行すると、「-」の演算子が無視されて、 > > >>> （この場合だと「*D+」のプラグマがあるので、）AND検索になってしまいます。 > > >>> > > >>> また、('*D+ -××× -○○○' IN BOOLEAN MODE)という形でSQLを発行すると、 > > >>> 先頭の「-」演算子のみが無視されてしまい、×××の結果から○○○を除いた結果が検索されます。 > > >>> > > >>> MySQLのBOOLEAN MODEの仕様を調べたところ、 > > >>> http://dev.mysql.com/doc/refman/5.0/en/fulltext-boolean.html > > >>> （-の項のNOTE:の部分です。） > > >>> なんとなく「単独で使用した場合は空の結果を返す」というようなことが書いてあるような気がします。（すいません曖昧で。。。） > > >>> > > >>> 現象はSennaの仕様なのでしょうか？ > > >>> ご教授いただけたらと思います。 > > >>> > > >>> よろしくお願いいたします。 > > >>> > > >>> _______________________________________________ > > >>> Senna-dev mailing list > > >>> Senna-dev ＠ lists.sourceforge.jp > > >>> http://lists.sourceforge.jp/mailman/listinfo/senna-dev > > >>> バグ報告方法：http://qwik.jp/senna/bug_report.html > > >> --- > > >> Tasuku SUENAGA > > --- > > Tasuku SUENAGA > > > > _______________________________________________ > > Senna-dev mailing list > > Senna-dev ＠ lists.sourceforge.jp > > http://lists.sourceforge.jp/mailman/listinfo/senna-dev > > バグ報告方法：http://qwik.jp/senna/bug_report.html > > > -- > morita > > _______________________________________________ > Senna-dev mailing list > Senna-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/senna-dev > バグ報告方法：http://qwik.jp/senna/bug_report.html > From a ＠ razil.jp Thu Feb 7 18:27:36 2008 From: a ＠ razil.jp (Tasuku Suenaga) Date: Thu, 7 Feb 2008 18:27:36 +0900 Subject: [Senna-dev 772] =?iso-2022-jp?b?U2VubmEgMS4xLjEbJEIkciVqJWohPCU5JDckXiQ3JD8bKEI=?= =?iso-2022-jp?b?GyRCISMbKEI=?= Message-ID: <4319463c0802070127s455056adu5813e52c8b78db77@mail.gmail.com> 末永です。 Senna 1.1.1をリリースしました。 http://sourceforge.jp/projects/senna/files/ - Senna 1.1.0とAPIの互換性は「保たれていません」！ sen_index_infoのシグネチャが変更になりました。 - Senna 1.1.0とインデックスの互換性は保たれています。 Tritonn/Ludiaとも 現Senna 1.1.1に対応したものはまだリリースされておりません。 稼働環境に間違ってインストールされないようご注意ください。 ●変更点 * SennaQLの機能追加・バグ修正 * sen_snip系APIで空文字列の受け入れを許可、バグ修正 * クエリ書式で、一番初めに-が指定された場合、 その単語についてまったく検索を行わないように仕様変更 * sen_index_infoの引数変更 --- Tasuku SUENAGA From ikdttr ＠ gmail.com Fri Feb 8 15:34:29 2008 From: ikdttr ＠ gmail.com (Tetsuro IKEDA) Date: Fri, 8 Feb 2008 15:34:29 +0900 Subject: [Senna-dev 773] Re: =?iso-2022-jp?b?U2VubmEgMS4xLjEbJEIkciVqJWohPCU5JDckXiQ3GyhC?= =?iso-2022-jp?b?GyRCJD8hIxsoQg==?= In-Reply-To: <4319463c0802070127s455056adu5813e52c8b78db77@mail.gmail.com> References: <4319463c0802070127s455056adu5813e52c8b78db77@mail.gmail.com> Message-ID: こんにちは。池田です。 Senna 1.1.1リリースおめでとうございます！ Tritonnではver1.1.0およびver1.0.10にてAPI対応を行う予定です。 尚、これまでのTritonnとSennaのバージョンの互換性は以下の ページにまとめてあります。ご参考まで。 http://qwik.jp/tritonn/reference.html#6e23c08f524c423e9e493a13dc0c4e94 08/02/07 に Tasuku Suenaga さんは書きました: > 末永です。 > > Senna 1.1.1をリリースしました。 > http://sourceforge.jp/projects/senna/files/ > > - Senna 1.1.0とAPIの互換性は「保たれていません」！ > sen_index_infoのシグネチャが変更になりました。 > - Senna 1.1.0とインデックスの互換性は保たれています。 > > Tritonn/Ludiaとも > 現Senna 1.1.1に対応したものはまだリリースされておりません。 > 稼働環境に間違ってインストールされないようご注意ください。 > > ●変更点 > * SennaQLの機能追加・バグ修正 > * sen_snip系APIで空文字列の受け入れを許可、バグ修正 > * クエリ書式で、一番初めに-が指定された場合、 > その単語についてまったく検索を行わないように仕様変更 > * sen_index_infoの引数変更 > > --- > Tasuku SUENAGA > > _______________________________________________ > Senna-dev mailing list > Senna-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/senna-dev > バグ報告方法：http://qwik.jp/senna/bug_report.html > -- Tritonn http://qwik.jp/tritonn/ hatena http://d.hatena.ne.jp/mir/ twitter http://twitter.com/_mir_ From sino ＠ valley.ne.jp Fri Feb 8 12:51:56 2008 From: sino ＠ valley.ne.jp (=?ISO-2022-JP?B?QWtpaGlrbyBTaGlub2hhcmE=?=) Date: Fri, 8 Feb 2008 12:51:56 +0900 (JST) Subject: [Senna-dev 774] =?iso-2022-jp?b?aW5kZXggZnVsbC4gc2V0IGJpZ2dlciB2YWx1ZSB0byBpbml0?= =?iso-2022-jp?b?aWFsX25fc2VnbWVudHM=?= Message-ID: <200802080351.m183pu9b011820@raidenm1.valley.ne.jp> こんにちは、篠原と申します。 MySQLバインディングでSennaを使用させてもらってます。 Senna: 1.1.0 Tritonn: 1.0.9 OS: CentOS 5.1 どうも最近登録したデータの検索ができないなぁと思い、メッセージを表示 させてみたところ、データ登録時に以下のメッセージが大量に出力されて います。 > index full. set bigger value to initial_n_segments. current value = 512 1. 登録したデータが検索できない（インデックスに反映されない）のは、 　 INITIAL_N_SEGMENTSのサイズに起因しますか？ 2. INITIAL_N_SEGMENTSのサイズを変更したいのですが、 　　動的に（インデックス作成後）に変える方法はありますか？ よろしくお願いします。 From sino ＠ valley.ne.jp Fri Feb 8 18:56:48 2008 From: sino ＠ valley.ne.jp (=?ISO-2022-JP?B?QWtpaGlrbyBTaGlub2hhcmE=?=) Date: Fri, 8 Feb 2008 18:56:48 +0900 (JST) Subject: [Senna-dev 775] NO SUBJECT Message-ID: <200802080956.m189umsw003696@raidenm1.valley.ne.jp> こんにちは、篠原と申します。 MySQLバインドで、Sennaを使用させて頂いています。 Senna: 1.1.0 Tritonn: 1.0.9 OS: CentOS 5.1 追加登録したデータで検索できない状況が発生したので、ログを表示 させてみたところ、データ登録時に、以下のメッセージが大量に表示 されます。 > flushing *a=52691136 seg=201(0x2aaafd2ff000) free=0 > index full. set bigger value to initial_n_segments. current value = 512 これは、INITIAL_N_SEGMENTを増やせば良いという問題でしょうか？ また、Tritonnから、INITIAL_N_SEGMENTを動的（インデックス作成後）に 変更する方法ってありましたでしょうか？ よろしくお願いします。 From sly2199 ＠ yahoo.co.jp Sun Feb 10 23:08:57 2008 From: sly2199 ＠ yahoo.co.jp (=?ISO-2022-JP?B?GyRCQ2ZEVCEhPy41MRsoQg==?=) Date: Sun, 10 Feb 2008 23:08:57 +0900 (JST) Subject: [Senna-dev 776] =?iso-2022-jp?b?UEhQIBskQiVQJSQlcyVHJSMlcyUwGyhC?= Message-ID: <20080210140857.38240.qmail@web3011.mail.tnz.yahoo.co.jp> はじめまして、中辻と申します。 senna 1.1.0とmecab 0.96を導入しPHPで使用しようとした のですがApacheのエラーログに下記のエラーが出力され 使うことが出来ません。 PHP Parse error: syntax error, unexpected ';', expecting T_FUNCTION in /var/www/html/sen_ctx.phpclass on line 115 PHPバインディングを使用することは出来ないのでしょうか？ -------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ From a ＠ razil.jp Mon Feb 11 18:22:25 2008 From: a ＠ razil.jp (Tasuku SUENAGA) Date: Mon, 11 Feb 2008 18:22:25 +0900 Subject: [Senna-dev 777] Re: index full. set bigger value to initial_n_segments In-Reply-To: <200802080351.m183pu9b011820@raidenm1.valley.ne.jp> References: <200802080351.m183pu9b011820@raidenm1.valley.ne.jp> Message-ID: <47B013D1.1030601@razil.jp> 末永と申します。 > 1. 登録したデータが検索できない（インデックスに反映されない）のは、 > 　 INITIAL_N_SEGMENTSのサイズに起因しますか？ > > 2. INITIAL_N_SEGMENTSのサイズを変更したいのですが、 > 　　動的に（インデックス作成後）に変える方法はありますか？ 1. initial_n_segmentsのサイズに起因します。 2. initial_n_segmentsの動的な更新はできません。 Tritonnでの利用とのことなので、 テーブル構成が同じテーブルを作成し、 USING 1024などinitial_n_segmentsを指定して全文検索インデックスを作成し、 insert into new_table select * from old_table; などのクエリでコピーすることによって対応することになると思います。 個人的な興味としては、 検索対象の ・件数 ・データ量 ・テキストの種別 の３点が気になります。 Akihiko Shinohara さんは書きました: > こんにちは、篠原と申します。 > > MySQLバインディングでSennaを使用させてもらってます。 > Senna: 1.1.0 > Tritonn: 1.0.9 > OS: CentOS 5.1 > > どうも最近登録したデータの検索ができないなぁと思い、メッセージを表示 > させてみたところ、データ登録時に以下のメッセージが大量に出力されて > います。 >> index full. set bigger value to initial_n_segments. current value = 512 > > 1. 登録したデータが検索できない（インデックスに反映されない）のは、 > 　 INITIAL_N_SEGMENTSのサイズに起因しますか？ > > 2. INITIAL_N_SEGMENTSのサイズを変更したいのですが、 > 　　動的に（インデックス作成後）に変える方法はありますか？ > > よろしくお願いします。 --- tasuku From a ＠ razil.jp Mon Feb 11 18:23:34 2008 From: a ＠ razil.jp (Tasuku SUENAGA) Date: Mon, 11 Feb 2008 18:23:34 +0900 Subject: [Senna-dev 778] Re: =?iso-2022-jp?b?UEhQIBskQiVQJSQlcyVHJSMlcyUwGyhC?= In-Reply-To: <20080210140857.38240.qmail@web3011.mail.tnz.yahoo.co.jp> References: <20080210140857.38240.qmail@web3011.mail.tnz.yahoo.co.jp> Message-ID: <47B01416.2060108@razil.jp> 末永です。 バグです。 sen_ctx.phpclassの42行目に ----- } ----- と}だけの行を１行追加してください。 次のリリースで修正したいと思います。 中辻　信輝 さんは書きました: > はじめまして、中辻と申します。 > > senna 1.1.0とmecab 0.96を導入しPHPで使用しようとした > のですがApacheのエラーログに下記のエラーが出力され > 使うことが出来ません。 > > PHP Parse error: syntax error, unexpected ';', expecting > T_FUNCTION in /var/www/html/sen_ctx.phpclass on line 115 > > PHPバインディングを使用することは出来ないのでしょうか？ --- tasuku From kadir.tokyo ＠ gmail.com Tue Feb 12 10:28:21 2008 From: kadir.tokyo ＠ gmail.com (Kadir Tokyo) Date: Tue, 12 Feb 2008 10:28:21 +0900 Subject: [Senna-dev 779] Re: =?iso-2022-jp?b?ImludmFsaWQgb2JqZWN0IGFzc2lnbmVkIGluIHF1ZXJ5?= =?iso-2022-jp?b?IhskQiQsPVBOTyQ1JGwkazdvGyhC?= In-Reply-To: <20080205163209.GA3437@epepe.com> References: <20080205163209.GA3437@epepe.com> Message-ID: 森さま KTです。返事が遅くなり申し訳ありません。 ご教授ありがとうございました。 予約語のときに2重引用符で括るといったことは AP側で特別していないと思いますので、 確認してみたいと思います。 Tritonnバージョンアップ前もAP側に変更点はないのですが、 バージョンアップ前はこのログが出ていませんので、 ログ出力の仕様が変わったということなのでしょうか。 AP側で上手くやるように検討してみます。 ありがとうございました。 08/02/06 に morita ＠ razil.jp さんは書きました: > > 森と申します。よろしくお願いします。 > > このメッセージはboolean クエリの解釈に失敗した場合に出力されます。 > > booleanモードでは、http://qwik.jp/senna/query.html に書かれている > 書式に従ってクエリをパースしますが、不正なクエリを受け取って > パースに失敗すると、メッセージをsennaログに出力し、該当部分を無視します。 > > パースに失敗するのは、単語の先頭が'*'であった場合や、 > クエリの末尾が'('であった場合などです。 > > 例えば以下のようなクエリが該当します。 > > match(acol, bcol) against ('(*^_^*)' in boolean mode) > > 文字列としてこれを検索したい場合には、boolean modeを使用しないか、 > > match(acol, bcol) against ('"(*^_^*)"' in boolean mode) > > のように二重引用符で括る方法があります。 > > > このようなメッセージが頻発するのであれば、クエリの書式がユーザさんに > あまり理解されてないのかも知れないですね。。 > > > >>> Kadir Tokyo さんは書きました： > > はじめて投稿させて頂きます。KTと申します。 > > よろしくお願いします。 > > > > 過去ログを検索しても該当するものが見当たらなかったため、 > > ご存知の方がいらっしゃればと思い、投稿させて頂きました。 > > > > 本番環境を、tritonn1.0.8バイナリ版（mysql5.0.51+senna1.0.9） > > にバージョンアップしたところ、NOTICEレベルで以下のsennaログが > > 頻発するようになりました。 > > ---------------------------------------------------------------------------------------- > > 01/30:18:55:50.214700|n|115| invalid object assigned in query > > 01/30:18:55:50.218086|n|115| invalid object assigned in query > > 01/30:18:57:36.603948|n|120| invalid object assigned in query > > 01/30:18:57:36.608632|n|120| invalid object assigned in query > > ・・・・ > > ---------------------------------------------------------------------------------------- > > > > Mecabは使用せず、ngram(デフォルトのバイグラム)のみです。 > > 更新バッチと検索が被ったときに出るかと疑いましたが、 > > 更新のないときも出力されます。 > > 全文検索クエリは、800Mほどのテーブルに対して、 > > 900MのSENNAインデックスを使う次のものです。 > > select * from A > > where match(acol, bcol) against ('xxx' in boolean mode) > > and flag = 1 > > order by ccol; > > > > senna_2indパラメータを使用していますが、 > > force index句は使用していません。 > > > > 上記NOTICEログは気にしないでもよろしいのでしょうか。それとも > > 回避すべきなのでしょうか。 > > ご教授頂けたらと思います。 > > > > よろしくお願い致します。 > > > > > > > > > > 全文検索できなくなったわけではなく、一見問題なさそうに > > 見えましたが、見知らぬところでユーザ影響があるといけないので、 > > 念のため以前のバージョンに切り戻しました。 > > _______________________________________________ > > Senna-dev mailing list > > Senna-dev ＠ lists.sourceforge.jp > > http://lists.sourceforge.jp/mailman/listinfo/senna-dev > > バグ報告方法：http://qwik.jp/senna/bug_report.html > > > -- > morita > > _______________________________________________ > Senna-dev mailing list > Senna-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/senna-dev > バグ報告方法：http://qwik.jp/senna/bug_report.html > From kousakadi ＠ nttdata.co.jp Thu Feb 14 11:40:14 2008 From: kousakadi ＠ nttdata.co.jp (kousakadi ＠ nttdata.co.jp) Date: Thu, 14 Feb 2008 11:40:14 +0900 Subject: [Senna-dev 780] =?iso-2022-jp?b?c2VuX3F1ZXJ5X3NjYW4bJEIkThsoQisbJEI4ITp3GyhC?= Message-ID: <178CD7FD87EF4B4BB23F3D0B6C201D3F048F7913@MAILSV11.msg.nttdata.co.jp> 幸坂です。こんにちは。 sen_query_scanで '今日 +明日' と検索すると、正常にスキャンできません。 '今日' と同じ結果になります。 ソースを覗いたところ、query.cのscan_keywordの sen_sel_andの処理がおかしいように見受けられます。 case sen_sel_and : if (tf) { *found &= 1; *score += w * tf; } break; ↓正しくは case sen_sel_and : if (tf) { *found &= 1; *score += w * tf; } else { *found = 0; } break; いかがでしょうか？ From a ＠ razil.jp Mon Feb 18 00:18:55 2008 From: a ＠ razil.jp (Tasuku Suenaga) Date: Mon, 18 Feb 2008 00:18:55 +0900 Subject: [Senna-dev 781] Re: =?iso-2022-jp?b?c2VuX3F1ZXJ5X3NjYW4bJEIkThsoQisbJEI4ITp3GyhC?= In-Reply-To: <178CD7FD87EF4B4BB23F3D0B6C201D3F048F7913@MAILSV11.msg.nttdata.co.jp> References: <178CD7FD87EF4B4BB23F3D0B6C201D3F048F7913@MAILSV11.msg.nttdata.co.jp> Message-ID: <4319463c0802170718g5136611dud7b9c14dd66ea44b@mail.gmail.com> 末永です！こんばんは。 > sen_query_scanで > '今日 +明日' > と検索すると、正常にスキャンできません。 > '今日' > と同じ結果になります。 上記の問題をリビジョン735で修正してみました！ ご確認ください。 08/02/14 に kousakadi ＠ nttdata.co.jp さんは書きました: > 幸坂です。こんにちは。 > > sen_query_scanで > '今日 +明日' > と検索すると、正常にスキャンできません。 > '今日' > と同じ結果になります。 > > ソースを覗いたところ、query.cのscan_keywordの > sen_sel_andの処理がおかしいように見受けられます。 > > case sen_sel_and : > if (tf) { > *found &= 1; > *score += w * tf; > } > break; > > ↓正しくは > > case sen_sel_and : > if (tf) { > *found &= 1; > *score += w * tf; > } else { > *found = 0; > } > break; > > いかがでしょうか？ --- Tasuku SUENAGA From kousakadi ＠ nttdata.co.jp Mon Feb 18 09:18:46 2008 From: kousakadi ＠ nttdata.co.jp (kousakadi ＠ nttdata.co.jp) Date: Mon, 18 Feb 2008 09:18:46 +0900 Subject: [Senna-dev 782] Re: =?iso-2022-jp?b?c2VuX3F1ZXJ5X3NjYW4bJEIkThsoQisbJEI4ITp3GyhC?= References: <178CD7FD87EF4B4BB23F3D0B6C201D3F048F7913@MAILSV11.msg.nttdata.co.jp> <4319463c0802170718g5136611dud7b9c14dd66ea44b@mail.gmail.com> Message-ID: <178CD7FD87EF4B4BB23F3D0B6C201D3F048F7922@MAILSV11.msg.nttdata.co.jp> 幸坂です。こんにちは。 > 上記の問題をリビジョン735で修正してみました！ > ご確認ください。 確認いたしました。 バッチリ対応しているようです。 ご対応ありがとうございました！ > -----Original Message----- > From: senna-dev-bounces ＠ lists.sourceforge.jp > [mailto:senna-dev-bounces ＠ lists.sourceforge.jp] On Behalf Of > Tasuku Suenaga > Sent: Monday, February 18, 2008 12:19 AM > To: sennaの開発に関する日本語での議論 > Subject: [Senna-dev 781] Re:sen_query_scanの+検索 > > 末永です！こんばんは。 > > > sen_query_scanで > > '今日 +明日' > > と検索すると、正常にスキャンできません。 > > '今日' > > と同じ結果になります。 > > 上記の問題をリビジョン735で修正してみました！ > ご確認ください。 > > 08/02/14 に kousakadi ＠ nttdata.co.jp さんは書きま した: > > 幸坂です。こんにちは。 > > > > sen_query_scanで > > '今日 +明日' > > と検索すると、正常にスキャンできません。 > > '今日' > > と同じ結果になります。 > > > > ソースを覗いたところ、query.cのscan_keywordの > > sen_sel_andの処理がおかしいように見受けられます。 > > > > case sen_sel_and : > > if (tf) { > > *found &= 1; > > *score += w * tf; > > } > > break; > > > > ↓正しくは > > > > case sen_sel_and : > > if (tf) { > > *found &= 1; > > *score += w * tf; > > } else { > > *found = 0; > > } > > break; > > > > いかがでしょうか？ > --- > Tasuku SUENAGA > > _______________________________________________ > Senna-dev mailing list > Senna-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/senna-dev > バグ報告方法：http://qwik.jp/senna/bug_report.html > From sino ＠ valley.ne.jp Wed Feb 20 00:26:09 2008 From: sino ＠ valley.ne.jp (Akihiko Shinohara) Date: Wed, 20 Feb 2008 00:26:09 +0900 Subject: [Senna-dev 783] Re: index full. set bigger value toinitial_n_segments References: <200802080351.m183pu9b011820@raidenm1.valley.ne.jp> <47B013D1.1030601@razil.jp> Message-ID: <000901c8730b$c09d54f0$0300a8c0@blackbox> こんにちは、篠原です。 返事がとても遅くなってしまいました。すいません。 > 個人的な興味としては、 > 検索対象の > ・件数 > ・データ量 > ・テキストの種別 > の３点が気になります。 まず、この件ですが、2つの環境として (1) 新規登録環境 (a). 件数　約300万件 (b). データ量　約20GB (c). テキストの種類　MEDIUMTEXT ,SJISコード (2) 0.8系で使用していたテーブルからのインデックス再作成 (a). 件数　約300万件 (b). データ量　約13GB (c). テキストの種類　MEDIUMTEXT ,SJISコード 但し、変換元のテーブルの型は、TEXTなので、最大でもTEXTのサイズを 超えることはありません。 という環境です。 今まで、INITIAL_N_SEGMENTSは、使用メモリサイズとスピードに関連する パラメータと思っていて、あまり気にしていませんでしたが、 実は、以下の説明にもあるように、 http://lists.sourceforge.jp/mailman/archives/senna-dev/2006-February/000197.html 初期値の512の設定だと、最大8G程度のインデックスしか作成できないという制限な のです ね、言い換えれば、形態素解析では、ほぼテーブルサイズのインデックスとなり N-gramのインデックスでは、テーブルサイズの1.5倍程度のインデックスとなるので 形態素解析では、8G N-gramでは、5.3G のへんが境界線という事でしょうか。 という事で最初に示した環境は無謀もいいところですね。（＾＾； INITIAL_N_SEGMENTSを調整することで無事にインデックスが 作成できました。 ありがとうございました。 ---- sino From a ＠ razil.jp Wed Feb 20 02:13:49 2008 From: a ＠ razil.jp (Tasuku SUENAGA) Date: Wed, 20 Feb 2008 02:13:49 +0900 Subject: [Senna-dev 784] Re: index full. set bigger value toinitial_n_segments In-Reply-To: <000901c8730b$c09d54f0$0300a8c0@blackbox> References: <200802080351.m183pu9b011820@raidenm1.valley.ne.jp> <47B013D1.1030601@razil.jp> <000901c8730b$c09d54f0$0300a8c0@blackbox> Message-ID: <47BB0E4D.6020104@razil.jp> 末永です。 過去のMLから情報をまとめてくださってありがとうございます！！ もう少し具体的な情報を含んだ返信メールを出せばよかったと 反省しているところです… > 今まで、INITIAL_N_SEGMENTSは、使用メモリサイズとスピードに関連する > パラメータと思っていて、あまり気にしていませんでしたが、(後略) 使用メモリサイズ・スピード・最大インデックスサイズの３つの要素に影響します。 正確に言うと、 メモリにマップされた更新用バッファファイルのサイズを指定するパラメータです。 今回の篠原さんのように大きなデータ量のテキスト集合を扱う場合には INITIAL_N_SEGMENTSをデフォルトの512から上げる必要があります。 まあ、更新が多いシステムの場合にも、 INITIAL_N_SEGMENTSを増やすと更新性能が上がる場合があると推測できます。 > 形態素解析では、8G > N-gramでは、5.3G > のへんが境界線という事でしょうか。 大まかな目安にはなると思います。 Akihiko Shinohara さんは書きました: > こんにちは、篠原です。 > 返事がとても遅くなってしまいました。すいません。 > >> 個人的な興味としては、 >> 検索対象の >> ・件数 >> ・データ量 >> ・テキストの種別 >> の３点が気になります。 > > まず、この件ですが、2つの環境として > (1) 新規登録環境 > (a). 件数　約300万件 > (b). データ量　約20GB > (c). テキストの種類　MEDIUMTEXT ,SJISコード > (2) 0.8系で使用していたテーブルからのインデックス再作成 > (a). 件数　約300万件 > (b). データ量　約13GB > (c). テキストの種類　MEDIUMTEXT ,SJISコード > 但し、変換元のテーブルの型は、TEXTなので、最大でもTEXTのサイズを > 超えることはありません。 > という環境です。 > > 今まで、INITIAL_N_SEGMENTSは、使用メモリサイズとスピードに関連する > パラメータと思っていて、あまり気にしていませんでしたが、 > 実は、以下の説明にもあるように、 > http://lists.sourceforge.jp/mailman/archives/senna-dev/2006-February/000197.html > 初期値の512の設定だと、最大8G程度のインデックスしか作成できないという制限な > のです > ね、言い換えれば、形態素解析では、ほぼテーブルサイズのインデックスとなり > N-gramのインデックスでは、テーブルサイズの1.5倍程度のインデックスとなるので > > 形態素解析では、8G > N-gramでは、5.3G > > のへんが境界線という事でしょうか。 > > という事で最初に示した環境は無謀もいいところですね。（＾＾； > INITIAL_N_SEGMENTSを調整することで無事にインデックスが > 作成できました。 > > ありがとうございました。 > ---- > sino --- Tasuku SUENAGA From utada ＠ themis.ocn.ne.jp Fri Feb 22 12:57:10 2008 From: utada ＠ themis.ocn.ne.jp (Katsuya Utada) Date: Fri, 22 Feb 2008 12:57:10 +0900 Subject: [Senna-dev 785] =?iso-2022-jp?b?GyRCJSQlcyVHJUMlLyU5PnBKczxoRkA7fiRLGyhCc3lzY2Fs?= =?iso-2022-jp?b?bCBlcnJvcg==?= Message-ID: <20080222123652.41C7.7AB1578@themis.ocn.ne.jp> お世話になっております うただです tritonn-1.0.9-mysql-5.0.51a-linux-x86_64バイナリを使用しているのですが show senna statusでインデックス情報を取得時に senna.logに下記のようなsyscall errorが多量に出力されます。 match検索は特に問題なくできているようですが、 インデックスファイルに問題あるでしょうか・・? |create table test ( | id int not null auto_increment, | text varchar(2000), | primary key(id) |) engine=myisam default charset=ujis; | |alter table test add fulltext index using ngram (text); | |show senna status\G | |==> senna.log <== |2008/02/22 12:39:12.719136|e|1| syscall error '/data/test.001.SEN.001' (No such file or directory) |2008/02/22 12:39:12.719157|e|1| syscall error '/data/test.001.SEN.002' (No such file or directory) |2008/02/22 12:39:12.719175|e|1| syscall error '/data/test.001.SEN.003' (No such file or directory) |2008/02/22 12:39:12.719194|e|1| syscall error '/data/test.001.SEN.004' (No such file or directory) |2008/02/22 12:39:12.719216|e|1| syscall error '/data/test.001.SEN.l.001' (No such file or directory) |… From a ＠ razil.jp Sat Feb 23 21:30:42 2008 From: a ＠ razil.jp (Tasuku SUENAGA) Date: Sat, 23 Feb 2008 21:30:42 +0900 Subject: [Senna-dev 786] Re: =?iso-2022-jp?b?GyRCJSQlcyVHJUMlLyU5PnBKczxoRkA7fiRLGyhCc3lz?= =?iso-2022-jp?b?Y2FsbCBlcnJvcg==?= In-Reply-To: <20080222123652.41C7.7AB1578@themis.ocn.ne.jp> References: <20080222123652.41C7.7AB1578@themis.ocn.ne.jp> Message-ID: <47C011F2.9010206@razil.jp> 末永です。こんばんは！！！ Sennaのバグです。 次回リリースされるバージョンで修正されます。 インデックスファイルに問題はないですので、 ご安心ください！！ Katsuya Utada さんは書きました: > お世話になっております > うただです > > tritonn-1.0.9-mysql-5.0.51a-linux-x86_64バイナリを使用しているのですが > show senna statusでインデックス情報を取得時に > senna.logに下記のようなsyscall errorが多量に出力されます。 > match検索は特に問題なくできているようですが、 > インデックスファイルに問題あるでしょうか・・? > > |create table test ( > | id int not null auto_increment, > | text varchar(2000), > | primary key(id) > |) engine=myisam default charset=ujis; > | > |alter table test add fulltext index using ngram (text); > | > |show senna status\G > | > |==> senna.log <== > |2008/02/22 12:39:12.719136|e|1| syscall error '/data/test.001.SEN.001' (No such file or directory) > |2008/02/22 12:39:12.719157|e|1| syscall error '/data/test.001.SEN.002' (No such file or directory) > |2008/02/22 12:39:12.719175|e|1| syscall error '/data/test.001.SEN.003' (No such file or directory) > |2008/02/22 12:39:12.719194|e|1| syscall error '/data/test.001.SEN.004' (No such file or directory) > |2008/02/22 12:39:12.719216|e|1| syscall error '/data/test.001.SEN.l.001' (No such file or directory) > |… --- tasuku From utada ＠ themis.ocn.ne.jp Sat Feb 23 21:42:25 2008 From: utada ＠ themis.ocn.ne.jp (Katsuya Utada) Date: Sat, 23 Feb 2008 21:42:25 +0900 Subject: [Senna-dev 787] Re: =?iso-2022-jp?b?GyRCJSQlcyVHJUMlLyU5PnBKczxoRkA7fiRLGyhCc3lz?= =?iso-2022-jp?b?Y2FsbCBlcnJvcg==?= In-Reply-To: <47C011F2.9010206@razil.jp> References: <20080222123652.41C7.7AB1578@themis.ocn.ne.jp> <47C011F2.9010206@razil.jp> Message-ID: <20080223213712.73F4.7AB1578@themis.ocn.ne.jp> お世話になっております うただと申します 問題ないとの事で安心いたしました。ありがとうございました On Sat, 23 Feb 2008 21:30:42 +0900 Tasuku SUENAGA wrote: |末永です。こんばんは！！！ | |Sennaのバグです。 |次回リリースされるバージョンで修正されます。 |インデックスファイルに問題はないですので、 |ご安心ください！！ | -- Katsuya Utada From a.yamanoi ＠ gmail.com Mon Feb 25 23:02:19 2008 From: a.yamanoi ＠ gmail.com (Akihiro YAMANOI) Date: Mon, 25 Feb 2008 23:02:19 +0900 Subject: [Senna-dev 788] =?iso-2022-jp?b?GyRCJT0hPCVIJDckPyVsJTMhPCVJJEsbKEJyZXdpbmQ=?= =?iso-2022-jp?b?GyRCJHI8QjlUJDkkayRIGyhCc2VuX2ludGVybmFsX2Vycm9y?= =?iso-2022-jp?b?GyRCJCxIL0A4GyhC?= Message-ID: <4d21cd500802250602u2c6060bbu36732ab6383a571a@mail.gmail.com> はじめまして。山野井と申します。 PHPからSennaを使いたくなり、右も左もわからぬままエクステンションを書いています。 メーリングリストの存在を知りまして、本日参加させて頂きました。ありがとうございます。 sen_records_sort()でソートしたレコードをsen_records_rewind()の引数に与えると sen_internal_errorが発生してしまい、現在、無理矢理な方法でこれを回避しています。 「ソートしたレコードはrewind不可」という制限はありますでしょうか？ [以下のようなコードで発生します] sen_rc result; sen_records *r = sen_records_open(sen_rec_document, sen_rec_none, 0); func_query(r); /* 何らかの検索クエリを実行し、rに格納する */ result = sen_records_sort(r, 1000, NULL); while (sen_records_next(r, NULL, 0, NULL)) { /* 各レコードに対する処理 */ } result = sen_records_rewind(r); /* ここでsen_internal_errorが発生 */ while (sen_records_next(r, NULL, 0, NULL)) { /* 各レコードに対する別の処理 */ } [無理矢理な回避方法] sen_rc result; sen_records *r = sen_records_open(sen_rec_document, sen_rec_none, 0); func_query(r); result = sen_records_sort(r, 1000, NULL); while (sen_records_next(r, NULL, 0, NULL)) { } r->curr_rec = NULL; /* rの中身を直接書き換えて対応 */ while (sen_records_next(r, NULL, 0, NULL)) { } ※senna/lib/index.c:1411行目あたりのsen_records_rewind()を参考にして 　「r->curr_rec = NULL」を書いたところ、意図した結果を得られるように 　なりました。 [発生する環境] OS: CentOS4.4 Senna: 1.1.1 gcc: 3.4.6 APIの解説ページ(http://qwik.jp/senna/APIJ.html)を見ると、ソート後に rewind出来ないとは明記されていないようです。そのため、エラーが発生するのは sen_records_rewind()の仕様なのかどうか判断できず、投稿させて頂きました。 ソートしたレコードのカーソルを先頭に戻す正しいAPIの使い方がありましたら ご教授いただければ嬉しいです。 どうぞよろしくお願いいたします。 From morita ＠ razil.jp Wed Feb 27 13:50:46 2008 From: morita ＠ razil.jp (morita ＠ razil.jp) Date: Wed, 27 Feb 2008 13:50:46 +0900 Subject: [Senna-dev 789] Re: =?iso-2022-jp?b?GyRCJT0hPCVIJDckPyVsJTMhPCVJJEsbKEJyZXdpbmQ=?= =?iso-2022-jp?b?GyRCJHI8QjlUJDkkayRIGyhCc2VuX2ludGVybmFsX2Vycm9y?= =?iso-2022-jp?b?GyRCJCxIL0A4GyhC?= In-Reply-To: <4d21cd500802250602u2c6060bbu36732ab6383a571a@mail.gmail.com> References: <4d21cd500802250602u2c6060bbu36732ab6383a571a@mail.gmail.com> Message-ID: <20080227045046.GA3617@epepe.com> はじめまして。森と申します。 ご指摘ありがとうございます!! sen_records_rewindの返すエラーコードが間違っていました。 内部でやっている処理は山野井さんの回避方法と全く同じなのですが、 sort済みのrecordsに関しては、sen_successを返すべきところで sen_internal_errorを返すようになっていました。 次のバージョンでは修正いたします。 >>> Akihiro YAMANOI さんは書きました： > はじめまして。山野井と申します。 > PHPからSennaを使いたくなり、右も左もわからぬままエクステンションを書いています。 > メーリングリストの存在を知りまして、本日参加させて頂きました。ありがとうございます。 > > sen_records_sort()でソートしたレコードをsen_records_rewind()の引数に与えると > sen_internal_errorが発生してしまい、現在、無理矢理な方法でこれを回避しています。 > 「ソートしたレコードはrewind不可」という制限はありますでしょうか？ > > [以下のようなコードで発生します] > sen_rc result; > sen_records *r = sen_records_open(sen_rec_document, sen_rec_none, 0); > func_query(r); /* 何らかの検索クエリを実行し、rに格納する */ > result = sen_records_sort(r, 1000, NULL); > while (sen_records_next(r, NULL, 0, NULL)) { /* 各レコードに対する処理 */ } > result = sen_records_rewind(r); /* ここでsen_internal_errorが発生 */ > while (sen_records_next(r, NULL, 0, NULL)) { /* 各レコードに対する別の処理 */ } > > [無理矢理な回避方法] > sen_rc result; > sen_records *r = sen_records_open(sen_rec_document, sen_rec_none, 0); > func_query(r); > result = sen_records_sort(r, 1000, NULL); > while (sen_records_next(r, NULL, 0, NULL)) { } > r->curr_rec = NULL; /* rの中身を直接書き換えて対応 */ > while (sen_records_next(r, NULL, 0, NULL)) { } > > ※senna/lib/index.c:1411行目あたりのsen_records_rewind()を参考にして > 　「r->curr_rec = NULL」を書いたところ、意図した結果を得られるように > 　なりました。 > > [発生する環境] > OS: CentOS4.4 > Senna: 1.1.1 > gcc: 3.4.6 > > APIの解説ページ(http://qwik.jp/senna/APIJ.html)を見ると、ソート後に > rewind出来ないとは明記されていないようです。そのため、エラーが発生するのは > sen_records_rewind()の仕様なのかどうか判断できず、投稿させて頂きました。 > > ソートしたレコードのカーソルを先頭に戻す正しいAPIの使い方がありましたら > ご教授いただければ嬉しいです。 > > どうぞよろしくお願いいたします。 > > _______________________________________________ > Senna-dev mailing list > Senna-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/senna-dev > バグ報告方法：http://qwik.jp/senna/bug_report.html > -- morita From a.yamanoi ＠ gmail.com Thu Feb 28 09:19:41 2008 From: a.yamanoi ＠ gmail.com (Akihiro YAMANOI) Date: Thu, 28 Feb 2008 09:19:41 +0900 Subject: [Senna-dev 790] Re: =?iso-2022-jp?b?GyRCJT0hPCVIJDckPyVsJTMhPCVJJEsbKEJyZXdpbmQ=?= =?iso-2022-jp?b?GyRCJHI8QjlUJDkkayRIGyhCc2VuX2ludGVybmFsX2Vycm9y?= =?iso-2022-jp?b?GyRCJCxIL0A4GyhC?= In-Reply-To: <20080227045046.GA3617@epepe.com> References: <4d21cd500802250602u2c6060bbu36732ab6383a571a@mail.gmail.com> <20080227045046.GA3617@epepe.com> Message-ID: <4d21cd500802271619w183e62f4r5173ed56d2b5c5b1@mail.gmail.com> 森さま、はじめまして。山野井です。 > sort済みのrecordsに関しては、sen_successを返すべきところで > sen_internal_errorを返すようになっていました。 なるほど！承知いたしました。バージョンアップで対応して頂けるとのことで、 それまでは現在の回避方法を使いたいと思います。 ご返信どうもありがとうございました。 > はじめまして。森と申します。 > > ご指摘ありがとうございます!! > > sen_records_rewindの返すエラーコードが間違っていました。 > > 内部でやっている処理は山野井さんの回避方法と全く同じなのですが、 > sort済みのrecordsに関しては、sen_successを返すべきところで > sen_internal_errorを返すようになっていました。 > > 次のバージョンでは修正いたします。 > > >>> Akihiro YAMANOI さんは書きました： > > はじめまして。山野井と申します。 > > PHPからSennaを使いたくなり、右も左もわからぬままエクステンションを書いています。 > > メーリングリストの存在を知りまして、本日参加させて頂きました。ありがとうございます。 > > > > sen_records_sort()でソートしたレコードをsen_records_rewind()の引数に与えると > > sen_internal_errorが発生してしまい、現在、無理矢理な方法でこれを回避しています。 > > 「ソートしたレコードはrewind不可」という制限はありますでしょうか？ > > > > [以下のようなコードで発生します] > > sen_rc result; > > sen_records *r = sen_records_open(sen_rec_document, sen_rec_none, 0); > > func_query(r); /* 何らかの検索クエリを実行し、rに格納する */ > > result = sen_records_sort(r, 1000, NULL); > > while (sen_records_next(r, NULL, 0, NULL)) { /* 各レコードに対する処理 */ } > > result = sen_records_rewind(r); /* ここでsen_internal_errorが発生 */ > > while (sen_records_next(r, NULL, 0, NULL)) { /* 各レコードに対する別の処理 */ } > > > > [無理矢理な回避方法] > > sen_rc result; > > sen_records *r = sen_records_open(sen_rec_document, sen_rec_none, 0); > > func_query(r); > > result = sen_records_sort(r, 1000, NULL); > > while (sen_records_next(r, NULL, 0, NULL)) { } > > r->curr_rec = NULL; /* rの中身を直接書き換えて対応 */ > > while (sen_records_next(r, NULL, 0, NULL)) { } > > > > ※senna/lib/index.c:1411行目あたりのsen_records_rewind()を参考にして > > 「r->curr_rec = NULL」を書いたところ、意図した結果を得られるように > > なりました。 > > > > [発生する環境] > > OS: CentOS4.4 > > Senna: 1.1.1 > > gcc: 3.4.6 > > > > APIの解説ページ(http://qwik.jp/senna/APIJ.html)を見ると、ソート後に > > rewind出来ないとは明記されていないようです。そのため、エラーが発生するのは > > sen_records_rewind()の仕様なのかどうか判断できず、投稿させて頂きました。 > > > > ソートしたレコードのカーソルを先頭に戻す正しいAPIの使い方がありましたら > > ご教授いただければ嬉しいです。 > > > > どうぞよろしくお願いいたします。 > > > > _______________________________________________ > > Senna-dev mailing list > > Senna-dev ＠ lists.sourceforge.jp > > http://lists.sourceforge.jp/mailman/listinfo/senna-dev > > バグ報告方法：http://qwik.jp/senna/bug_report.html > > > -- > morita > > _______________________________________________ > Senna-dev mailing list > Senna-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/senna-dev > バグ報告方法：http://qwik.jp/senna/bug_report.html From morita ＠ razil.jp Fri Feb 29 11:29:40 2008 From: morita ＠ razil.jp (morita ＠ razil.jp) Date: Fri, 29 Feb 2008 11:29:40 +0900 Subject: [Senna-dev 791] senna store Message-ID: <20080229022940.GA19423@epepe.com> こんにちは。森です。 svn最新リポジトリのSennaStoreをお使いの方にお知らせです。 (TritonnやLudia等のDBMSバインディングの動作には全く影響のない話ですので、 sennaqlをお使いでない方は読み飛ばしてください。) リビジョン r738 で SennaStoreのファイルの形式を変更しました。 従来のSennaStoreで作成したデータベースとは互換性がないので注意が必要です。 また、近々リリース予定のSenna 1.1.2では後方互換性を持たせるかどうか思案中です。 強い要望があるようであれば、救済策を検討したいと思います。 なお、新しい形式のSennaStoreでは以下の点が良くなりました。 - メモリ消費量が小さくなった。 - ファイルサイズが小さくなった。 - 追加処理が連続する時にシーク回数が少なくなり、高速になった。 - text,longtext型のレコード長上限が16MB→4GBと、大きくなった。 以上です。ご意見ご要望等もしあれば、よろしくお願いします‥。 -- morita From a.yamanoi ＠ gmail.com Fri Feb 29 13:18:24 2008 From: a.yamanoi ＠ gmail.com (Akihiro YAMANOI) Date: Fri, 29 Feb 2008 13:18:24 +0900 Subject: [Senna-dev 792] =?iso-2022-jp?b?c2VuX3NuaXBfb3BlbigpGyRCJEcbKEJTRU5fU05JUF9DT1BZ?= =?iso-2022-jp?b?X1RBRxskQiVVJWklMCRyO1hEaiQ3JEYkYhsoQmRlZmF1bHQ=?= =?iso-2022-jp?b?GyRCJT8lMCQsSiNAPSQ1JGwkSiQkGyhC?= Message-ID: <4d21cd500802282018l78d4ac35l45a5a4c3fb1a1db3@mail.gmail.com> 山野井です。 sen_snip_open()関数のバグ報告です。Senna-1.1.1で追加された SEN_SNIP_COPY_TAGフラグを指定した際の挙動に関してです。 [発生した環境] ・CPU: VIA C3 ・メモリ容量: 512MB ・ハードディスク容量: 160GB(空き100GB) ・OS: CentOS4.4 ・uname -aの結果: Linux localhost.localdomain 2.6.9-42.0.10.EL #1 Tue Feb 27 09:24:42 EST 2007 i686 i686 i386 GNU/Linux ・Senna: 1.1.1 ・gcc: 3.4.6 [起こっている問題] sen_snip_open()関数は、flags引数にSEN_SNIP_COPY_TAGフラグを指定しても defaultopentag及びdefaultclosetagを複製せずに保持します。 (lib/snip.c:388行目辺り) しかし、sen_snip_close()関数は、SEN_SNIP_COPY_TAGフラグが立っている場合 保持しているdefaultopentag及びdefaultclosetagに対しSEN_FREE()を呼びます。 (lib/snip.c:432行目辺り) 上記が原因で、senna外部で確保した変数が意図せず解放されてしまいます。 [再現方法1] char *openTag = calloc(9, sizeof(char)); memcpy(openTag, "", 8); openTag[8] = '\0'; sen_snip *snip = sen_snip_open( sen_enc_utf8, SEN_SNIP_COPY_TAG, 100, 1, openTag, strlen(openTag), NULL, 0, NULL ); sen_snip_close(snip); free(openTag); ---- (実行結果) セグメンテーション違反です。 ---- と表示されました。呼び出し側で確保した文字列変数openTagが sen_snip_close()内部で解放されてしまい、呼び出し側のfree()は エラーになります。 [再現方法2] char *openTag = calloc(9, sizeof(char)); memcpy(openTag, "", 8); openTag[8] = '\0'; sen_snip *snip = sen_snip_open( sen_enc_utf8, SEN_SNIP_COPY_TAG, 100, 1, openTag, strlen(openTag), openTag, strlen(openTag), /* 同じ変数を与える */ NULL ); sen_snip_close(snip); ---- (実行結果) *** glibc detected *** double free or corruption (fasttop): 0x0a5b8c48 *** アボートしました ---- と表示されました。sen_snip_close()内部でopenTag変数が2重に 解放されてエラーが発生します。 sen_snip_close()にデフォルトタグ文字列の解放処理が記述されていましたので、 sen_snip_open()内で文字列を複製していないのは不具合なのではと思い、ご報告 させて頂きました。 バグではなく仕様上あえてこうなっていましたら、上記報告は私の勘違いです！ ご確認頂けると嬉しいです。 よろしくお願いいたします。