高見 直輝
takam****@orega*****
2016年 2月 3日 (水) 14:46:56 JST
高見です。 > > 正常に稼動している環境で上記の手順で確認したところ、以下の挙動になりました。 > > ・REINDEXによってpg_classのOIDに変化は見られなかった > > ・「SourcesXXX」のXXXは、当初pg_classのOIDであったが、REINDEX実行後は > > pg_classのrelfilenodeの値がセットされる > > > > この挙動自体は正しいのでしょうか？ > > これが間違っている場合、DB構築手順やpg_confの内容に原因がある可能性はあ > > りますでしょうか？ > > うぉー！そうでした。「SourcesXXX」のXXXはOIDではなく > relfilenodeを使っているのでした。 CREATE INDEXの時点ではOIDを使っているように見えるのですが、どうなのでしょ うか？ てっきり、XXXの値がrelfilenodeの値に切り替わったのが原因ではないかと思っ たのですが・・・。 > なので、VACUUM/ANALYZEのときに > > SELECT * FROM pg_class WHERE oid = 37356; > > 相当でチェックしているのが間違いで > > SELECT * FROM pg_class WHERE relfilenode = 37356; > > 相当でチェックしないといけないのでした。 > そうしていなかったので「REINDEX」後に生きているインデックス > が消えてしまっていました。 CREATE INDEX時にOIDがセットされている場合、REINDEXをしていない（relfilenode の値に切り替わっていない）インデックスが消えてしまいませんか？ 次回アップデート時に既存インデックスの再作成が必要かどうか教えて下さい。 > つまり、電源断をしなくても以下で再現します。 > > CREATE INDEX ...; > REINDEX INDEX ...; > ANALYZE; > SELECT ...; 当方の環境ではREINDEXの前にpgrnファイルを削除しないと再現しないようなの ですが、理由は分かりますでしょうか？ ファイル削除をやっていない環境であればアップデート時にインデックス再作成 が不要になる、となってくれると色々と助かるのですが・・・。 > ということでmasterで直しておきました。 > > 情報提供ありがとうございました。 > 助かりました。 こちらこそ、対応ありがとうございます。 ----------------------------- 高見 直輝 <takam****@orega*****> 株式会社オレガ TEL:03-3267-0150 FAX:03-3267-0180
