2010年12月 8日

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

井上です。

(2010/12/07 14:44), Itagaki Takahiro wrote:
> 2010/12/7<toshihideka4316@xxxxx>:
>> ログは以下の通りです。
>
> ログを見る限り、「トランザクションの結果反映に遅延が生じる」原因は、
> やはり実際にはサーバで処理が続いていたためのようです。「コミット」と

> あるところでは、実際にはまだコミットは完了していません。
> 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が処理されてしまったのでしょう。

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

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

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


投稿者 xml-rpc : 2010年12月 8日 23:06
役に立ちました?:
過去のフィードバック 平均:(0) 総合:(0) 投票回数:(0)
本記事へのTrackback: http://hoop.euqset.org/blog/mt-tb2006.cgi/100597
トラックバック
コメント
コメントする




画像の中に見える文字を入力してください。