change docs V3_4_7 V3_4_7_RPM
authorpengbo <pengbo@sraoss.co.jp>
Mon, 20 Jun 2016 10:29:36 +0000 (19:29 +0900)
committerpengbo <pengbo@sraoss.co.jp>
Mon, 20 Jun 2016 10:29:36 +0000 (19:29 +0900)
doc/pgpool-ja.html

index 7b4c7a24f1ed9160758c9c3c1d9c31e66d274088..e86df9ae7dac88cc11db0d47942051cf1b35ce56 100644 (file)
@@ -6188,7 +6188,7 @@ SELECTの最終実行ステータスとパフォーマンスのおおよその
 <ul>
 
 <li>
-    ヘルスチェックを実施中の間でも、pgpool に接続ができるようになりました。
+    ヘルスチェックを実施中の間でも、pgpool に接続ができるようになりました。(Tatsuo Ishii)
     <p>
     今まではダウンしたノードに対してヘルスチェックを行っている間は、たとえ fail_over_on_backend_error が off になっていても、pgpoolに接続することができませんでした。
     </p>
@@ -6231,7 +6231,10 @@ SELECTの最終実行ステータスとパフォーマンスのおおよその
 </li>
 
 <li>
-    ドキュメントのraw モードに関する内容の誤りを修正しました。(Yugo Nagata, Bo Peng)raw モードの場合、コネクションプーリングが有効です。
+    ドキュメントのraw モードに関する内容の誤りを修正しました。(Yugo Nagata, Bo Peng)
+    <p>
+    raw モードの場合、コネクションプーリングが有効です。
+    </p>
 </li>
 
 <li>
@@ -6246,7 +6249,7 @@ SELECTの最終実行ステータスとパフォーマンスのおおよその
 </li>
 
 <li>
-    バックエンドのステートメントタイムアウトが有効な場合、do_query() が最初のクエリをプライマリノードに送信し、それ以降のユーザクエリをスタンバイノードに送信します。例えば、END コマンドの場合、プライマリノードのステートメントタイムアウトを引き起こし、kind mismatch error が発生する可能性がありました。
+    バックエンドのステートメントタイムアウトが有効な場合、do_query() が最初のクエリをプライマリノードに送信し、それ以降のユーザクエリをスタンバイノードに送信します。例えば、END コマンドの場合、プライマリノードのステートメントタイムアウトを引き起こし、kind mismatch error が発生する可能性がありました。(Tatsuo Ishii)
     <p>
     この問題を軽減するために、do_query() がフラッシュメッセージを送信する代わりに、sync メッセージ送信するように修正しました。sync メッセージを送信することで、明示的トランザクションの場合、ステートメントタイムアウトタイマーがリセットされます。unnamed portal が存在する場合、sync メッセージがunnamed portal を削除しますので、暗黙的トランザクションの場合には適用しません。
     </p>
@@ -6264,25 +6267,28 @@ SELECTの最終実行ステータスとパフォーマンスのおおよその
         <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-&gt; virtual_master_node_id<br />
-を返します。変数がセットされていない場合、この関数が間違ったノード<br />
-を返す可能性があります。そのため、pool_virtual_master_db_node_id() <br />
-関数を以下のように修正しました。戻り値がプライマリノードまたはロード<br />
+    MASTER マクロと呼ばれる pool_virtual_master_db_node_id() が、
+クエリコンテキストが存在する場合、query_context-&gt; virtual_master_node_id
+を返します。変数がセットされていない場合、この関数が間違ったノード
+を返す可能性があります。そのため、pool_virtual_master_db_node_id() 
+関数を以下のように修正しました。戻り値がプライマリノードまたはロード
 バランスノードではない場合、プライマリノードを返します。
     </blockquote>
 </li>
 
 <li>
-    src/sql/ 配下の Makefile を修正しました。 (pengbo)詳しくは [pgpool-hackers: 1611] を参照してください。
+    src/sql/ 配下の Makefile を修正しました。 (pengbo)
+    <p>
+    詳しくは [pgpool-hackers: 1611] を参照してください。
+    </p>
 </li>
 
 <li>
@@ -6316,8 +6322,6 @@ bug194-3.3.diff を適用しても、プライマリノードが 0 ではない
     このバグが前からありましたが、上記の原因で、今まで見つかっておリませんでした。
     </p>
 </li>
-
-
 </ul>
 <!-- -------------------------------------------------------------------------------- -->
 <h2><a name="release3.4.6"></a>3.4.6 (tataraboshi) 2016/04/26</h2>