高見 直輝
takam****@orega*****
2016年 2月 1日 (月) 19:21:24 JST
高見です。 > >> Sourcesのあとの「37356」がインデックスのID（PostgreSQLの中で > >> はOIDと呼ばれているもの）なんですが、PGroongaはVACUUMのとき > >> に「37356」が有効かどうかをチェックして無効ならその > >> SourcesXXXと関連する（Groongaの）テーブル・カラムを削除して > >> います。 > >> > >> 有効かどうかのチェック方法は、たぶん、SQLでいうと > >> > >> SELECT * FROM pg_class WHERE oid = 37356; > >> > >> に相当します。問題のデータベースで↑の結果がどうなるか教えて > >> もらえませんか？ > >> > >> > >> レコードが存在しないなら想定外なんですが、たぶん、存在するん > >> ですよ。とすると、なんで無効扱いになっているかなんですけど、 > >> なんでだろう。デバッガーで追えればすぐにわかりそうですが。。。 > > > > 残念ながら、レコードが存在しませんでした。 > > え、あ、そうなんですか。 > > > 1.0.0にデバッグログ出力を追加したモジュールなどを作成してもらえれば、差 > > し替えて調査することは可能です。 > > よろしければ御検討下さい。 > > これはPGroongaレベルでどうこうの話ではなく、PostgreSQLレベル > でどうこうの話なんです。（PostgreSQLがインデックスをどうやっ > て管理しているか。） > > インデックスは存在しているがpg_classには該当インデックスの > OIDが存在しない、という状況がどういうときに発生するかがわか > ればいいんですが、どのようなSQLを実行しているかがわからない > とこちらで再現できないので調べられないんです。 > > なにか操作するたびにpg_classをチェックして、どんな操作をすれ > ば「インデックスは存在しているがpg_classには該当インデックス > のOIDが存在しない」という状況になるか絞り込んでもらうことは > できますか？ autovacuum = offにした状態で確認したところ、ANALYZEがトリガであることが 判明しました。 ※InsertとSelectでは発生しないことを確認。 以下の処理を行い、再現することを確認しました。 １．pgrn*ファイルの削除 ２．REINDEX実行 ３．ANALYZE実行 この後、数分以内にobj_removeが実行され始めます。 > たぶん、REINDEXしたときはpg_classに存在していると思うんです > よ。PGroongaにそのOIDのインデックスを作ってくれ、という指示 > が飛んでいるので。なので、それ以降のそうさのどこかでpg_class > から消えるんだと思うんです。 オブジェクトが残っている状態でpg_classからデータが消えるという状況がよく 分かっていないのですが、上記手順における、REINDEXの実行後とANALYZEの実行 後（obj_removeの完了後）でpg_classの内容を比較しました。 その結果、PGroongaのインデックスのレコード数並びに内容に変化はありません でした。 pg_classの内容取得に使用したSQLは以下の通り。 select oid, * from pg_class; 確認内容に不備がある場合はご指摘下さい。 なお、ANALYZEの実行後、REINDEX実行時に作成されたpgrn*ファイルが、pgrn、 pgrn.0000000、pgrn.001、pgrn.confの4つを除いて削除されました。 現時点で判明したのは以上です。 ----------------------------- 高見 直輝 <takam****@orega*****> 株式会社オレガ TEL:03-3267-0150 FAX:03-3267-0180
