[pgpool-general-jp: 1405] pgpool-II 3.5.3, 3.4.7, 3.3.11, 3.2.16, 3.1.19, and pgpoolAdmin 3.5.3 released
Bo Peng
pengbo @ sraoss.co.jp
2016年 6月 17日 (金) 21:01:56 JST
彭です。
3.5.3, 3.4.7, 3.3.11, 3.2.16, 3.1.19, および pgpoolAdmin 3.5.3 をリリース
しましたのでお知らせいたします。
以下からダウンロードすることができます。
http://pgpool.net/mediawiki/index.php/Downloads
3.5.3 (ekieboshi) 2016/06/17
* 概要
このバージョンは 3.5.2 に対するバグ修正リリースです。
__________________________________________________________________
* 改善
- ヘルスチェックを実施中の間でも、pgpool に接続ができるようになりました。
(Tatsuo Ishii)
今まではダウンしたノードに対してヘルスチェックを行っている間は、
たとえ fail_over_on_backend_error が off になっていても、pgpool
に接続することができませんでした。
これは、pgpool の子プロセスがダウンしているノードを含めてすべての
バックエンドに接続を試み、一つでも接続に失敗したら終了してしまう
からです(もちろんこの場合は接続に失敗します)。これは一時的な状態
で、pgpool がフェイルオーバーを完了すれば問題は起きません。
しかし、ヘルスチェックがリトライを実施している間は、
health_check_max_retries とhealth_check_retry_delay の設定によっ
ては長時間、このような一時的な状態が続きます。
今回の修正では、以下のようにしてこの問題が解決されました。
- ストリーミングレプリケーションモードでは、pgpoolの子プロセスが
バックエンドへの接続に失敗すると、そこで終了してしまうのではな
く、失敗したバックエンドノードがプライマリーノードでない限りそ
のノードをスキップして次のノードに接続を試みます。
- この場合、その子プロセスはそのノードを「ダウン中」とローカルに
記憶します。ローカルにダウン中とマークされたノードは、ロードバ
ランスの対象から外れます。
- セッションが終了するとその子プロセスは終了し、ローカルにマークし
た「ダウン中」の状態を新しいセッションでも継続しないようにします。
これは、ヘルスチェックのリトライの結果、一時的にダウン中のノード
が復活することがありえるからです。
詳しくは [pgpool-hackers: 1531] を参照してください。
* バグ修正
- is_set_transaction_serializable() 関数の
SET default_transaction_isolation TO 'serializable' のバグを修正しました。(Bo Peng)
pgpool は SET default_transaction_isolation TO 'serializable' をプライマリ
だけではなく、スタンバイにも送信してしまい、エラーが起きていました。
この修正で、streaming replication モードの場合、
SET default_transaction_isolation TO 'serializable'がプライマリサーバのみに
送信されます。
bug #191 の報告によります。
- ドキュメントのraw モードに関する内容の誤りを修正しました。(Yugo Nagata, Bo Peng)
raw モードの場合、コネクションプーリングが有効です。
- pgpool.confの不正確なコメントを修正しました。(Tatsuo Ishii)
- 拡張プロトコルのraw モードでのバグを修正しました。(Tatsuo Ishii)
Bug152の報告により、拡張プロトコルの raw モード(実は stream モード以外)
で Describe() と Close() の処理に誤りがありました。
stream モードとは異なり、バックエンドからの応答を待つべきでした。
bug #152 の報告によります。
- pgpool が 複数 SSL cipher protocols に対応させるように修正しました。
(Muhammad Usama)
今まで TLSv1_method() を使って、SSL contextを初期化していました。
そのため、SSL通信で TLSv1 protocol のみに対応するという制約がありました。
この修正で、上記制約をなくし、SSLv23_method() を使って SSLSession を
初期化するように修正しました(PostgreSQL と同じように)。この関数が特定
バージョンのプロトコルを利用することではなく、互換性のあるプロトコルの最新
バージョンを利用できるからです。
- バックエンドのステートメントタイムアウトが有効な場合、do_query() が
最初のクエリをプライマリノードに送信し、それ以降のユーザクエリを
スタンバイノードに送信します。例えば、END コマンドの場合、プライマリ
ノードのステートメントタイムアウトを引き起こし、kind mismatch error が
発生する可能性がありました。
この問題を軽減するために、do_query() がフラッシュメッセージを送信する
代わりに、sync メッセージ送信するように修正しました。sync メッセージを
送信することで、明示的トランザクションの場合、ステートメントタイムアウト
タイマーがリセットされます。unnamed portal が存在する場合、sync メッセージが
unnamed portal を削除しますので、暗黙的トランザクションの場合には
適用しません。
また、pg_stat_statement が do_query() が発行したクエリを "running" で
表示しなくなります。
bug #194 の報告によります。
- streaming replication モードで、プライマリノードが 0 ではない場合に発生
するバグを修正しました。 (Tatsuo Ishii)
http://www.pgpool.net/mantisbt/view.php?id=194#c837の報告により、
bug194-3.3.diff を適用しても、プライマリノードが 0 ではない場合、
ステートメントタイムアウトが発生する可能性がありました。
調査した結果、MASTER マクロがプライマリノードまたはロードバランスノード
以外のノードを返したからです。そのため、 do_query() がクエリを間違った
ノードに送信してしまいました(これは報告で確認されていませんが、
調査で確認できました)。
MASTER マクロと呼ばれる pool_virtual_master_db_node_id() が、
クエリコンテキストが存在する場合、query_context->virtual_master_node_id
を返します。その変数が初期化されていない場合、この関数が間違ったノード
を返す可能性があります。そのため、pool_virtual_master_db_node_id()
関数を以下のように修正しました。戻り値がプライマリノードまたはロード
バランスノードではない場合、プライマリノードを返します。
- #197 で報告されたハングを修正しました。(Muhammad Usama)
watchdogが有効で、バックエンドノードとリモートpgpool-II ノードが
同時接続できなくになった場合、クライアント接続がスタックします。
原因は watchdog に IPC コマンドを送信する関数を呼び出すコマンド
タイムアウトがなかったからです。
bug #197 の報告によります。
- 報告されたcoverity scan の問題を修正しました。(Muhammad Usama)
- src/sql/ 配下の Makefile を修正しました。 (Bo Peng)
詳しくは [pgpool-hackers: 1611] を参照してください。
- ヘルスチェックで発生し得るハングアップを修正しました。 (Yugo Nagata)
connect(2) が成功し、その後バックエンドからデータが送信されない場合、
ヘルスチェックがハングしていました。ヘルスチェックが行われると、
select(2)にSIGALRMを送信し、EINTRで抜けて、pool_check_fd() は 1 を
返すように修正しました。
パッチはバグ報告者によって作成され、Yugo により修正されました。
bug #204 の報告によります。
- 共有メモリ上のロードバランスノードの書き込みに関するバグを修正しました。(Tatsuo Ishii)
領域が少ないため、ロードバランスノードは間違ったことろに置かれてしまいました。
[正しい場所]
ConnectionInfo *con_info[child id, connection pool_id, backend id].load_balancing_node].
[実際に置かれた場所]
*con_info[child id, connection pool_id, 0].load_balancing_node].
バックエンドid が 0 の場合、上記バグが発生しませんが、 pgpool-II 3.6 の
フェイルオーバーテストで、プライマリノードが 1 (ロードバランスノード)、
スタンバイノードが 0 の場合、ノード1 の接続が切断され、フェイルオーバー
が起きています。これは想定外のバグです。
このバグが前からありましたが、上記の原因で、今まで見つかっておリませんでした。
===============================================================================
3.4.7 (tataraboshi) 2016/06/17
* 概要
このバージョンは 3.4.6 に対するバグ修正リリースです。
__________________________________________________________________
* 改善
- ヘルスチェックを実施中の間でも、pgpool に接続ができるようになりました。
(Tatsuo Ishii)
今まではダウンしたノードに対してヘルスチェックを行っている間は、
たとえ fail_over_on_backend_error が off になっていても、pgpool
に接続することができませんでした。
これは、pgpool の子プロセスがダウンしているノードを含めてすべての
バックエンドに接続を試み、一つでも接続に失敗したら終了してしまう
からです(もちろんこの場合は接続に失敗します)。これは一時的な状態
で、pgpool がフェイルオーバーを完了すれば問題は起きません。
しかし、ヘルスチェックがリトライを実施している間は、
health_check_max_retries とhealth_check_retry_delay の設定によっ
ては長時間、このような一時的な状態が続きます。
今回の修正では、以下のようにしてこの問題が解決されました。
- ストリーミングレプリケーションモードでは、pgpoolの子プロセスが
バックエンドへの接続に失敗すると、そこで終了してしまうのではな
く、失敗したバックエンドノードがプライマリーノードでない限りそ
のノードをスキップして次のノードに接続を試みます。
- この場合、その子プロセスはそのノードを「ダウン中」とローカルに
記憶します。ローカルにダウン中とマークされたノードは、ロードバ
ランスの対象から外れます。
- セッションが終了するとその子プロセスは終了し、ローカルにマークし
た「ダウン中」の状態を新しいセッションでも継続しないようにします。
これは、ヘルスチェックのリトライの結果、一時的にダウン中のノード
が復活することがありえるからです。
詳しくは [pgpool-hackers: 1531] を参照してください。
* バグ修正
- is_set_transaction_serializable() 関数の
SET default_transaction_isolation TO 'serializable' のバグを修正しました。(Bo Peng)
pgpool は SET default_transaction_isolation TO 'serializable' をプライマリ
だけではなく、スタンバイにも送信してしまい、エラーが起きていました。
この修正で、streaming replication モードの場合、
SET default_transaction_isolation TO 'serializable'がプライマリサーバのみに
送信されます。
bug #191 の報告によります。
- ドキュメントのraw モードに関する内容の誤りを修正しました。(Yugo Nagata, Bo Peng)
raw モードの場合、コネクションプーリングが有効です。
- pgpool.confの不正確なコメントを修正しました。(Tatsuo Ishii)
- pgpool が 複数 SSL cipher protocols に対応させるように修正しました。
(Muhammad Usama)
今まで TLSv1_method() を使って、SSL contextを初期化していました。
そのため、SSL通信で TLSv1 protocol のみに対応するという制約がありました。
この修正で、上記制約をなくし、SSLv23_method() を使って SSLSession を
初期化するように修正しました(PostgreSQL と同じように)。この関数が特定
バージョンのプロトコルを利用することではなく、互換性のあるプロトコルの最新
バージョンを利用できるからです。
- バックエンドのステートメントタイムアウトが有効な場合、do_query() が
最初のクエリをプライマリノードに送信し、それ以降のユーザクエリを
スタンバイノードに送信します。例えば、END コマンドの場合、プライマリ
ノードのステートメントタイムアウトを引き起こし、kind mismatch error が
発生する可能性がありました。
この問題を軽減するために、do_query() がフラッシュメッセージを送信する
代わりに、sync メッセージ送信するように修正しました。sync メッセージを
送信することで、明示的トランザクションの場合、ステートメントタイムアウト
タイマーがリセットされます。unnamed portal が存在する場合、sync メッセージが
unnamed portal を削除しますので、暗黙的トランザクションの場合には
適用しません。
また、pg_stat_statement が do_query() が発行したクエリを "running" で
表示しなくなります。
bug #194 の報告によります。
- streaming replication モードで、プライマリノードが 0 ではない場合に発生
するバグを修正しました。 (Tatsuo Ishii)
http://www.pgpool.net/mantisbt/view.php?id=194#c837の報告により、
bug194-3.3.diff を適用しても、プライマリノードが 0 ではない場合、
ステートメントタイムアウトが発生する可能性がありました。
調査した結果、MASTER マクロがプライマリノードまたはロードバランスノード
以外のノードを返したからです。そのため、 do_query() がクエリを間違った
ノードに送信してしまいました(これは報告で確認されていませんが、
調査で確認できました)。
MASTER マクロと呼ばれる pool_virtual_master_db_node_id() が、
クエリコンテキストが存在する場合、query_context->virtual_master_node_id
を返します。変数がセットされていない場合、この関数が間違ったノード
を返す可能性があります。そのため、pool_virtual_master_db_node_id()
関数を以下のように修正しました。戻り値がプライマリノードまたはロード
バランスノードではない場合、プライマリノードを返します。
- src/sql/ 配下の Makefile を修正しました。 (pengbo)
詳しくは [pgpool-hackers: 1611] を参照してください。
- ヘルスチェックで発生し得るハングアップを修正しました。 (Yugo Nagata)
connect(2) が成功し、その後バックエンドからデータが送信されない場合、
ヘルスチェックがハングしていました。ヘルスチェックが行われると、
select(2)にSIGALRMを送信し、EINTRで抜けて、pool_check_fd() は 1 を
返すように修正しました。
パッチはバグ報告者によって作成され、Yugo により修正されました。
bug #204 の報告によります。
- 共有メモリ上のロードバランスノードの書き込みに関するバグを修正しました。(Tatsuo Ishii)
領域が少ないため、ロードバランスノードは間違ったことろに置かれてしまいました。
[正しい場所]
ConnectionInfo *con_info[child id, connection pool_id, backend id].load_balancing_node].
[実際に置かれた場所]
*con_info[child id, connection pool_id, 0].load_balancing_node].
バックエンドid が 0 の場合、上記バグが発生しませんが、 pgpool-II 3.6 の
フェイルオーバーテストで、プライマリノードが 1 (ロードバランスノード)、
スタンバイノードが 0 の場合、ノード1 の接続が切断され、フェイルオーバー
が起きています。これは想定外のバグです。
このバグが前からありましたが、上記の原因で、今まで見つかっておリませんでした。
===============================================================================
3.3.11 (tokakiboshi) 2016/06/17
* 概要
このバージョンは 3.3.10 に対するバグ修正リリースです。
__________________________________________________________________
* 改善
- ヘルスチェックを実施中の間でも、pgpool に接続ができるようになりました。
(Tatsuo Ishii)
今まではダウンしたノードに対してヘルスチェックを行っている間は、
たとえ fail_over_on_backend_error が off になっていても、pgpool
に接続することができませんでした。
これは、pgpool の子プロセスがダウンしているノードを含めてすべての
バックエンドに接続を試み、一つでも接続に失敗したら終了してしまう
からです(もちろんこの場合は接続に失敗します)。これは一時的な状態
で、pgpool がフェイルオーバーを完了すれば問題は起きません。
しかし、ヘルスチェックがリトライを実施している間は、
health_check_max_retries とhealth_check_retry_delay の設定によっ
ては長時間、このような一時的な状態が続きます。
今回の修正では、以下のようにしてこの問題が解決されました。
- ストリーミングレプリケーションモードでは、pgpoolの子プロセスが
バックエンドへの接続に失敗すると、そこで終了してしまうのではな
く、失敗したバックエンドノードがプライマリーノードでない限りそ
のノードをスキップして次のノードに接続を試みます。
- この場合、その子プロセスはそのノードを「ダウン中」とローカルに
記憶します。ローカルにダウン中とマークされたノードは、ロードバ
ランスの対象から外れます。
- セッションが終了するとその子プロセスは終了し、ローカルにマークし
た「ダウン中」の状態を新しいセッションでも継続しないようにします。
これは、ヘルスチェックのリトライの結果、一時的にダウン中のノード
が復活することがありえるからです。
詳しくは [pgpool-hackers: 1531] を参照してください。
* バグ修正
- is_set_transaction_serializable() 関数の
SET default_transaction_isolation TO 'serializable' のバグを修正しました。(Bo Peng)
pgpool は SET default_transaction_isolation TO 'serializable' をプライマリ
だけではなく、スタンバイにも送信してしまい、エラーが起きていました。
この修正で、streaming replication モードの場合、
SET default_transaction_isolation TO 'serializable'がプライマリサーバのみに
送信されます。
bug #191 の報告によります。
- ドキュメントのraw モードに関する内容の誤りを修正しました。(Yugo Nagata, Bo Peng)
raw モードの場合、コネクションプーリングが有効です。
- pgpool.confの不正確なコメントを修正しました。(Tatsuo Ishii)
- pgpool が 複数 SSL cipher protocols に対応させるように修正しました。
(Muhammad Usama)
今まで TLSv1_method() を使って、SSL contextを初期化していました。
そのため、SSL通信で TLSv1 protocol のみに対応するという制約がありました。
この修正で、上記制約をなくし、SSLv23_method() を使って SSLSession を
初期化するように修正しました(PostgreSQL と同じように)。この関数が特定
バージョンのプロトコルを利用することではなく、互換性のあるプロトコルの最新
バージョンを利用できるからです。
- バックエンドのステートメントタイムアウトが有効な場合、do_query() が
最初のクエリをプライマリノードに送信し、それ以降のユーザクエリを
スタンバイノードに送信します。例えば、END コマンドの場合、プライマリ
ノードのステートメントタイムアウトを引き起こし、kind mismatch error が
発生する可能性がありました。
この問題を軽減するために、do_query() がフラッシュメッセージを送信する
代わりに、sync メッセージ送信するように修正しました。sync メッセージを
送信することで、明示的トランザクションの場合、ステートメントタイムアウト
タイマーがリセットされます。unnamed portal が存在する場合、sync メッセージが
unnamed portal を削除しますので、暗黙的トランザクションの場合には
適用しません。
また、pg_stat_statement が do_query() が発行したクエリを "running" で
表示しなくなります。
bug #194 の報告によります。
- streaming replication モードで、プライマリノードが 0 ではない場合に発生
するバグを修正しました。 (Tatsuo Ishii)
http://www.pgpool.net/mantisbt/view.php?id=194#c837の報告により、
bug194-3.3.diff を適用しても、プライマリノードが 0 ではない場合、
ステートメントタイムアウトが発生する可能性がありました。
調査した結果、MASTER マクロがプライマリノードまたはロードバランスノード
以外のノードを返したからです。そのため、 do_query() がクエリを間違った
ノードに送信してしまいました(これは報告で確認されていませんが、
調査で確認できました)。
MASTER マクロと呼ばれる pool_virtual_master_db_node_id() が、
クエリコンテキストが存在する場合、query_context->virtual_master_node_id
を返します。変数がセットされていない場合、この関数が間違ったノード
を返す可能性があります。そのため、pool_virtual_master_db_node_id()
関数を以下のように修正しました。戻り値がプライマリノードまたはロード
バランスノードではない場合、プライマリノードを返します。
- src/sql/ 配下の Makefile を修正しました。 (pengbo)
詳しくは [pgpool-hackers: 1611] を参照してください。
- ヘルスチェックで発生し得るハングアップを修正しました。 (Yugo Nagata)
connect(2) が成功し、その後バックエンドからデータが送信されない場合、
ヘルスチェックがハングしていました。ヘルスチェックが行われると、
select(2)にSIGALRMを送信し、EINTRで抜けて、pool_check_fd() は 1 を
返すように修正しました。
パッチはバグ報告者によって作成され、Yugo により修正されました。
bug #204 の報告によります。
- 共有メモリ上のロードバランスノードの書き込みに関するバグを修正しました。(Tatsuo Ishii)
領域が少ないため、ロードバランスノードは間違ったことろに置かれてしまいました。
[正しい場所]
ConnectionInfo *con_info[child id, connection pool_id, backend id].load_balancing_node].
[実際に置かれた場所]
*con_info[child id, connection pool_id, 0].load_balancing_node].
バックエンドid が 0 の場合、上記バグが発生しませんが、 pgpool-II 3.6 の
フェイルオーバーテストで、プライマリノードが 1 (ロードバランスノード)、
スタンバイノードが 0 の場合、ノード1 の接続が切断され、フェイルオーバー
が起きています。これは想定外のバグです。
このバグが前からありましたが、上記の原因で、今まで見つかっておリませんでした。
===============================================================================
3.2.16 (namameboshi) 2016/06/17
* 概要
このバージョンは 3.2.15 に対するバグ修正リリースです。
__________________________________________________________________
* 改善
- ヘルスチェックを実施中の間でも、pgpool に接続ができるようになりました。
(Tatsuo Ishii)
今まではダウンしたノードに対してヘルスチェックを行っている間は、
たとえ fail_over_on_backend_error が off になっていても、pgpool
に接続することができませんでした。
これは、pgpool の子プロセスがダウンしているノードを含めてすべての
バックエンドに接続を試み、一つでも接続に失敗したら終了してしまう
からです(もちろんこの場合は接続に失敗します)。これは一時的な状態
で、pgpool がフェイルオーバーを完了すれば問題は起きません。
しかし、ヘルスチェックがリトライを実施している間は、
health_check_max_retries とhealth_check_retry_delay の設定によっ
ては長時間、このような一時的な状態が続きます。
今回の修正では、以下のようにしてこの問題が解決されました。
- ストリーミングレプリケーションモードでは、pgpoolの子プロセスが
バックエンドへの接続に失敗すると、そこで終了してしまうのではな
く、失敗したバックエンドノードがプライマリーノードでない限りそ
のノードをスキップして次のノードに接続を試みます。
- この場合、その子プロセスはそのノードを「ダウン中」とローカルに
記憶します。ローカルにダウン中とマークされたノードは、ロードバ
ランスの対象から外れます。
- セッションが終了するとその子プロセスは終了し、ローカルにマークし
た「ダウン中」の状態を新しいセッションでも継続しないようにします。
これは、ヘルスチェックのリトライの結果、一時的にダウン中のノード
が復活することがありえるからです。
詳しくは [pgpool-hackers: 1531] を参照してください。
* バグ修正
- is_set_transaction_serializable() 関数の
SET default_transaction_isolation TO 'serializable' のバグを修正しました。(Bo Peng)
pgpool は SET default_transaction_isolation TO 'serializable' をプライマリ
だけではなく、スタンバイにも送信してしまい、エラーが起きていました。
この修正で、streaming replication モードの場合、
SET default_transaction_isolation TO 'serializable'がプライマリサーバのみに
送信されます。
bug #191 の報告によります。
- ドキュメントのraw モードに関する内容の誤りを修正しました。(Yugo Nagata, Bo Peng)
raw モードの場合、コネクションプーリングが有効です。
- pgpool.confの不正確なコメントを修正しました。(Tatsuo Ishii)
- pgpool が 複数 SSL cipher protocols に対応させるように修正しました。
(Muhammad Usama)
今まで TLSv1_method() を使って、SSL contextを初期化していました。
そのため、SSL通信で TLSv1 protocol のみに対応するという制約がありました。
この修正で、上記制約をなくし、SSLv23_method() を使って SSLSession を
初期化するように修正しました(PostgreSQL と同じように)。この関数が特定
バージョンのプロトコルを利用することではなく、互換性のあるプロトコルの最新
バージョンを利用できるからです。
- バックエンドのステートメントタイムアウトが有効な場合、do_query() が
最初のクエリをプライマリノードに送信し、それ以降のユーザクエリを
スタンバイノードに送信します。例えば、END コマンドの場合、プライマリ
ノードのステートメントタイムアウトを引き起こし、kind mismatch error が
発生する可能性がありました。
この問題を軽減するために、do_query() がフラッシュメッセージを送信する
代わりに、sync メッセージ送信するように修正しました。sync メッセージを
送信することで、明示的トランザクションの場合、ステートメントタイムアウト
タイマーがリセットされます。unnamed portal が存在する場合、sync メッセージが
unnamed portal を削除しますので、暗黙的トランザクションの場合には
適用しません。
また、pg_stat_statement が do_query() が発行したクエリを "running" で
表示しなくなります。
bug #194 の報告によります。
- streaming replication モードで、プライマリノードが 0 ではない場合に発生
するバグを修正しました。 (Tatsuo Ishii)
http://www.pgpool.net/mantisbt/view.php?id=194#c837の報告により、
bug194-3.3.diff を適用しても、プライマリノードが 0 ではない場合、
ステートメントタイムアウトが発生する可能性がありました。
調査した結果、MASTER マクロがプライマリノードまたはロードバランスノード
以外のノードを返したからです。そのため、 do_query() がクエリを間違った
ノードに送信してしまいました(これは報告で確認されていませんが、
調査で確認できました)。
MASTER マクロと呼ばれる pool_virtual_master_db_node_id() が、
クエリコンテキストが存在する場合、query_context->virtual_master_node_id
を返します。変数がセットされていない場合、この関数が間違ったノード
を返す可能性があります。そのため、pool_virtual_master_db_node_id()
関数を以下のように修正しました。戻り値がプライマリノードまたはロード
バランスノードではない場合、プライマリノードを返します。
- src/sql/ 配下の Makefile を修正しました。 (pengbo)
詳しくは [pgpool-hackers: 1611] を参照してください。
- ヘルスチェックで発生し得るハングアップを修正しました。 (Yugo Nagata)
connect(2) が成功し、その後バックエンドからデータが送信されない場合、
ヘルスチェックがハングしていました。ヘルスチェックが行われると、
select(2)にSIGALRMを送信し、EINTRで抜けて、pool_check_fd() は 1 を
返すように修正しました。
パッチはバグ報告者によって作成され、Yugo により修正されました。
bug #204 の報告によります。
- 共有メモリ上のロードバランスノードの書き込みに関するバグを修正しました。(Tatsuo Ishii)
領域が少ないため、ロードバランスノードは間違ったことろに置かれてしまいました。
[正しい場所]
ConnectionInfo *con_info[child id, connection pool_id, backend id].load_balancing_node].
[実際に置かれた場所]
*con_info[child id, connection pool_id, 0].load_balancing_node].
バックエンドid が 0 の場合、上記バグが発生しませんが、 pgpool-II 3.6 の
フェイルオーバーテストで、プライマリノードが 1 (ロードバランスノード)、
スタンバイノードが 0 の場合、ノード1 の接続が切断され、フェイルオーバー
が起きています。これは想定外のバグです。
このバグが前からありましたが、上記の原因で、今まで見つかっておリませんでした。
===============================================================================
3.1.19 (hatsuiboshi) 2016/06/17
* 概要
このバージョンは 3.1.18 に対するバグ修正リリースです。
__________________________________________________________________
* バグ修正
- is_set_transaction_serializable() 関数の
SET default_transaction_isolation TO 'serializable' のバグを修正しました。(Bo Peng)
pgpool は SET default_transaction_isolation TO 'serializable' をプライマリ
だけではなく、スタンバイにも送信してしまい、エラーが起きていました。
この修正で、streaming replication モードの場合、
SET default_transaction_isolation TO 'serializable'がプライマリサーバのみに
送信されます。
bug #191 の報告によります。
- ドキュメントのraw モードに関する内容の誤りを修正しました。(Yugo Nagata, Bo Peng)
raw モードの場合、コネクションプーリングが有効です。
- pgpool.confの不正確なコメントを修正しました。(Tatsuo Ishii)
- pgpool が 複数 SSL cipher protocols に対応させるように修正しました。
(Muhammad Usama)
今まで TLSv1_method() を使って、SSL contextを初期化していました。
そのため、SSL通信で TLSv1 protocol のみに対応するという制約がありました。
この修正で、上記制約をなくし、SSLv23_method() を使って SSLSession を
初期化するように修正しました(PostgreSQL と同じように)。この関数が特定
バージョンのプロトコルを利用することではなく、互換性のあるプロトコルの最新
バージョンを利用できるからです。
- バックエンドのステートメントタイムアウトが有効な場合、do_query() が
最初のクエリをプライマリノードに送信し、それ以降のユーザクエリを
スタンバイノードに送信します。例えば、END コマンドの場合、プライマリ
ノードのステートメントタイムアウトを引き起こし、kind mismatch error が
発生する可能性がありました。
この問題を軽減するために、do_query() がフラッシュメッセージを送信する
代わりに、sync メッセージ送信するように修正しました。sync メッセージを
送信することで、明示的トランザクションの場合、ステートメントタイムアウト
タイマーがリセットされます。unnamed portal が存在する場合、sync メッセージが
unnamed portal を削除しますので、暗黙的トランザクションの場合には
適用しません。
また、pg_stat_statement が do_query() が発行したクエリを "running" で
表示しなくなります。
bug #194 の報告によります。
- streaming replication モードで、プライマリノードが 0 ではない場合に発生
するバグを修正しました。 (Tatsuo Ishii)
http://www.pgpool.net/mantisbt/view.php?id=194#c837の報告により、
bug194-3.3.diff を適用しても、プライマリノードが 0 ではない場合、
ステートメントタイムアウトが発生する可能性がありました。
調査した結果、MASTER マクロがプライマリノードまたはロードバランスノード
以外のノードを返したからです。そのため、 do_query() がクエリを間違った
ノードに送信してしまいました(これは報告で確認されていませんが、
調査で確認できました)。
MASTER マクロと呼ばれる pool_virtual_master_db_node_id() が、
クエリコンテキストが存在する場合、query_context->virtual_master_node_id
を返します。変数がセットされていない場合、この関数が間違ったノード
を返す可能性があります。そのため、pool_virtual_master_db_node_id()
関数を以下のように修正しました。戻り値がプライマリノードまたはロード
バランスノードではない場合、プライマリノードを返します。
- src/sql/ 配下の Makefile を修正しました。 (pengbo)
詳しくは [pgpool-hackers: 1611] を参照してください。
- ヘルスチェックで発生し得るハングアップを修正しました。 (Yugo Nagata)
connect(2) が成功し、その後バックエンドからデータが送信されない場合、
ヘルスチェックがハングしていました。ヘルスチェックが行われると、
select(2)にSIGALRMを送信し、EINTRで抜けて、pool_check_fd() は 1 を
返すように修正しました。
パッチはバグ報告者によって作成され、Yugo により修正されました。
bug #204 の報告によります。
- 共有メモリ上のロードバランスノードの書き込みに関するバグを修正しました。(Tatsuo Ishii)
領域が少ないため、ロードバランスノードは間違ったことろに置かれてしまいました。
[正しい場所]
ConnectionInfo *con_info[child id, connection pool_id, backend id].load_balancing_node].
[実際に置かれた場所]
*con_info[child id, connection pool_id, 0].load_balancing_node].
バックエンドid が 0 の場合、上記バグが発生しませんが、 pgpool-II 3.6 の
フェイルオーバーテストで、プライマリノードが 1 (ロードバランスノード)、
スタンバイノードが 0 の場合、ノード1 の接続が切断され、フェイルオーバー
が起きています。これは想定外のバグです。
このバグが前からありましたが、上記の原因で、今まで見つかっておリませんでした。
--
Bo Peng <pengbo @ sraoss.co.jp>
SRA OSS, Inc. Japan
pgpool-general-jp メーリングリストの案内