高見 直輝
takam****@orega*****
2015年 7月 17日 (金) 09:48:38 JST
高見です。 > >> 1. 接続Aでテーブル作成 > >> * 接続Aはこのテーブルのファイルを開く > > > 上記１で、テーブルのファイルが閉じるタイミング（条件）はどうなっているのでしょうか？ > > これが分かれば、プログラムで対応することが可能になるかもしれません。 > > クライアントとの接続が切れるタイミングです。 つまり、DROP文をPSQLコマンドなどで実行することで対応出来る可能性があるわけですね。 > >> 2. 接続Bで↑が作成したテーブルを削除 > >> * 接続Aが開いたままのファイルを削除しようとしてエラー > > > また、上記２でPostgreSQLのDROP文を失敗させることは可能でしょうか？ > > それができないんです。 > ファイルを削除するのはVACUUMの処理の中であって、DROP TABLEの > 処理ではないからです。DROP TABLEはあくまでも「削除フラグ」み > たいなのをつけるだけで、実際に削除はしないのです。 > > 高見さんの環境でどのタイミングでVACUUMが実行されているのかは > わからないのですが（クエリーログをとるとわかるのかしら。。。）、 > VACUUM文の最中にエラーが発生しているはずです。 ログのタイムスタンプからは、DROP文を実行してから数十ミリ秒後にエラーが発生しているように見えました。 PostgreSQL内部ではDROP⇒VACUUMがバッチで実行されているのかもしれません。 > > 今回混乱したのは、DROP文が正常終了していることに原因があるように思えます。 > > テーブルが削除されると当然ながらVACUUMの対象外となるわけで、不正な状態を固定している要因 > > となっている気がします。 > > むしろ逆で、テーブルが削除されるとそのテーブルがVACUUM対象と > なるようになっています。（テーブルが削除されていないときは > 「テーブル」そのものではなく、テーブル内の「レコード」が対象 > となっています。） > > PostgreSQL本体もそうしているかは調べていないのですが、少なく > ともPGroongaはそのようにしています。 > > これがスジが悪いのかしら。でも、このときくらいしかタイミング > がなさそうな気がするんだよなぁ。 私もPostgreSQLの内部処理に詳しいわけではないので想像の話になりますが、“削除に失敗しても無視する” 仕様なのかも知れません。 削除に失敗しても、ファイルを空（サイズ0）にしておけば削除が後回しになっても運用上の問題（ストレージ 容量の枯渇）になることはないでしょうし。 > > あとは、暫定対応として「Permission denied」を検知したらファイル名を変更して再実行することで > > テーブルの作成が失敗しないようにするといったところでしょうか・・・。 > > 実は、1つでもテーブルを開いている接続（プロセス）が残ってい > るとファイル名の変更もできないのです。。。 > > 不要なテーブルの削除をだれも開いていないことを確認できた状態 > でだけ実行できればいいんですけど。。。FILE_SHARE_DELETEでう > まく動くかと思ったんですが、相変わらずエラーになるんですよ > ねぇ。 > これに関しては発想が逆で、『削除に失敗している状況でも、作成を成功させる』のが目的です。 先日のログで、テーブル作成時に作るファイルの名前を、既存のファイル（pgrn.000042F）ではなく、別の名 前（例：pgrn.00004AF）で作成してやれば、差し当たりの問題は解決すると思うのですが、どうでしょうか？ ----------------------------- 高見 直輝 <takam****@orega*****> 株式会社オレガ TEL:03-3267-0150 FAX:03-3267-0180
