[pgsql-jp: 40174] Re: update文のフリーズ

[Fujii Masao]

2010/2/16 Eiichiro Sakai <sakai ＠ agate-japan.com>:
> 以下のようなSQLをpgpool2（2.1）経由で複数のプロセスより大量に実行していたと
> ころupdate文（下記tr2）が途中でフリーズし、その後同様のSQLを実行しても
> select for update文（下記tr1）がロック待ちの状態となり滞留し続けていく状況と
> なりました。
>
> begin;
> select * from tableA where id = 1;（tr1）
> その他の処理
> update tableA SET column = xx where id = 1;（tr2）
> commit;
>
> １．トリガとなったupdate文のSQLログを見るとbindまでは出力されていますが、
> executeのログが出力されていない状況で止まってしまっています。
> これはどのような時に発生しうるでしょうか？
> 回避策をご存じの方がいらっしゃればご教授いただければと思います。

文中の SQL ログとはどのログ (PostgreSQL のサーバログ? pgpool? アプリ独自?) を
指しますでしょうか?

可能であれば、そのログをいただけませんでしょうか?

execute message は PostgreSQL には届いていないとの認識でよろしいでしょうか?
この認識で正しければ、問題の UPDATE の前に実行された SELECT FOR UPDATE が
ロックを獲得したままになっています。このロックは COMMIT / ROLLBACK の段階で
開放されますが、UPDATE の execute message が届かないため、そこまで処理が
進みません。このため、他の SELECT FOR UPDATE がロック待ちになったのだと思われます。

まずは、execute message がどこまで届いたのか確認してください。PostgreSQL まで
届いていなければ、上記の通りで、pgpool またはアプリ側の問題を次に疑います。

> ２．tr2でフリーズ後のpg_stat_activityを見るとフリーズが起こる前に実行されて
> い
>    るがtr1でロック待ちのままとなっているトランザクションが多数存在していま
> した。
> ただ、フリーズが起こる前は他のいくつかのトランザクションは正常終了（上記
>    commitまで終了）している状態です。
> このことよりpostgresは必ずしもロック要求があった順番にロック取得
> しているわけではないように思えますが理解は正しいでしょうか？

はい。アプリが発行した順序でクエリが実行されるとは限りません。OS のスケジューラ等の
都合によって、クエリの実行順序は前後します。

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center