[pgsql-jp: 35975] Re: VACUUM中にCOPYが終わらない

[T.Suzuki]

鈴木＠KEGと申します。

> 運用やシステムの変更は、現時点ではままならない状態です。
> 現在、最優先で知りたい情報は、このような現象がなぜ発生する
> かです。先も書きましたが、現在はインデックスを無くすことで
> 安定した稼動状態になってはいます。しかし、お客様への説明が
> 十分でない上、今後も同様のシステムが必要な場合にどのように
> 対処すべきを判断する為に（PostgreSQLではダメとか、8.0なら大丈夫とか・・）
> 是非お力をお貸しいただきたく思っております。

確認ですが、”ハング”すると書かれていましたが
PostgreSQLではなくて、Copyを実行しているプログラムが
ハングしているのですよね？

そうだとして、”現象がなぜ発生するか”は、
VACUUM 中に、Copy処理が長時間ロック解放待ちになった場合の
対策を行っていないからではないでしょうか？

Cで書かれたプログラムの構成が分からないので
ヘタな憶測になって申し訳ないですが…

例えば、1分毎にスレッドを起動してCopyを実行している場合、
VACUUM中は、Copy処理がロック待ちになるので
約480個 （8時間分） のスレッドがロックの解放待ちになる事も
作り方次第ではあるでしょう。
pg_locks を見る限りでは、こんな作りにはなっていない事は分かりますが
長時間、ロック解放待ちになる事で、プログラムに不都合が起きていませんか？

VACUUM ではなく、table_a をロックしても試せると思います。
# BEGIN;
# LOCK table_a IN ACESS EXCLUSIVE MODE;
　〜監視プログラムを実行して適当な時間、反応を見守る。
# END;
　〜止まっていたCopyが実行されるか見守る。

プログラム側の情報収集を、もう少しされてはいかがでしょうか。

> Indexes:
>     "tbl_a_key" primary key, btree (item01, item02, item03, item04, item05, 
> item11)
個人的には、ログ系のテーブルならば
6個もの複合インデックスになっている主キーを
Serial へ変えれば、VACUUM ANALYZEが早くなると思います。Copyも早くなるし。

 -----------------------------------------
      鈴木 徹 (SUZUKI Toru)
      Kenwood Engineering Corporation.
      E-mail:t_suzuki ＠ kenwood-eng.co.jp
 -----------------------------------------