===============================================================================
3.1 Series (2011/09/08 - )
+===============================================================================
+
+ 3.1.19 (hatsuiboshi) 2016/06/17
+
+* Version 3.1.19
+
+ This is a bugfix release against pgpool-II 3.1.18.
+
+ __________________________________________________________________
+
+* Bug fixes
+
+ - Fix is_set_transaction_serializable() when
+ SET default_transaction_isolation TO 'serializable'. (Bo Peng)
+
+ SET default_transaction_isolation TO 'serializable' is sent to
+ not only primary but also to standby server in streaming replication mode,
+ and this causes an error. Fix is, in streaming replication mode,
+ SET default_transaction_isolation TO 'serializable' is sent only to the
+ primary server.
+
+ See bug 191 for related info.
+
+ - Fix Chinese documetation bug about raw mode (Yugo Nagata, Bo Peng)
+ Connection pool is avalilable in raw mode.
+
+ - Fix confusing comments in pgpool.conf (Tatsuo Ishii)
+
+ - Permit pgpool to support multiple SSL cipher protocols (Muhammad Usama)
+
+ Currently TLSv1_method() is used to initialize the SSL context, that puts an
+ unnecessary limitation to allow only TLSv1 protocol for SSL communication.
+ While postgreSQL supports other ciphers protocols as well. The commit changes
+ the above and initializes the SSLSession using the SSLv23_method()
+ (same is also used by PostgreSQL). Because it can negotiate the use of the
+ highest mutually supported protocol version and remove the limitation of one
+ specific protocol version.
+
+ - If statement timeout is enabled on backend and do_query() sends a (Tatsuo Ishii)
+ query to primary node, and all of following user queries are sent to
+ standby, it is possible that the next command, for example END, could
+ cause a statement timeout error on the primary, and a kind mismatch
+ error on pgpool-II is raised.
+
+ This fix tries to mitigate the problem by sending sync message instead
+ of flush message in do_query(), expecting that the sync message reset
+ the statement timeout timer if we are in an explicit transaction. We
+ cannot use this technique for implicit transaction case, because the
+ sync message removes the unnamed portal if there's any.
+
+ Plus, pg_stat_statement will no longer show the query issued by
+ do_query() as "running".
+
+ See bug 194 for related info.
+
+ - Deal with the case when the primary is not node 0 in streaming replication mode. (Tatsuo Ishii)
+
+ http://www.pgpool.net/mantisbt/view.php?id=194#c837 reported that if
+ primary is not node 0, then statement timeout could occur even after
+ bug194-3.3.diff was applied. After some investigation, it appeared
+ that MASTER macro could return other than primary or load balance
+ node, which was not supposed to happen, thus do_query() sends queries
+ to wrong node (this is not clear from the report but I confirmed it in
+ my investigation).
+
+ pool_virtual_master_db_node_id(), which is called in MASTER macro
+ returns query_context->virtual_master_node_id if query context
+ exists. This could return wrong node if the variable has not been set
+ yet. To fix this, the function is modified: if the variable is not
+ either load balance node or primary node, the primary node id is
+ returned.
+
+ - change the Makefile under the directory src/sql/, that is proposed (Bo Peng)
+ by [pgpool-hackers: 1611]
+
+ - Fix a posible hang during health checking (Yugo Nagata)
+
+ Helath checking was hang when any data wasn't sent
+ from backend after connect(2) succeeded. To fix this,
+ pool_check_fd() returns 1 when select(2) exits with
+ EINTR due to SIGALRM while health checkking is performed.
+
+ Reported and patch provided by harukat and some modification
+ by Yugo. Per bug #204.
+
+ backported from 3.4 or later;
+ https://git.postgresql.org/gitweb/?p=pgpool2.git;a=commitdiff;h=ed9f2900f1b611f5cfd52e8f758c3616861e60c0
+
+ - Fix bug with load balance node id info on shmem (Tatsuo Ishii)
+
+ There are few places where the load balance node was mistakenly put on
+ wrong place. It should be placed on: ConnectionInfo *con_info[child
+ id, connection pool_id, backend id].load_balancing_node]. In fact it
+ was placed on: *con_info[child id, connection pool_id,
+ 0].load_balancing_node].
+
+ As long as the backend id in question is 0, it is ok. However while
+ testing pgpool-II 3.6's enhancement regarding failover, if primary
+ node is 1 (which is the load balance node) and standby is 0, a client
+ connecting to node 1 is disconnected when failover happens on node
+ 0. This is unexpected and the bug was revealed.
+
+ It seems the bug was there since long time ago but it had not found
+ until today by the reason above.
+
===============================================================================
3.1.18 (hatsuiboshi) 2016/04/26
<a href="http://www.pgpool.net/mantisbt/view.php?id=194#c837の報告により、">
http://www.pgpool.net/mantisbt/view.php?id=194#c837の報告により、
</a><br />
-bug194-3.3.diff を適用しても、プライマリノードが 0 ではない場合、<br />
-ステートメントタイムアウトが発生する可能性がありました。<br />
-調査した結果、MASTER マクロがプライマリノードまたはロードバランスノード<br />
-以外のノードを返したからです。そのため、 do_query() がクエリを間違った<br />
-ノードに送信してしまいました（これは報告で確認されていませんが、<br />
+bug194-3.3.diff を適用しても、プライマリノードが 0 ではない場合、
+ステートメントタイムアウトが発生する可能性がありました。
+調査した結果、MASTER マクロがプライマリノードまたはロードバランスノード
+以外のノードを返したからです。そのため、 do_query() がクエリを間違った
+ノードに送信してしまいました（これは報告で確認されていませんが、
調査で確認できました）。
</blockquote>
<blockquote>
- MASTER マクロと呼ばれる pool_virtual_master_db_node_id() が、<br />
-クエリコンテキストが存在する場合、query_context->virtual_master_node_id<br />
-を返します。変数がセットされていない場合、この関数が間違ったノード<br />
-を返す可能性があります。そのため、pool_virtual_master_db_node_id() <br />
-関数を以下のように修正しました。戻り値がプライマリノードまたはロード<br />
+ MASTER マクロと呼ばれる pool_virtual_master_db_node_id() が、
+クエリコンテキストが存在する場合、query_context-> virtual_master_node_id
+を返します。変数がセットされていない場合、この関数が間違ったノード
+を返す可能性があります。そのため、pool_virtual_master_db_node_id()
+関数を以下のように修正しました。戻り値がプライマリノードまたはロード
バランスノードではない場合、プライマリノードを返します。
</blockquote>
</li>
<!-- ================================================================================ -->
<hr>
+<!-- -------------------------------------------------------------------------------- -->
+<h2><a name="release3.1.19"></a>3.1.19 (hatsuiboshi) 2016/06/17</h2>
+<!-- -------------------------------------------------------------------------------- -->
+
+<h3>概要</h3>
+<p>
+このバージョンは 3.1.18 に対するバグ修正リリースです。
+</p>
+
+<h3>バグ修正</h3>
+<ul>
+
+<li>
+ is_set_transaction_serializable() 関数のSET default_transaction_isolation TO 'serializable' のバグを修正しました。(Bo Peng)
+ <p>
+ pgpool は SET default_transaction_isolation TO 'serializable' をプライマリだけではなく、スタンバイにも送信してしまい、エラーが起きていました。
+ </p>
+ <p>
+ この修正で、streaming replication モードの場合、SET default_transaction_isolation TO 'serializable'がプライマリサーバのみに送信されます。
+ </p>
+ <p>
+ bug #191 の報告によります。
+ </p>
+</li>
+
+<li>
+ ドキュメントのraw モードに関する内容の誤りを修正しました。(Yugo Nagata, Bo Peng)
+ <p>
+ raw モードの場合、コネクションプーリングが有効です。
+ </p>
+</li>
+
+<li>
+ pgpool.confの不正確なコメントを修正しました。(Tatsuo Ishii)
+</li>
+
+<li>
+ pgpool が 複数 SSL cipher protocols に対応させるように修正しました。(Muhammad Usama)
+ <p>
+ 今まで TLSv1_method() を使って、SSL contextを初期化していました。そのため、SSL通信で TLSv1 protocol のみに対応するという制約がありました。この修正で、上記制約をなくし、SSLv23_method() を使って SSLSession を初期化するように修正しました（PostgreSQL と同じように）。この関数が特定バージョンのプロトコルを利用することではなく、互換性のあるプロトコルの最新バージョンを利用できるからです。
+ </p>
+</li>
+
+<li>
+ バックエンドのステートメントタイムアウトが有効な場合、do_query() が最初のクエリをプライマリノードに送信し、それ以降のユーザクエリをスタンバイノードに送信します。例えば、END コマンドの場合、プライマリノードのステートメントタイムアウトを引き起こし、kind mismatch error が発生する可能性がありました。(Tatsuo Ishii)
+ <p>
+ この問題を軽減するために、do_query() がフラッシュメッセージを送信する代わりに、sync メッセージ送信するように修正しました。sync メッセージを送信することで、明示的トランザクションの場合、ステートメントタイムアウトタイマーがリセットされます。unnamed portal が存在する場合、sync メッセージがunnamed portal を削除しますので、暗黙的トランザクションの場合には適用しません。
+ </p>
+ <p>
+ また、pg_stat_statement が do_query() が発行したクエリを "running" で表示しなくなります。
+ </p>
+ <p>
+ bug #194 の報告によります。
+ </p>
+</li>
+
+<li>
+ streaming replication モードで、プライマリノードが 0 ではない場合に発生するバグを修正しました。 (Tatsuo Ishii)
+ <blockquote>
+ <a href="http://www.pgpool.net/mantisbt/view.php?id=194#c837の報告により、">
+ http://www.pgpool.net/mantisbt/view.php?id=194#c837の報告により、
+ </a><br />
+bug194-3.3.diff を適用しても、プライマリノードが 0 ではない場合、
+ステートメントタイムアウトが発生する可能性がありました。
+調査した結果、MASTER マクロがプライマリノードまたはロードバランスノード
+以外のノードを返したからです。そのため、 do_query() がクエリを間違った
+ノードに送信してしまいました（これは報告で確認されていませんが、
+調査で確認できました）。
+ </blockquote>
+ <blockquote>
+ MASTER マクロと呼ばれる pool_virtual_master_db_node_id() が、
+クエリコンテキストが存在する場合、query_context-> virtual_master_node_id
+を返します。変数がセットされていない場合、この関数が間違ったノード
+を返す可能性があります。そのため、pool_virtual_master_db_node_id()
+関数を以下のように修正しました。戻り値がプライマリノードまたはロード
+バランスノードではない場合、プライマリノードを返します。
+ </blockquote>
+</li>
+
+<li>
+ src/sql/ 配下の Makefile を修正しました。 (pengbo)
+ <p>
+ 詳しくは [pgpool-hackers: 1611] を参照してください。
+ </p>
+</li>
+
+<li>
+ ヘルスチェックで発生し得るハングアップを修正しました。 (Yugo Nagata)
+ <p>
+ connect(2) が成功し、その後バックエンドからデータが送信されない場合、ヘルスチェックがハングしていました。ヘルスチェックが行われると、select(2)にSIGALRMを送信し、EINTRで抜けて、pool_check_fd() は 1 を返すように修正しました。
+ </p>
+ <p>
+ パッチはバグ報告者によって作成され、Yugo により修正されました。
+ </p>
+ <p>
+ bug #204 の報告によります。
+ </p>
+</li>
+
+<li>
+ 共有メモリ上のロードバランスノードの書き込みに関するバグを修正しました。(Tatsuo Ishii)
+ <p>
+ 領域が少ないため、ロードバランスノードは間違ったことろに置かれてしまいました。
+ </p>
+ <p>
+ [正しい場所]ConnectionInfo *con_info[child id, connection pool_id, backend id].load_balancing_node].
+ </p>
+ <p>
+ [実際に置かれた場所]*con_info[child id, connection pool_id, 0].load_balancing_node].
+ </p>
+ <p>
+ バックエンドid が 0 の場合、上記バグが発生しませんが、 pgpool-II 3.6 のフェイルオーバーテストで、プライマリノードが 1 (ロードバランスノード)、スタンバイノードが 0 の場合、ノード1 の接続が切断され、フェイルオーバーが起きています。これは想定外のバグです。
+ </p>
+ <p>
+ このバグが前からありましたが、上記の原因で、今まで見つかっておリませんでした。
+ </p>
+</li>
+</ul>
<!-- -------------------------------------------------------------------------------- -->
<h2><a name="release3.1.18"></a>3.1.18 (hatsuiboshi) 2016/04/26</h2>
<!-- -------------------------------------------------------------------------------- -->
projects / pgpool2.git / commitdiff