Kouhei Sutou
kou****@clear*****
2015年 7月 16日 (木) 23:33:34 JST
須藤です。 In <20150****@orega*****> "[groonga-dev,03365] Re: PGROONGAで障害発生" on Thu, 16 Jul 2015 09:50:00 +0900, 高見 直輝 <takam****@orega*****> wrote: >> 1. 接続Aでテーブル作成 >> * 接続Aはこのテーブルのファイルを開く > 上記１で、テーブルのファイルが閉じるタイミング（条件）はどうなっているのでしょうか？ > これが分かれば、プログラムで対応することが可能になるかもしれません。 クライアントとの接続が切れるタイミングです。 >> 2. 接続Bで↑が作成したテーブルを削除 >> * 接続Aが開いたままのファイルを削除しようとしてエラー > また、上記２でPostgreSQLのDROP文を失敗させることは可能でしょうか？ それができないんです。 ファイルを削除するのはVACUUMの処理の中であって、DROP TABLEの 処理ではないからです。DROP TABLEはあくまでも「削除フラグ」み たいなのをつけるだけで、実際に削除はしないのです。 高見さんの環境でどのタイミングでVACUUMが実行されているのかは わからないのですが（クエリーログをとるとわかるのかしら。。。）、 VACUUM文の最中にエラーが発生しているはずです。 > 今回混乱したのは、DROP文が正常終了していることに原因があるように思えます。 > テーブルが削除されると当然ながらVACUUMの対象外となるわけで、不正な状態を固定している要因 > となっている気がします。 むしろ逆で、テーブルが削除されるとそのテーブルがVACUUM対象と なるようになっています。（テーブルが削除されていないときは 「テーブル」そのものではなく、テーブル内の「レコード」が対象 となっています。） PostgreSQL本体もそうしているかは調べていないのですが、少なく ともPGroongaはそのようにしています。 これがスジが悪いのかしら。でも、このときくらいしかタイミング がなさそうな気がするんだよなぁ。 > あとは、暫定対応として「Permission denied」を検知したらファイル名を変更して再実行することで > テーブルの作成が失敗しないようにするといったところでしょうか・・・。 実は、1つでもテーブルを開いている接続（プロセス）が残ってい るとファイル名の変更もできないのです。。。 不要なテーブルの削除をだれも開いていないことを確認できた状態 でだけ実行できればいいんですけど。。。FILE_SHARE_DELETEでう まく動くかと思ったんですが、相変わらずエラーになるんですよ ねぇ。
