[pgsql-jp: 40602] Re: トランザクションの結果反映遅延についてご質問

[Hiroshi Inoue]

井上です。

(2010/12/07 14:44), Itagaki Takahiro wrote:
> 2010/12/7<toshihideka4316 ＠ zenrin.co.jp>:
>> ログは以下の通りです。
>
> ログを見る限り、「トランザクションの結果反映に遅延が生じる」原因は、
> やはり実際にはサーバで処理が続いていたためのようです。「コミット」と
> あるところでは、実際にはまだコミットは完了していません。
> out of memory の際に、サーバがパイプの切断を検知していることから、
> DB⇔AP間で適切な通信ができなくなっていることは確実です。
>
> 対策としては、out of memory にならないようAPを作るのが前提ですが、
> もし out of memory した場合はトランザクションの顛末がどうなったかを、
> 他の接続から確認する必要があると思われます。その場合、別接続経由で
> pg_cancel/terminate_backend で処理を強制停止することも視野に入ります。
>
>
> とはいえ、サーバやドライバの動きにも、若干気になる点があります：

ドライバはOut of memoryとなった時点で、通信の途中にもかかわらず
エラーとしてAPIからreturnしてしまっていました。このためサーバー
側から返すデータの残りが未処理のまま残ってしまい、サーバー側が
ハングする結果となっていました。9.0.0202では残りのデータを読み
飛ばすように変更して双方の同期を取るようにしました。、

>> ⇒5)にてコミット後に接続を切断しない場合、コミットを行ってから20分たってもト
>> ランザクションの結果が反映されない
>
> なぜ切断がコミットに結び付くのかが不思議です。切断時に通信キューを
> フラッシュするような動作になるんでしょうか？ サーバプロセス自体は
> 生きているので、SELECT が終わった後、キューに残っている COMMIT を
> 受け取ってしまうのかもしれません。
>
> また、サーバ側での COMMERROR は、エラーレベルとしては LOG 扱いで、
> 処理は継続してしまうようです。

多分これが原因で強制切断後にcommitが処理されてしまったのでしょう。

> これって妥当な動作なんでしたっけ？

妥当とは言えないと思います。送信がおかしくなった時点でもう「会話」
になっていないと思いますが。

> 通信バッファ溢れ程度ならばリトライが望ましいとは思いますが、
> 言ってみれば「途中で電話は切れましたが、申し込みは受け付けました！」
> となるのは、まずいケースもあるような気がします。