[groonga-dev,03365] Re: PGROONGAで障害発生

Back to archive index

高見 直輝 takam****@orega*****
2015年 7月 16日 (木) 09:50:00 JST


高見です。

お役に立てたようで、何よりです。

> PostgreSQLは接続毎にプロセスを起動するので
> 
>   1. 接続Aでテーブル作成
>      * 接続Aはこのテーブルのファイルを開く
>   2. 接続Bで↑が作成したテーブルを削除
>      * 接続Aが開いたままのファイルを削除しようとしてエラー
> 
> という状態になりえます。
> 
> で、テーブルを削除する機会はVACUUMされたタイミングになります。
> VACUUMは手動で実行することもできますが、自動でも動きます。
> 
>   https://www.postgresql.jp/document/9.4/html/routine-vacuuming.html#AUTOVACUUM
> 
> おそらく、高見さんの環境で発生しているのはちょうど自動で実行
> されているからでしょう。レコードを追加すると発生しなくなる、
> というのもその影響で自動でVACUUMが実行されなくなるからです。
> 
> 
> どうやって直すとよいのかしら。。。
> どのプロセスもファイルを開いていないことを保証した状態で削除
> しないといけないんだけど。。。バックグラウンドワーカープロセ
> スを作ってそっちで削除するようにすればいいのかしら。
> 大げさだなぁ。

上記1で、テーブルのファイルが閉じるタイミング(条件)はどうなっているのでしょうか?
これが分かれば、プログラムで対応することが可能になるかもしれません。
また、上記2でPostgreSQLのDROP文を失敗させることは可能でしょうか?
今回混乱したのは、DROP文が正常終了していることに原因があるように思えます。
テーブルが削除されると当然ながらVACUUMの対象外となるわけで、不正な状態を固定している要因
となっている気がします。
あとは、暫定対応として「Permission denied」を検知したらファイル名を変更して再実行することで
テーブルの作成が失敗しないようにするといったところでしょうか・・・。

----------------------------- 
高見 直輝 <takam****@orega*****>
株式会社オレガ
TEL:03-3267-0150
FAX:03-3267-0180




groonga-dev メーリングリストの案内
Back to archive index