[pgsql-jp: 41041] Re: トランザクション中のネットワーク切断

Hiroki Kataoka kataoka @ interwiz.jp
2012年 1月 28日 (土) 14:35:09 JST


片岡です。

ネットワーク断イベントはソケットに対するアクセス時(select含む)にエラーやシグナルで伝達されるはずですから、バックエンドがビジー中(ロック待ち含む)はソケットアクセスが無いのでご指摘のように検出されないと思います。ただしこれはTCP/IP+Keepaliveでも同じだと思います。

(このスレッドの当初の話題とは逆の話ですが)ロック待ちのクライアントがネットワーク断でいなくなった場合ですが、ロックが解消した時点でソケットに何らかのアクセス(sendかselect)をするでしょうから、その時点でバックエンドはネットワーク断を検出すると思われます。ネットワーク断の発生から検出するまでのタイムラグは厳密には無駄な時間ですが、もともとネットワーク断がなかったとしても消費しただろう時間ですから、ネットワーク断によって状況が「悪化」したわけではないと考えることができるます。

というわけで、バックエンドがビジー中にネットワーク断が検出できないことは、さほど憂慮すべき事ではないように思います。

2012年1月28日9:13 Tatsuo Ishii <ishii @ sraoss.co.jp>:
> 石井です。
>
> バックエンドがソケットの読み出しや書き込みを行っているタイミングであれ
> ば検出できると思いますが、たとえばロック待ちになっている状態でクライア
> ントがいなくなってしまった場合は、バックエンドは待ち続けることになりま
> す。TCP/IP+Keepaliveではこのケースは救済されると思いますが、いかがでしょ
> う?
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese: http://www.sraoss.co.jp
>
>> 片岡です。
>>
>> ソケットの実装によって挙動が変わる可能性はありますが、UNIXドメインソケットの場合、(クライアントプロセスが落ちるなどの)不意のコネクション切断はEOFやSIGPIPEなどでサーバプロセスにタイムリーに伝わると思われますので、そもそもtcp_keepalives_*は必要なさそうです。
>>
>> 2012年1月28日2:12 Tatsuo Ishii <ishii @ sraoss.co.jp>:
>>> 石井です。
>>>
>>> tcp_keepalives_*を設定する方法は、当たり前ですが UNIX ドメインソケット
>>> を使って接続している場合には効果がないというのが欠点だと思います。
>>> --
>>> Tatsuo Ishii
>>> SRA OSS, Inc. Japan
>>> English: http://www.sraoss.co.jp/index_en.php
>>> Japanese: http://www.sraoss.co.jp
>>>
>>>> 片岡です。
>>>>
>>>> コネクション断は、LinuxやWindowsのデフォルトでは2時間少々で検出されます。つまりその間はロックされっぱなしになる可能性があります。
>>>>
>>>> もっと早いタイミングで検出したいなら、通常はpostgresql.confで
>>>> tcp_keepalives_idle
>>>> tcp_keepalives_interval
>>>> tcp_keepalives_count
>>>> を設定すればOKですが、残念ながらWindowsではnot
>>>> suppoertedで機能しません。Windowsで対策をするなら、レジストリを書き換えてOSのデフォルト設定(2時間)を変更するしかないと思います。
>>>>
>>>> Windows XPのドキュメントですが、 http://support.microsoft.com/kb/314053/ja>>>> KeepAliveTime
>>>> KeepAliveInterval
>>>> TcpMaxDataRetransmissions
>>>> このあたりをチェックしてみてください。
>>>>
>>>> 2012年1月27日19:26 水口(ヴァンガードネットワークス) <mizuguchi @ vanguard.ne.jp>:
>>>>> SELECT FRO UPDATE後に障害でネットワークが切断されると
>>>>> そのテーブルがロックしたままとなり
>>>>> 他のクライアントの同じ処理でSELECT FOR UPDATE できなくなってしまいます
>>>>> この様に浮いてしまったトランザクションは自動的に解放されないのでしょうか?
>>>>
>>>>> 環境
>>>>> SERVER:WINDOWS7-32Bit postgresql8.3.12
>>>>
>>>> --
>>>> Hiroki Kataoka
>>>
>>
>>
>>
>> --
>> Hiroki Kataoka
>



-- 
Hiroki Kataoka


pgsql-jp メーリングリストの案内