[pgpool-general-jp: 1106] pgpool-II 3.2.1, 3.1.5, 3.0.9 released

Nozomi Anzai anzai @ sraoss.co.jp
2012年 10月 12日 (金) 17:12:59 JST


安齋です。

pgpool-II 3.2.1, 3.1.5, 3.0.9 をリリースしましたのでお知らせいたします。こ
れらは、各メジャーバージョンの最新安定版です。

以下からダウンロードすることができます。
http://pgpool.net/mediawiki/index.php/Downloads

============================================================================
3.2.1
============================================================================

http://git.postgresql.org/gitweb/?p=pgpool2.git;a=shortlog;h=refs/heads/V3_2_STABLE

- send_cached_messages() を修正しました。 (Tatsuo Ishii)

  これまでは、行データが 8192 byte 以上のときはバッファ長を 8192 byte に修
  正してキャッシュしているだけでした。
  これを、引数としてわたってきたバッファ用の raw データのコピーを削除して、
  send_message へのポインタを無視するようにしました。

- クエリキャッシュ機能により、拡張問い合わせが失敗していたのを修正しまし
  た。 (Nozomi Anzai)

-  read_startup_packet() を修正しました。(Tatsuo Ishii)

  パケット長が 0 以下のときは直ちに return するべきでしたが、そうなっていな
  く、メモリ確保時にエラーになっていました。
  これは pgpool-general:886 を参照してください。また、キャンセルアラームを
  追加しました。

  [pgpool-general: 886] read_startup_packet: out of memory
  From: Lonni J Friedman
  Date: Wed, 8 Aug 2012 10:18:15 -0700
  http://www.sraoss.jp/pipermail/pgpool-general/2012-August/000896.html

- pgpool をシャットダウンするときに、watchdog のプロセス終了方法を修正し
  ました。 (Tatsuo Ishii)

  watchdog プロセスは kill(0,SIG) を呼んで watchdog 関連のプロセスを終了し
  ていました。これによってかえって、親プロセスや pgpool や httpd プロセスま
  でもを終了させることがありました。これは、pgpoolAdmin によって invoke さ
  れている場合に、すべてが同じプロセスグループになるためです。
  将来は、どんな場合でも setsid() によって新しいプロセスグループを作るべき
  だと思います。

- "-- コメント" で始まったりコメントが複数あるクエリで、クエリキャッシュが
  使えなかったのを修正しました。(Nozomi Anzai)

- マルチステートメントのクエリはキャッシュしないようにしました。
  (Nozomi Anzai)

  これまでは "SELECT 1;UPDATE..." のようなクエリもキャッシュしていました
  が、誤りでした。

- ドキュメントに watchdog の制限を追記しました。(Yugo Nagata)

- s_do_auth() に NOTICE メッセージ処理を追加しました。(Tatsuo Ishii)
  (Tatsuo Ishii)

  これがなかったために、ヘルスチェックがNOTICEメッセージを受け取った時
  にフェイルオーバしていました。
  これはバグトラックで報告されました。

  #25 s_do_auth doesn't handle NoticeResponse (N) message
  Date:     2012-08-28 03:57
  Reporter: singh.gurjeet
  http://www.pgpool.net/mantisbt/view.php?id=25

- s_do_auth() から、不要かつ混乱をまねくデバッグメッセージを削除しました。
  (Tatsuo Ishii)

- メモリキャッシュ有効時に Execute() でバッファオーバーランするのを修正しま
  した。(Tatsuo Ishii)

  bind パラメータのひとつが 0 より小さいとき、符号拡張のために "%02X" で
  2 バイト以上の文字を生成する可能性がありました。
  また、そのあとにバッファオーバランを招く可能性を排除するため、sprintf()
  ではなく snprintf() を使うようにしました。

- 2009 年 12 月にリリースした pgpool-II 2.3 以来ずっと存在した
  free_select_result() のメモリリークを修正しました。(Tatsuo Ishii)

  実際にはこのバグは、レプリケーションモードでしか発生しません(タイムスタ
  ンプ書き換え時に偶然発生することがありました)。
  これはバグトラック #24 で報告されました。

  #24 Severe memory leak in an OLTP environment
  Date:     2012-08-28 03:43
  Reporter: singh.gurjeet
  http://www.pgpool.net/mantisbt/view.php?id=24

- cache_reporting() の typo を修正しました。(Tatsuo Ishii)

