Kouhei Sutou
kou****@clear*****
2016年 1月 28日 (木) 16:09:45 JST
須藤です。 In <20160****@orega*****> "[groonga-dev,03874] Re: PGRNファイルが開けない？" on Wed, 27 Jan 2016 08:40:14 +0900, 高見 直輝 <takam****@orega*****> wrote: >> ところどころに >> >> > 2016-01-19 11:33:42.134000|e| syscall error 'base/16384/pgrn.000012F' (Permission denied) >> >> というログがでているのですが、別にデータベースを開いているプ >> ロセスがいたりしますか？ > > はい。InsertとSelectはそれぞれ別のプロセスから実行しています。 なるほど。それらのプロセスがファイルを開いているので削除でき ないというエラーになるんですね。 > 現在、DEBUGを設定した状態にしています。 > 3〜5の期間のログを添付します。 > 5ではエラーになりませんでした。 > ※%％を使って検索したが、pgroonga.logになにも出力されなかった > なお、9:50の段階でPostgreSQLを停止しています。 ありがとうございます。 この部分ではおかしなところはありませんでした。 > その後、9:53に再起動をした後の経過を端的に。 > ・再起動直後（09:54:57まで）はInsertを実行してもエラーにならない > ・09:55:07に、Insert文で以下のエラーが発生した。 > 42602: pgroonga: object isn't found: <Sources37356> > 以後、Insert文＆Select文いずれもエラーとなる。 > > pgroonga.logを確認したところ、09:55:02から『DDL:obj_remove ~』というログ > が大量に出力されていました。 > 『Sources37356』についてのログも09:55:03に出力されていました。 > これだけだとobj_removeが行われているのが原因のように思えるのですが、どう > なのでしょうか？ obj_remove()をするのはVACUUMのときだけなので、おそらく、 09:55くらいにAUTO VACUUMが走ったのだと思います。 PGroongaはVACUUMのときに無効なテーブルを削除します。おかしい のは有効なテーブルも無効だと判断されているということです。 エラーメッセージに出ているSources37356はREINDEXのときに作ら れている（提供してもらったログにでている）ので有効なテーブル のはずです。 Sourcesのあとの「37356」がインデックスのID（PostgreSQLの中で はOIDと呼ばれているもの）なんですが、PGroongaはVACUUMのとき に「37356」が有効かどうかをチェックして無効ならその SourcesXXXと関連する（Groongaの）テーブル・カラムを削除して います。 有効化どうかのチェック方法は、たぶん、SQLでいうと SELECT * FROM pg_class WHERE oid = 37356; に相当します。問題のデータベースで↑の結果がどうなるか教えて もらえませんか？ レコードが存在しないなら想定外なんですが、たぶん、存在するん ですよ。とすると、なんで無効扱いになっているかなんですけど、 なんでだろう。デバッガーで追えればすぐにわかりそうですが。。。 -- 須藤 功平 <kou****@clear*****> 株式会社クリアコード <http://www.clear-code.com/> Groongaベースの全文検索システムを総合サポート: http://groonga.org/ja/support/ パッチ採用 - プログラミングが楽しい人向けの採用プロセス: http://www.clear-code.com/recruitment/ リーダブルコードワークショップ: http://www.clear-code.com/services/code-reader/readable-code-workshop.html
