[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 メーリングリストの案内