[pgsql-jp: 35717] Re: pgpoolのfflush()におけるEAGAIN

Tatsuo Ishii t-ishii ＠ sra.co.jp
2005年 7月 9日 (土) 19:56:59 JST 

石井です．

> 山下です。
> 
> From: Tatsuo Ishii <t-ishii ＠ sra.co.jp>
> Subject: [pgsql-jp: 35692] Re: pgpoolのfflush()におけるEAGAIN
> Date: Thu, 07 Jul 2005 17:17:04 +0900 (JST)
> 
> > なっていると思います)．とりあえず stdio関連をとっぱらい，pool_writeで
> > はバッファリングのみを行い，pool_flush の中でwriteするようにしたバージョ
> > ンを
> > 
> > http://www2b.biglobe.ne.jp/~caco/pgpool/tmp/pgpool-2.6.tar.gz
> > 
> > に置きましたので，良かったら試して頂けますか？
> 
> ちょっとテストしたところでは良い感じです。
> 引き続きテストを継続してみます。

よろしくお願いします．

> > > ということは write() を呼び出す前に select() を使って書き込
> > > み可能な状態を検査しつつ処理を進めるという手順が必要な気もし
> > > ます。また何か分かりましたらお知らせします。
> > 
> > write()で書き込み可能でなければEAGAINが返るのではないでしょうか．また，
> > select()で確認したとしても，次にwrite()を呼び出すときにはすでに書き込
> > み不可になっている可能性もあるわけで，あまり意味がないような...
> 
> この件については私の勉強不足だと思うので調べてみます。
> 
> こんなにすぐ動く様になるなんて思いませんでした。あまり力にな
> れなくてすいません。どうも有り難うございました。

いえ，お陰さまでfflushの問題がクリアになりました．

また，個別のメールで永橋さんから pgpool でのblock/non-blocking socket
の扱いが一貫していないというご指摘を受けました．

> solaris(HP-UXもそうですが)のaccept関数の説明では生成されるソケットは
> listenソケットの属性を引き継ぐ旨の記述があり、
> 逆にlinuxでは引き継がないとの記述ありますので以下のような状況に
> なっていると考えます。この違いからOSにより挙動がちがうんですね
> 
>  --------------------------------------------------------------
>         OS    |   linux    | solaris(HP-UX)  |  FreeBSD       |
>  --------------------------------------------------------------
>   backend向け |  blocking  | blocking        | blocking ？    |
>  --------------------------------------------------------------
>   frontend向け|  blocking  | non-blocking    | non-blocking？ |
>  --------------------------------------------------------------

今までnon-blocking+EAGAIN問題であまり苦情がこなかったのは，プラットフォー
ムの多数はがLinuxだったからなのですね:-) というわけで，FreeBSDや
Solarisのユーザの皆さまにはご迷惑をおかけしました．

実は偶然海外のFreeBSDユーザからもpgpoolの不安定さの指摘を受け，pgpool
2.6改で改善されたとの報告を受けました．

というわけで，今回行った修正を正式に取り込んで2.6.1としてリリースした
いと思っているのですが，どうもpgfoudryのcvsサーバが調子悪いようで，ま
だコミットできていません．2.6.1の正式リリースはもう少しお待ち下さい．

ところで，ソースを見直していたところ，今回の問題以外にも直した方が良い
と思われる箇所を見つけました．

1) read/writeがEINTRを返したときにエラーにしている．これはretryすべき
   だと思います．

2) readがEOFを返したときに，fatal error扱いにしており，ただちに縮退や
   フェイルオーバしていた．バックエンドは，バグやその他の理由で異常終
   了してソケットを閉じることがあります．それをfatal扱いにするのはちょっ
   と過剰反応ではないかと思います．そこでこのようなケースでは，単に
   pgpoolの子プロセスを異常終了させることにしました．pgpoolのクライア
   ントから見ると，あたかもPostgreSQL側から接続を切られたように見えま
   すが，これはこれでつじつまが合っている振る舞いかと思います．

   ただし，こうしたことにより，ネットワークトラブルなどの本当の障害の
   検知が遅れる可能性もあり，難しいところではあります．もしかしたら，
   PostgreSQLやネットワークの異常検知は，health checkにまかせた方が良
   いのかもしれない，などと思ったりもします．このあたり，識者のご意見
   をいただければ，と思います．

これらも2.6.1に取り込む予定です．

皆さまに報告とお礼まで．

P.S.
とりあえず現時点までの修正版を，

http://www2b.biglobe.ne.jp/~caco/pgpool/tmp/pgpool-2.6.1.tar.gz

に置きました．
--
Tatsuo Ishii

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