高見 直輝
takam****@orega*****
2016年 1月 29日 (金) 10:40:29 JST
高見です。 > >> ところどころに > >> > >> > 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; > > に相当します。問題のデータベースで↑の結果がどうなるか教えて > もらえませんか？ > > > レコードが存在しないなら想定外なんですが、たぶん、存在するん > ですよ。とすると、なんで無効扱いになっているかなんですけど、 > なんでだろう。デバッガーで追えればすぐにわかりそうですが。。。 残念ながら、レコードが存在しませんでした。 1.0.0にデバッグログ出力を追加したモジュールなどを作成してもらえれば、差 し替えて調査することは可能です。 よろしければ御検討下さい。 なお、autovacuum = off にした状態でインデックスの再作成を前回と同じ手順 で実行したところ、再起動後30分経過してもエラーは発生していません。 VACUUMがトリガであることは間違いなさそうです。 ----------------------------- 高見 直輝 <takam****@orega*****> 株式会社オレガ TEL:03-3267-0150 FAX:03-3267-0180