- SSL モードでの無限ループを修正しました。 (Tatsuo Ishii)

  フロントエンドの SSL レイヤで溜っているデータがあるとき、
  pool_process_query() がバックエンドに溜っているデータをチェックします。
  もしそれが無かったときは再度ループして、フロントエンド/バックエンドがバッ
  ファを受け取っていないか is_cache_empty() を以ってチェックします。
  しかし、フロントエンドの SSL レイヤでデータが溜っているのを一度検知する
  と、バックエンドに行ってまたチェックしようとします(無限ループ)。

  これを解決するには、フロントエンドの SSL レイヤに溜っているデータがあり
  かつ クエリが実行中でなければ、ProcessFrontendResponse() を呼んでフロント
  エンドへの新しいリクエストをするようにしました。

- is_system_catalog() で、可能ならば pgpool_regclass を使うようにしました。
  (Tatsuo Ishii)

- pool_get_insert_table_name() のメモリリークを修正しました。(Tatsuo Ishii)

  nodeToString() でセッションコンテクストのメモリコンテクストを使ったあと、
  セッション終了までは、メモリを開放していませんでした。
  詳しくはバグトラックをご覧ください。

  #24 Severe memory leak in an OLTP environment
  Date:     2012-08-28 03:43
  Reporter: singh.gurjeet
  http://www.pgpool.net/mantisbt/view.php?id=24

- OID マップファイルをロックするのに flock(2) ではなく fcntl(2) を使うよう
  にしました。(Tatsuo Ishii)

  flock(2) は環境に依存し、Solaris で使えませんでした。
  パッチは Ibrar Ahmed さんからいただきました。

- Raw モードで稼働しているとき、get_next_master_node() で見落としがあったの
  を修正しました。(Tatsuo Ishii)

  マスタノードがダウンしたとき、必ずマスタノード ID 0 を返していました。

  詳細は [pgpool-general: 1039] をご覧ください。

  [pgpool-general: 1039] Raw failover not working as expected on pgpool-II
  v3.2.0
  From: Quentin White
  Date: Tue, 25 Sep 2012 07:45:34 +0000
  http://www.sraoss.jp/pipermail/pgpool-general/2012-September/001057.html

- do_query() のセグメンテーションフォルトを修正しました。(Tatsuo Ishii)

  クエリキャッシュが有効で拡張問い合わせが使われているとき、do_query() はシ
  ステムカタログに接続し、pool_read2() を使います。しかし、parse メッセージ
  パケットを Parse() で取得し、パケットの内容が pool_read2() のバッファにあ
  ります。このため、do_query() はパケットの内容を分割できず、セグメンテー
  ションフォルトを引き起こしていました。

  これを解決するために、メモリを確保し、パケット内容をコピーし、Parse() を
  飛ばすようにしました。ただし、パケットの中にはクエリコンテクストが参照し
  ているクエリ文字列も含まれています。そのため、このクエリ文字列をコピーし
  てポインタをクエリコンテクストに保持する必要があります。

  これは、Parse() だけの話でなく、他のプロトコルモジュールにもある問題と考
  えています。本修正はそれらにも適用しますが、そのためには、
  ProcessFrontendResponse() を変更します。

  この問題はバグトラック #21 で報告されました。

  #21 pgpool-II 3.2.0 cannot execute sql through jdbc
  Date:     2012-08-17 16:31
  Reporter: elisechiang
  http://www.pgpool.net/mantisbt/view.php?id=21

- PCP 通信で UNIX ドメインソケットパスをセットするのを、シグナルハンドラの
  セットアップ前に行なうように修正しました。(Yugo Nagata)

  これまでは、このパス情報がなかったために、プロセス終了時のソケットの削除
  が失敗していました。

  パッチは Gilles Darold さんが提供しました。

  [pgpool-hackers: 131] Found bug with watchdog resulting in pgpool
                        segmentation fault
  From: Gilles Darold
  Date: Thu, 13 Sep 2012 18:54:42 +0200
  http://www.sraoss.jp/pipermail/pgpool-hackers/2012-September/000130.html

- watchdog の ifup/ifdown や arping コマンドが存在しないときにメッセージを
  出すようにしました。 (Yugo Nagata)

