[pgpool-general-jp: 1153] pgpool-II 3.2.4, 3.1.7, 3.0.11, and pgpool-ha 2.1 released
Yugo Nagata
nagata ＠ sraoss.co.jp
2013年 4月 26日 (金) 15:57:18 JST
長田です。
pgpool-II 3.2.4, 3.1.7, 3.0.11 をリリースしましたのでお知らせいたします。
これらは、各メジャーバージョンの最新安定版です。
また、pgpool-ha 2.1 がリリースされました。
これは、pgpool-ha のマイナーバージョンアップです。
以下からダウンロードすることができます。
http://pgpool.net/mediawiki/index.php/Downloads
===========================================================================
pgpool-II 3.2.4
===========================================================================
---------------------------------------------------------------------------
* バグ修正
---------------------------------------------------------------------------
- connect_inet_domain_socket_by_port() 関数内で select(2) に渡される
タイムアウトパラメータをより適切に修正しました。(Tatuo Ishii)
Solaris などいくつかのプラットフォームでは、タイムアウトのマイクロ秒に
1000000 以上の大きな値を指定することが許されていません。そのため、タイム
アウト値を秒とマイクロ秒に分けて設定するようにしました。
- connect_inet_domain_socket_by_port() で alarm 割り込み時を受けた時に、
エラー処理を行うよう修正しました。(Tatsuo Ishii)
この関数が無効なファイルディスクリプタを返すためにヘルスチェックが混乱し、
エラー検出に長時間かかる原因となっていました。
[pgpool-general: 1458]
health check timeout in pgpool-II-3.2.3
http://www.pgpool.net/pipermail/pgpool-general/2013-March/001482.html
- 拡張プロトコルの処理における timestamp
の書き換えに関する長い間見過ごされていたバグを修正しました。(Tatsuo Ishii)
Parse() 関数は、parse メッセージの書き換えの際に palloc() を使ってメモリ
を確保していました。しかし、書き換えられたメッセージは
pool_create_sent_message() 関数などが管理するデータ領域に格納されるのが問題
となります。この関数ではデータが session context memory 中に存在することを
想定しているのに対し、palloc() では query context 中でメモリの割り当てを行い、
これは query context 終了時に解放されます。一方で、他の関数もこのメモリを解放
しようとするため、セグメンテーション違反や二重解放を含む様々な問題の原因となっ
ていました。この問題は、書き換えたメッセージを格納するメモリを session context
を用いて確保するこで修正されました。これは pgpool-II 3.0 以来ずっと存在してい
たバグです。
この問題は、Naoya Anzai さんによって解析され、パッチが提供されました。
[pgpoolgenera-jp: 1146]
拡張問い合わせプロトコルでセグメンテーションフォルト
http://www.pgpool.net/pipermail/pgpool-general-jp/2013-March/001145.html
- md5認証で長いユーザ名を処理する際のバグを修正しました。(Tatsuo Ishii)
ユーザ名が 32 バイトより長い場合、md5 認証が動作していませんでした。
この問題は [pgpool-general: 1526] で Thomas Martin さんにより報告されました。
[pgpool-general: 1526]
[pgPool-II 3.2.3] MD5 authentication and username longer than 32 characters.
http://www.pgpool.net/pipermail/pgpool-general/2013-March/001551.html
- レプリケーション遅延の計算はスタンバイサーバがプライマリサーバより
遅れている場合にのみ行うよう修正しました。(Yugo Nagata)
タイミングによってスタンバイよりプライマリの方がレプリケーションが遅延
しているように見える場合があり、その場合には負値の遅延が計算されていました。
この値が符号無し変数に代入されると、実際には遅延が生じていないにも関わらず、
ログに遅延が負値で出力され、されに悪いことには、ロードバランス機能により
SELECT クエリがプライマリに振り分けられ、その結果プライマリの負荷が高まる
ことがありました。
この問題は Saitoh Hidenori さんによって報告、解析されました。
[pgpool-genera-jp: 1145]
レプリケーション遅延確認の不具合について
http://www.pgpool.net/pipermail/pgpool-general-jp/2013-March/001144.html
- pgpool-recovery が PostgreSQL 9.3 に対応しました。 (Tatsuo Ishii)
パッチは Asif Rehman さんにより提供され、これに Tatsuo Ishii が若干の修正を
加えました。
[pgpool-hackers: 180]
compile error in ppool-recovery
http://www.pgpool.net/pipermail/pgpool-hackers/2013-April/000179.html
- pool_has_pgpool_regclass が pgpool_regclass() の実行権限をチェックする
よう修正しました。 (Tatsuo Ishii)
pgpool_regclass が存在する場合でも、pgpool がこの関数を実行できない場合に、
バックエンドへの接続がハングしていました。この問題は、pgpool_regclass
から実行権限を剥奪し、ネイティブレプリケーションモードで INSERT を実行
することで再現可能です。
この問題は bugtrack #53 で報告されました。
#53 pgpool_regclas hangs all connections
Date: 2013-04-04 13:35
Reporter: tmandke
http://www.pgpool.net/mantisbt/view.php?id=53
- detect_postmaster_down_error() のエラーメッセージを修正しました。(Tatsuo Ishii)
例えば、"LOG: detect_stop_postmaster_error: detect_error error" を
"LOG: detect_postmaster_down_error: detect_error error" に修正するなどです。
- watchdog 使用時の root ユーザであるかのチェックを取り除きました。
(Tatsuo Ishii)
詳しい議論は以下を参照してください。
[pgpool-general: 1627]
Re: watchdog root requirement.
http://www.pgpool.net/pipermail/pgpool-general/2013-April/001654.html
- 別名を持つ UPDATE/DELETE の処理におけるオンメモリクエリキャッシュのバグを
修正しました。(Tatsuo Ishii)
別名を持つ UPDATE/DELETE 文（例えば、UPDATE t1 AS foo ...）において、
"t1 AS foo" がテーブル名と認識されていたため、クエリキャッシュの無効化が
うまく働いていませんでした。これは、パースツリーのノードからクエリ文を
生成する nodeToString() 関数から呼び出されている _outRangeVar() 関数に
原因があります。出力されたクエリ文から "AS foo" の部分を取り除くことで
解決しました。
この問題はバグトラック #56 で報告されました。
#56 UPDATE with alias does not discard cache
Date: 2013-04-18 17:33
Reporter: harukat
http://www.pgpool.net/mantisbt/view.php?id=56
===========================================================================
pgpool-II 3.1.7
===========================================================================
---------------------------------------------------------------------------
* バグ修正
---------------------------------------------------------------------------
- 設定パラメータの一覧を表示する "SHOW pool_status" で pool_passwd
が表示されていないのを修正しました。(Yugo Nagata)
- 拡張プロトコルの処理における timestamp
の書き換えに関する長い間見過ごされていたバグを修正しました。(Tatsuo Ishii)
Parse() 関数は、parse メッセージの書き換えの際に palloc() を使ってメモリ
を確保していました。しかし、書き換えられたメッセージは
pool_create_sent_message() 関数などが管理するデータ領域に格納されるのが問題
となります。この関数ではデータが session context memory 中に存在することを
想定しているのに対し、palloc() では query context 中でメモリの割り当てを行い、
これは query context 終了時に解放されます。一方で、他の関数もこのメモリを解放
しようとするため、セグメンテーション違反や二重解放を含む様々な問題の原因となっ
ていました。この問題は、書き換えたメッセージを格納するメモリを session context
を用いて確保するこで修正されました。これは pgpool-II 3.0 以来ずっと存在してい
たバグです。
この問題は、Naoya Anzai さんによって解析され、パッチが提供されました。
[pgpoolgenera-jp: 1146]
拡張問い合わせプロトコルでセグメンテーションフォルト
http://www.pgpool.net/pipermail/pgpool-general-jp/2013-March/001145.html
- md5認証で長いユーザ名を処理する際のバグを修正しました。(Tatsuo Ishii)
ユーザ名が 32 バイトより長い場合、md5 認証が動作していませんでした。
この問題は [pgpool-general: 1526] で Thomas Martin さんにより報告されました。
[pgpool-general: 1526]
[pgPool-II 3.2.3] MD5 authentication and username longer than 32 characters.
http://www.pgpool.net/pipermail/pgpool-general/2013-March/001551.html
- レプリケーション遅延の計算はスタンバイサーバがプライマリサーバより
遅れている場合にのみ行うよう修正しました。(Yugo Nagata)
タイミングによってスタンバイよりプライマリの方がレプリケーションが遅延
しているように見える場合があり、その場合には負値の遅延が計算されていました。
この値が符号無し変数に代入されると、実際には遅延が生じていないにも関わらず、
ログに遅延が負値で出力され、されに悪いことには、ロードバランス機能により
SELECT クエリがプライマリに振り分けられ、その結果プライマリの負荷が高まる
ことがありました。
この問題は Saitoh Hidenori さんによって報告、解析されました。
[pgpool-genera-jp: 1145]
レプリケーション遅延確認の不具合について
http://www.pgpool.net/pipermail/pgpool-general-jp/2013-March/001144.html
- pgpool-recovery が PostgreSQL 9.3 に対応しました。 (Tatsuo Ishii)
パッチは Asif Rehman さんにより提供され、これに Tatsuo Ishii が若干の修正を
加えました。
[pgpool-hackers: 180]
compile error in ppool-recovery
http://www.pgpool.net/pipermail/pgpool-hackers/2013-April/000179.html
- pool_has_pgpool_regclass が pgpool_regclass() の実行権限をチェックする
よう修正しました。 (Tatsuo Ishii)
pgpool_regclass が存在する場合でも、pgpool がこの関数を実行できない場合に、
バックエンドへの接続がハングしていました。この問題は、pgpool_regclass
から実行権限を剥奪し、ネイティブレプリケーションモードで INSERT を実行
することで再現可能です。
この問題は bugtrack #53 で報告されました。
#53 pgpool_regclas hangs all connections
Date: 2013-04-04 13:35
Reporter: tmandke
http://www.pgpool.net/mantisbt/view.php?id=53
- detect_postmaster_down_error() のエラーメッセージを修正しました。(Tatsuo Ishii)
例えば、"LOG: detect_stop_postmaster_error: detect_error error" を
"LOG: detect_postmaster_down_error: detect_error error" に修正するなどです。
===========================================================================
pgpool-II 3.0.11
===========================================================================
---------------------------------------------------------------------------
* バグ修正
---------------------------------------------------------------------------
- 設定パラメータの一覧を表示する "SHOW pool_status" で pool_passwd
が表示されていないのを修正しました。(Yugo Nagata)
- 拡張プロトコルの処理における timestamp
の書き換えに関する長い間見過ごされていたバグを修正しました。(Tatsuo Ishii)
Parse() 関数は、parse メッセージの書き換えの際に palloc() を使ってメモリ
を確保していました。しかし、書き換えられたメッセージは
pool_create_sent_message() 関数などが管理するデータ領域に格納されるのが問題
となります。この関数ではデータが session context memory 中に存在することを
想定しているのに対し、palloc() では query context 中でメモリの割り当てを行い、
これは query context 終了時に解放されます。一方で、他の関数もこのメモリを解放
しようとするため、セグメンテーション違反や二重解放を含む様々な問題の原因となっ
ていました。この問題は、書き換えたメッセージを格納するメモリを session context
を用いて確保するこで修正されました。これは pgpool-II 3.0 以来ずっと存在してい
たバグです。
この問題は、Naoya Anzai さんによって解析され、パッチが提供されました。
[pgpoolgenera-jp: 1146]
拡張問い合わせプロトコルでセグメンテーションフォルト
http://www.pgpool.net/pipermail/pgpool-general-jp/2013-March/001145.html
- md5認証で長いユーザ名を処理する際のバグを修正しました。(Tatsuo Ishii)
ユーザ名が 32 バイトより長い場合、md5 認証が動作していませんでした。
この問題は [pgpool-general: 1526] で Thomas Martin さんにより報告されました。
[pgpool-general: 1526]
[pgPool-II 3.2.3] MD5 authentication and username longer than 32 characters.
http://www.pgpool.net/pipermail/pgpool-general/2013-March/001551.html
- レプリケーション遅延の計算はスタンバイサーバがプライマリサーバより
遅れている場合にのみ行うよう修正しました。(Yugo Nagata)
タイミングによってスタンバイよりプライマリの方がレプリケーションが遅延
しているように見える場合があり、その場合には負値の遅延が計算されていました。
この値が符号無し変数に代入されると、実際には遅延が生じていないにも関わらず、
ログに遅延が負値で出力され、されに悪いことには、ロードバランス機能により
SELECT クエリがプライマリに振り分けられ、その結果プライマリの負荷が高まる
ことがありました。
この問題は Saitoh Hidenori さんによって報告、解析されました。
[pgpool-genera-jp: 1145]
レプリケーション遅延確認の不具合について
http://www.pgpool.net/pipermail/pgpool-general-jp/2013-March/001144.html
- pgpool-recovery が PostgreSQL 9.3 に対応しました。 (Tatsuo Ishii)
パッチは Asif Rehman さんにより提供され、これに Tatsuo Ishii が若干の修正を
加えました。
[pgpool-hackers: 180]
compile error in ppool-recovery
http://www.pgpool.net/pipermail/pgpool-hackers/2013-April/000179.html
- pool_has_pgpool_regclass が pgpool_regclass() の実行権限をチェックする
よう修正しました。 (Tatsuo Ishii)
pgpool_regclass が存在する場合でも、pgpool がこの関数を実行できない場合に、
バックエンドへの接続がハングしていました。この問題は、pgpool_regclass
から実行権限を剥奪し、ネイティブレプリケーションモードで INSERT を実行
することで再現可能です。
この問題は bugtrack #53 で報告されました。
#53 pgpool_regclas hangs all connections
Date: 2013-04-04 13:35
Reporter: tmandke
http://www.pgpool.net/mantisbt/view.php?id=53
- detect_postmaster_down_error() のエラーメッセージを修正しました。(Tatsuo Ishii)
例えば、"LOG: detect_stop_postmaster_error: detect_error error" を
"LOG: detect_postmaster_down_error: detect_error error" に修正するなどです。
--
Yugo Nagata <nagata ＠ sraoss.co.jp>
pgpool-general-jp メーリングリストの案内