- ずっとあった do_query() で "portal "" does not exist" エラーが出るのを修
  正しました。(Tatsuo Ishii)

  1) 拡張問い合わせを使っていて、2) unnamed portal が使われていて、3) 明示
  的なトランザクションを使っていないとき、ユーザの unnamed portal が Sync
  メッセージで削除されていました。
  これは、Sync メッセージがトランザクションを終了して unnamed portal を削除
  するためです。このために "portal "" does not exist" というエラーが出てい
  ました。

  これを修正するために、Sync ではなく Flush メッセージを使うようにしまし
  た。二者の主な違いとしては、Flush は Ready For Query メッセージを返さない
  ことです。したがって do_query() は、来るべきであろうメッセージをすべて
  待ってから return するようになります。
  バックエンドからメッセージが来る順序はランダムに見えますが、do_query() は
  それを状態のビットを以って管理しています。

============================================================================
3.1.5, 3.0.9
============================================================================

http://git.postgresql.org/gitweb/?p=pgpool2.git;a=shortlog;h=refs/heads/V3_1_STABLE
http://git.postgresql.org/gitweb/?p=pgpool2.git;a=shortlog;h=refs/heads/V3_0_STABLE

- Fix read_startup_packet. (Tatsuo Ishii)

  If packet length is lower than 0, it should
  have returned immediately. Otherwise it would cause memory allocation
  error later on.  per pgpool-general:886.
  Also add canceling alarm.

  パケット長が 0 以下のときは直ちに return するべきでしたが、そうなっていな
  く、メモリ確保時にエラーになっていました。
  これは pgpool-general:886 を参照してください。また、キャンセルアラームを
  追加しました。

  [pgpool-general: 886] read_startup_packet: out of memory
  From: Lonni J Friedman
  Date: Wed, 8 Aug 2012 10:18:15 -0700
  http://www.sraoss.jp/pipermail/pgpool-general/2012-August/000896.html

- s_do_auth() に NOTICE メッセージ処理を追加しました。(Tatsuo Ishii)
  (Tatsuo Ishii)

  これがなかったために、ヘルスチェックがNOTICEメッセージを受け取った時
  にフェイルオーバしていました。
  これはバグトラックで報告されました。

  #25 s_do_auth doesn't handle NoticeResponse (N) message
  Date:     2012-08-28 03:57
  Reporter: singh.gurjeet
  http://www.pgpool.net/mantisbt/view.php?id=25

- s_do_auth() から、不要かつ混乱をまねくデバッグメッセージを削除しました。
  (Tatsuo Ishii)

- SSL モードでの無限ループを修正しました。 (Tatsuo Ishii)

  フロントエンドの SSL レイヤで溜っているデータがあるとき、
  pool_process_query() がバックエンドに溜っているデータをチェックします。
  もしそれが無かったときは再度ループして、フロントエンド/バックエンドがバッ
  ファを受け取っていないか is_cache_empty() を以ってチェックします。
  しかし、フロントエンドの SSL レイヤでデータが溜っているのを一度検知する
  と、バックエンドに行ってまたチェックしようとします(無限ループ)。

  これを解決するには、フロントエンドの SSL レイヤに溜っているデータがあり
  かつ クエリが実行中でなければ、ProcessFrontendResponse() を呼んでフロント
  エンドへの新しいリクエストをするようにしました。

- is_system_catalog() で、可能ならば pgpool_regclass を使うようにしました。
  (Tatsuo Ishii)

- pool_get_insert_table_name() のメモリリークを修正しました。(Tatsuo Ishii)

  nodeToString() でセッションコンテクストのメモリコンテクストを使ったあと、
  セッション終了までは、メモリを開放していませんでした。
  詳しくはバグトラックをご覧ください。

  #24 Severe memory leak in an OLTP environment
  Date:     2012-08-28 03:43
  Reporter: singh.gurjeet
  http://www.pgpool.net/mantisbt/view.php?id=24

- ずっとあった do_query() で "portal "" does not exist" エラーが出るのを修
  正しました。(Tatsuo Ishii)

  1) 拡張問い合わせを使っていて、2) unnamed portal が使われていて、3) 明示
  的なトランザクションを使っていないとき、ユーザの unnamed portal が Sync
  メッセージで削除されていました。
  これは、Sync メッセージがトランザクションを終了して unnamed portal を削除
  するためです。このために "portal "" does not exist" というエラーが出てい
  ました。

  これを修正するために、Sync ではなく Flush メッセージを使うようにしまし
  た。二者の主な違いとしては、Flush は Ready For Query メッセージを返さない
  ことです。したがって do_query() は、来るべきであろうメッセージをすべて
  待ってから return するようになります。
  バックエンドからメッセージが来る順序はランダムに見えますが、do_query() は
  それを状態のビットを以って管理しています。

============================================================================

-- 
Nozomi Anzai
SRA OSS, Inc. Japan


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