<!-- doc/src/sgml/release-3.6.sgml -->
<!-- See header comment in release.sgml about typical markup -->

<sect1 id="release-3-6-5">
  <title>リリース 3.6.5</title>

  <note>
    <title>リリース日</title>
    <simpara>2017-07-11</simpara>
  </note>

  <sect2>
    <title>不具合修正</title>

    <itemizedlist>

    <listitem>
    <!--
    2017-07-07 [33fd84c]
    -->
    <para>
    <ulink url="http://www.sraoss.jp/pipermail/pgpool-hackers/2017-June/002400.html">[pgpool-hackers: 2400]</ulink>で報告された、ログ出力中の不正なバイトを修正しました。(Muhammad Usama)
    </para>
    <para>
    ほとんどログメッセージの修正でした。
    </para>
    </listitem>

    <listitem>
    <!--
    2017-06-29 [85392b8]
    -->
    <para>
    <productname>PostgreSQL</productname>の<productname>MemoryManager API</productname>に関する最新の変更をインポートしました。(Muhammad Usama)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-06-24 [2ad4abd]
    -->
    <para>
    スプリットブレインが発生した場合、間違ったノードが MASTER になってしまう不具合を修正しました。
    <ulink url="http://www.pgpool.net/mantisbt/view.php?id=306">(bug 306)</ulink> (Muhammad Usama)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-06-21 [045e516]
    -->
    <para>
    <ulink url="http://www.sraoss.jp/pipermail/pgpool-hackers/2017-June/002390.html">[pgpool-hackers: 2390]</ulink> によって報告されたデーモンモードでの相対パスの問題を修正しました。(Muhammad Usama)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-06-19 [16db1f1]
    -->
    <para>
    <productname>PostgreSQL</productname> 10の変更に合わせて以下の関数名を修正しました。(Tatsuo Ishii)
    </para>

    <programlisting>
    pg_current_wal_location     -> pg_current_wal_lsn
    pg_last_wal_replay_location -> pg_last_wal_replay_lsn
    </programlisting>
    </listitem>

    <listitem>
    <!--
    2017-06-09 [d9b0b83]
    -->
    <para>
    ストリーミングレプリケーションと拡張プロトコルで発生するハングアップを修正しました。(Yugo Nagata)
    </para>
    <para>
    以下の例で再現できます。

    <programlisting>
    - <filename>pgpool.conf</filename>ですべての読み取りクエリをスタンバイに送信するように設定しています。
    - まず、トランザクションブロックで書き込みクエリを発行します。
    - トランザクションをコミットした後、<command>SELECT</command>クエリを発行します。
    - クエリを処理するときに、<command>Parse</command>の直後に<command>Describe（statement)</command>メッセージを送信します。
    </programlisting>
    </para>

    <para>
    <productname>JDBC</productname>を使用せず、<productname>pgproto</productname>を利用し以下のデータでこの問題を再現できます。
    <programlisting>

    'Q' "DROP TABLE IF EXISTS test_tbl"
    'Y'
    'Q' "CREATE TABLE test_tbl(i int)"
    'Y'
    'Q' "INSERT INTO test_tbl VALUES(1)"
    'Y'

    'P' "" "BEGIN" 0
    'B' "" "" 0 0 0
    'E' "" 0
    'S'
    'Y'

    'P' "" "INSERT INTO test_tbl VALUES(1)" 0
    'B' "" "" 0 0 0
    'E' "" 0
    'S'
    'Y'

    'P' "" "COMMIT" 0
    'B' "" "" 0 0 0
    'E' "" 0
    'S'
    'Y'

    'P' "S_1" "SELECT * FROM test_tbl" 0
    'D' 'S' "S_1"
    'B' "C_1" "S_1" 0 0 0
    'E' "C_1" 0
    'S'
    'Y'

    'X'
    </programlisting>

    </para>
    <para>
    <command>Bind</command>と<command>Execute</command>を適切なバックエンドに送信するように、<function>parse_before_bind()</function>は、トランザクション中にのみ呼び出されるように修正しました。
    </para>
    </listitem>

    <listitem>
    <!--
    2017-06-07 [204b08e]
    -->
    <para>
    <productname>erlang</productname>アプリケーションを使用する場合、<productname>Pgpool-II</productname> がハングする不具合を修正しました。(Tatsuo Ishii)
    </para>
    <para>
    <productname>Erlang</productname>クライアントは "Describe"メッセージの後に "Flush"を送信し、バックエンドは "Row description" を返します。しかし、<productname>Pgpool-II</productname>は、"Row description" メッセージを受信した後、進行中のクエリフラグをリセットすることを忘れてしまい、<productname>Pgpool-II</productname>はバックエンドからの応答を待っていました。これが<productname>erlang</productname>クライアントのハングアップの原因でした。

    </para>
    <para>
     <productname>Pgpool-II</productname>が "Row description" メッセージを受信した際に、クエリ処理中のフラグをリセットするように修正しました。"no data" メッセージと同じ扱いにする必要がありました。
    </para>
    <para>
    詳細は<ulink url="http://www.pgpool.net/pipermail/pgpool-general/2017-June/005613.html">[pgpo       ol-general: 5555]</ulink>を参照してください。
    </para>
    </listitem>

    <listitem>
    <!--
    2017-06-07 [e310167]
    -->
    <para>
    間違ったターゲットノードにバインドメッセージを送信するバグを修正しました。 <ulink url="http://www.pgpool.net/mantisbt/view.php?id=306">(bug 306)</ulink> (Tatsuo Ishii)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-05-31 [bc84c0b]
    -->
    <para>
    <productname>node.js</productname>を使用する場合に発生するクエリキャッシュのハングアップの問題を修正しました。(Tatsuo Ishii)
    </para>
    <para>
    詳細は<ulink url="http://www.pgpool.net/pipermail/pgpool-general/2017-May/005569.html">[pgpool-general: 5511]</ulink>を参照してください。
    </para>
    </listitem>

    <listitem>
    <!--
    2017-05-28 [6e6b022]
    -->
    <para>
    <productname>PostgreSQL</productname> 10のストリーミングレプリケーションの遅延チェックに関する変更に合わせて修正しました。(Tatsuo Ishii)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-05-27 [e4f37e4]
    -->
    <para>
    クエリキャッシュのメモリリークを修正しました。(Tatsuo Ishii)
    </para>
    <para>
    oidがないクエリ（<command>BEGIN</command>、<command>CHECKPOINT</command>、<command>VACUUM</command>など）の場合キャッシュバッファがクリアされるべきでしたが、されていませんでした。
    </para>
    </listitem>

    <listitem>
    <!--
    2017-05-23 [f1b8877]
    -->
    <para>
    特定の場合に発生する拡張クエリのハングアップを修正しました。(Tatsuo Ishii)
    </para>

    <para>
    <productname>erlang</productname> PostgreSQL APIは<command>Parse ('P')</command>、<command>Describe ('D')</command>、<command>Flush ('H')</command>、<command>Bind (B)</command>、<command>Execute('E')</command>を生成します。この"H"は<productname>JDBC</productname>にはありませんので、今まで問題が起こらなかったと思われます。その後、<productname>Pgpool-II</productname>は拡張クエリモードを削除し、データを読み取るバックエンドを見つけることができませんでした。したがって、<productname>Pgpool-II</productname>はバックエンドの一部にメッセージを送信していない可能性があるため、ハングアップを引き起こすすべてのバックエンドを読み取ろうとします。
    </para>
    <para>
    この問題を避けるために、<command>Flush</command>メッセージを受信後拡張クエリフラグを設定するように修正しました。
    </para>
    </listitem>

    <listitem>
    <!--
    2017-05-23 [512fbae]
    -->
    <para>
    <ulink url="http://www.pgpool.net/pipermail/pgpool-hackers/2017-May/002354.html">[pgpool-hackers: 2354]</ulink>によって報告された<command>pg_md5</command> のセグメンテーション違反を修正しました。(Muhammad Usama)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-05-31 [02ad737]
    2017-05-17 [6fe79be]
    -->
    <para>
    <function>white/black_memcache_table_list</function>のドキュメントを修正しました。(Tatsuo Ishii)
    </para>
    <para>
    実際の実装と異なっています。
    </para>
    <para>
    詳細は<ulink url="http://www.sraoss.jp/pipermail/pgpool-general/2017-May/005537.html">[pgpool-general：5479]</ulink>を参照してください。
    </para>
    </listitem>

    <listitem>
    <!--
    2017-05-10 [c901024]
    -->
    <para>
    滅多に発生しない<productname>Pgpool-II</productname>起動時のバグを修正しました。(Tatsuo Ishii)
    </para>
    <para>
    プライマリノードが見つかる前にフェールオーバーの要求が受け入れられる可能性がありました。
    これにより、<productname>Pgpool-II</productname>は奇妙な状態に陥ります。障害が発生したノードはプライマリノードの場合、
    プライマリノードは存在しないと判断していました。（既存のスタンバイが昇格し新しいプライマリノードになった場合でも）
    </para>
    <para>
    詳細は<ulink url="http://www.pgpool.net/pipermail/pgpool-hackers/2017-May/002321.html">[pgpool-hackers: 2321]</ulink>  をご参照下さい。
    </para>
    </listitem>

    </itemizedlist>

  </sect2>

</sect1>


<sect1 id="release-3-6-4">
  <title>リリース 3.6.4</title>

  <note>
    <title>リリース日</title>
    <simpara>2017-05-11</simpara>
  </note>

  <sect2>
    <title>不具合修正</title>

    <itemizedlist>

    <listitem>
    <!--
    2017-05-10 [c99e0fc]
    -->
    <para>
    Watchdog のフェイルオーバーリクエスト処理の不具合を修正しました。(Muhammad Usama)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-05-10 [ee0a415]
    -->
    <para>
    Watchdog クラスタのメンバーの基準を改善しました。(Muhammad Usama)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-05-10 [54aa688]
    -->
    <para>
    ロードバランスに関するドキュメントを改善しました。(Tatsuo Ishii)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-05-08 [eb83f0b]
    -->
    <para>
    ノード 0 がフェイルオーバーする場合のレグレッションテストを追加しました。(Tatsuo Ishii)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-05-04 [2b0edb1]
    -->
    <para>
    <ulink url="http://www.sraoss.jp/pipermail/pgpool-hackers/2017-May/002312.html">[pgpool-hackers：2312]</ulink> で報告された
<productname>Pgpool-II</productname>ノード 0 がフェイルオーバーするときに発生するセグメンテーション違反を修正しました。(Tatsuo Ishii)
    </para>
    </listitem>

    </itemizedlist>

  </sect2>

</sect1>


<sect1 id="release-3-6-3">
  <title>リリース 3.6.3</title>

  <note>
    <title>リリース日</title>
    <simpara>2017-04-28</simpara>
  </note>

  <sect2>
    <title>不具合修正</title>

    <itemizedlist>

    <listitem>
    <!--
    2017-04-18 [b8eb551]
    -->
    <para>
     memcachedが使用されているときに発生する"show pool_cache"のセグメンテーション違反を修正しました。
     <ulink url="http://www.pgpool.net/mantisbt/view.php?id=301">(Bug 301)</ulink> (Tatsuo Ishii)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-04-14 [bedb509]
    -->
    <para>
     いくつかのソースコードの警告を修正しました。(Muhammad Usama)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-04-14 [8b25ca3]
    -->
    <para>
        いくつかのコンパイラの警告を修正しました。(Muhammad Usama)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-04-14 [50fb9a4]
    -->
    <para>
     pool_config_vatiable.cから「定義されたが未使用の関数」という警告を削除しました。(Muhammad Usama)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-04-14 [9007558]
    -->
    <para>
     古いdebug_level設定パラメーターの参照を削除しました。(Muhammad Usama)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-04-12 [7105243]
    -->
    <para>
     Watchdogのソースコードのミスを修正し、いくつかのdebugメッセージを追加しました。(Muhammad Usama)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-04-12 [f5f42be]
    -->
    <para>
     pool_hba.confファイルをリロード時に発生するエラーを修正しました。<ulink url="http://www.pgpool.net/mantisbt/view.php?id=299">(Bug 299)</ulink> (Muhammad Usama)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-04-12 [32b7c6d]
    2017-04-11 [d47add6]
    2017-04-11 [02a6f45]
    -->
    <para>
     英語/日本語のドキュメントにpgpool_adm extensionに関する情報を追加しました。(Tatsuo Ishii)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-04-11 [a6cc0c9]
    -->
    <para>
     ドキュメントを改善しました。(Tatsuo Ishii)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-04-11 [2997b3a]
    -->
    <para>
     watchdog 使用時に Pgpool-II 間でバックエンドの状態が一致しない不具合を修正しました。
     <ulink url="http://www.pgpool.net/mantisbt/view.php?id=289">(Bug 289)</ulink> (Muhammad Usama)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-03-30 [be9d634]
    -->
    <para>
     Watchdogによるスプリットブレインシナリオの処理を強化しました。(Muhammad Usama)
    </para>
    <para>

     watchdogクラスタを使用しmaster/coordinatorノードの再選出が呼び出されていました。その結果、すべてのノードがウォッチドッグネットワークに再結合する必要がありました。これはwatchdogクラスタ全体の再起動と本質的に同じでした。
    </para>
    <para>
     今回の修正では、master/coordinatorノードの候補は、次の基準で選択されるようになりました。
    </para>
    <para>
    (1) 2つのウォッチドッグノードがクラスタマスターであると主張している場合、エスカレーションを実行したマスターノードはマスター状態を保持し、他のノードはステップダウンするように要求されます。
    </para>
    <para>
    (2) 競合がノードのエスカレーション状況によって解決できない場合、クォーラムを保持するノードはマスター/コーディネータのままです。
    </para>
    <para>
    (3) 両方の候補のクォーラムステータスが同じ場合、接続されたアライブノードの数が多いノードが優先されます。
    </para>
    <para>
    (4) 最後に、上記3つでマスターノードを選出できなかった場合、古いマスター(長期間コーディネーターステータスを持つノード) はマスターのままです。
    </para>
    </listitem>

    <listitem>
    <!--
    2017-03-21 [deaa822]
    -->
    <para>
     複数の並行コマンドを処理するためにwatchdog内部コマンドのメカニズムを強化しました。(Muhammad Usama)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-04-07 [e989242]
    -->
    <para>
     コンパイラ時の警告を修正しました。(Tatsuo Ishii)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-04-06 [d87f93d]
    -->
    <para>
     リグレッションの失敗を防ぐために、サポートされていないJavaメソッドを新しいJDBCドライバでコメントアウトしました。(Tatsu Ishii)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-04-05 [e5541d7]
    -->
    <para>
     <function>parse_before_bind() </function> のログメッセージを debug1 にダウングレードしました。(Tatsuo Ishii)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-04-04 [aa4e308]
    2017-04-04 [24d9770]
    2017-04-03 [7d8482a]
    -->
    <para>
     coverity警告を修正しました。(Muhammad Usama, Tatsuo Ishii)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-03-31 [c4f816b]
    -->
    <para>
     <ulink url="http://www.sraoss.jp/pipermail/pgpool-general/2017-March/005454.html">[pgpool-general: 5396]</ulink>
        pam ldapが失敗する不具合を修正しました。(Muhammad Usama)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-03-31 [6899b7d]
    -->
    <para>
     拡張クエリモードでSQL型コマンドが使用できないことをドキュメントに追加しました。(Tatsuo Ishii)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-03-31 [9cd2f8a]
    -->
    <para>
     <command>SHOW</command>コマンドを読み込みクエリの一つとして認識するようにしました。(Tatsuo Ishii)
    </para>
    <para>
     ストリーミングレプリケーションモードでは、<command>SHOW</command>が発行されるとその後のSELECTは明示的なトランザクションでプライマリノードに送信されていました。この制限は不適切でした。また、parseコマンドがエラーを返すときに発生するハングアップを修正しました。
    </para>
    </listitem>

    <listitem>
    <!--
    2017-03-30 [9aaec32]
    -->
    <para>
     コミットadcb636によって引き起こされたメモリリークの問題を修正しました。(Tatsuo Ishii)
    </para>
    <para>
     Commit adcb636では"pending message queue"を導入しました。メッセージを受信すると、情報がキューに追加され、オブジェクトのコピーが同時に作成されますが、オブジェクトを解放するのを忘れてしまいました。
     </para>
     <para>
     今回の修正では、新しい関数<function>pool_pending_message_free_pending_message()</function>を作成し、<function>pool_pending_message_add()</function>、<function>pool_pending_message_get()</function>および<function>pool_pending_message_pull_out()</function>の後に呼び出すように修正しました。
    </para>
    </listitem>

    <listitem>
    <!--
    2017-03-29 [18f9501]
    -->
    <para>
     ストリーミングレプリケーションモードで「kind mismatch」(またはそれに関連する)エラーが修正されました。
     <ulink url="http://www.pgpool.net/mantisbt/view.php?id=271">(Bug 271)</ulink> (Tatsuo Ishii)
    </para>
    <para>
     このエラー原因はデータベースノードがPgpool-IIに送る応答の予測が誤っていたことです。以前使用した「sync map」の実装は弱く、予測に失敗することがありました。今回の修正では、送信されたすべてのメッセージをバックエンドに記録する"pending message queue"を導入しました。このキューの要素には、メッセージのタイプ(parse/bind/execute/describe/close/sync)、メッセージが送信されたデータベースノードの情報などが格納されます。これは単純なFIFOキューです。バックエンドからメッセージが到着すると、"pending message queue"の先頭を見れば、受信したメッセージの種類やデータベースノードを確実に予測できます。 メッセージを受信した後、この要素はキューから削除されます。
    </para>
    <para>
    一連のパッチをテストしてくれたSergey Kimさんに感謝します。
    </para>
    <para>
    詳細は <ulink url="http://www.pgpool.net/mantisbt/view.php?id=271">Bug 271</ulink>、
    <ulink url="http://www.sraoss.jp/pipermail/pgpool-hackers/2017-February/002043.html">[pgpool-hackers: 2043]</ulink> と
    <ulink url="http://www.sraoss.jp/pipermail/pgpool-hackers/2017-March/002140.html">[pgpool-hackers: 2140]</ulink> をご参照下さい。
    </para>
    </listitem>

    <listitem>
    <!--
    2017-03-24 [c2a0cc5]
    -->
    <para>
    [Service] が Type=forking に設定されている場合、Pgpool-II 3.6.2 が systemd によって強制終了されていた不具合を修正しました。
    <ulink url="http://www.pgpool.net/mantisbt/view.php?id=296">(Bug 296)</ulink> (Muhammad Usama)
    </para>
    </listitem>
    </itemizedlist>

  </sect2>

</sect1>

<sect1 id="release-3-6-2">
  <title>リリース 3.6.2</title>

  <note>
    <title>リリース日</title>
    <simpara>2017-03-17</simpara>
  </note>

  <sect2>
    <title>不具合修正</title>

    <itemizedlist>

    <listitem>
    <!--
    2017-03-17 [ba1bcc3]
    -->
    <para>
    pgpool.serviceファイルに"Wants=network.target"を追加しました。
    (<ulink url="http://www.pgpool.net/mantisbt/view.php?id=294">bug 294</ulink>) (Bo Peng)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-03-09 [1ddb7f1]
    -->
    <para>
 <link linkend="PCP-PROMOTE-NODE">pcp_promote_node</link>を使ってノード0の昇格に失敗する不具合を修正しました。(Yugo Nagata)
    </para>
    <para>
失敗したときのエラーメッセージは以下のとおりです。
    </para>

    <programlisting>
  FATAL: invalid pgpool mode for process recovery request
  DETAIL: specified node is already primary node, can't promote node id 0
    </programlisting>

    <para>
ストリーミングレプリケーションモードでは、<productname>Pgpool-II</productname>がプライマリノードを何らかの理由で「スタンバイ」とみなしていました。たとえば、<productname>Pgpool-II</productname>が起動中で、pg_ctl promoteを手動で実行したとき、<productname>Pgpool-II</productname>はプライマリノードが存在しないと認識します。
    </para>

    <para>
この状態の不一致は、pcp_promote_nodeコマンドによって直されるはずですが、昇格させたいノードがマスターノード（最初のアライブノード）である場合、上記のように失敗しました。
失敗した理由は次のとおりです。ステータスを変更する前に、pcp_promote_nodeコマンドがPRIMARY_NODE_IDのノードIDと比較することによって、指定されたノードが既にプライマリであるかどうかをチェックします。ただし、プライマリが存在しない場合<productname>Pgpool-II</productname>のビューでは、PRIMARY_NODE_IDが0に設定されます。これはMASTER_NODE_IDと同じです。したがって、マスタノードを昇格させるように指定する場合、pcp_promote_nodeはこのノードが既にプライマリであるとのエラーを返して終了しました。
    </para>

    <para>
これを修正するには、pcp_promote_nodeは指定したノードがプライマリーノードであるかどうかをチェックするとき、PRIMARY_NODE_IDではなくREAL_PRIMARY_NODE_IDを使うように修正しました。REAL_PRIMARY_NODE_IDはプライマリが存在しない場合、-1に設定されます。
    </para>
    </listitem>

    <listitem>
    <!--
    2017-02-28 [b1060bd]
    2017-01-10 [1e4e494]
    2017-02-09 [767eff3]
    -->
    <para>
<productname>Pgpool-II</productname>のドキュメントを修正しました。(Tatsuo Ishii, Bo Peng)
    </para>
    <para>

    </para>
    </listitem>

    <listitem>
    <!--
    2017-02-23 [2b7217e]
    -->
    <para>
<productname>Pgpool-II</productname>がVIPを解除した後にpingテストを続けている不具合を修正しました。(Muhammad Usama)
    </para>
    <para>
<ulink url="http://www.pgpool.net/pipermail/pgpool-hackers/2016-June/001611.html">[pgpool-hackers: 1611]</ulink> により報告されました。
    </para>
    </listitem>

    <listitem>
    <!--
    2017-02-23 [7ed400b]
    -->
    <para>
特定の場合に、<productname>Pgpool-II</productname>が終了したときに共有メモリセグメントを解放しない不具合を修正しました。(<ulink url="http://www.pgpool.net/mantisbt/view.php?id=272">bug 272</ulink>) (Tatsuo Ishii)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-02-14 [c1cd41c]
    -->
    <para>
pg_terminate_backend関数を実行するときに発生する不具合を修正しました。(Muhammad Usama)
    </para>
    <para>
<ulink url="http://www.pgpool.net/pipermail/pgpool-general/2017-February/005373.html">[pgpool-general: 5315]</ulink>により報告されました。
    </para>
    </listitem>

    <listitem>
    <!--
    2017-02-06 [8fa731a]
    -->
    <para>
ExecStopとExecReloadコマンドをsystemdサービス設定ファイルに追加しました。(Muhammad Usama)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-01-30 [6362ba6]
    -->
    <para>
<link linkend="PCP-ATTACH-NODE">pcp_attach_node</link>を実行するときのセグメンテーション違反を修正しました。(<ulink url="http://www.pgpool.net/mantisbt/view.php?id=281">bug 281</ulink>)(Muhammad Usama)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-01-30 [fb58877]
    -->
    <para>
ストリーミングレプリケーションモードでロードバランスのバグを修正しました。(Tatsuo Ishii)
    </para>
    <para>
明示的なトランザクションでは、書き込みクエリが送信されるまで、SELECTはロードバランスされます。書込みクエリが送信された後、SELECTがプライマリノードに送信されます。しかし、syncメッセージが送信される前にSELECTが送信された場合、これは正しく動作しませんでした。
    </para>
    <para>
書き込みクエリが実行されると書き込みクエリの処理が行われるように修正しました。
    </para>
    </listitem>

    <listitem>
    <!--
    2017-01-30 [8371649]
    -->
    <para>
ストリーミングレプリケーションモードでのkind mismatchエラーを修正しました。(Tatsuo Ishii)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-01-27 [4f98bf0]
    -->
    <para>
closeメッセージの後に<function>do_query()</function>がハングする問題を修正しました。(Tatsuo Ishii)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-01-27 [7512482]
    -->
    <para>
<function>wd_get_cmd</function>関数のバッファオーバーフローを修正しました。(<ulink url="http://www.pgpool.net/mantisbt/view.php?id=280">bug 280</ulink>)(Muhammad Usama)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-01-19 [839a709]
    -->
    <para>
watchdogプロセスを再起動する時の不具合を修正しました。(Muhammad Usama)
    </para>
    <para>
watchdogプロセスが何らかの問題（例えばセグメンテーションフォルト）によって異常終了した場合、新たに生成されたwatchdogプロセスの起動が失敗し、"bind on ... failed with reason: Address already in use"とのエラーを返しました。
    </para>

    <para>
理由は、異常終了したwatchdogプロセスはIPCに使用するソケットをクリーンアップする時間がなかったからです。
    </para>

    <para>
この不具合を修正するために、Pgpoolのメインプロセスは、watchdogプロセスが異常終了したときに共有メモリにフラグを設定するように修正しました。
watchdogプロセスが再起動されるとき、フラグがセットされたら、ソケットファイルをクリーンアップするようにしました。
    </para>
    </listitem>

    <listitem>
    <!--
    2017-01-19 [779d029]
    -->
    <para>
特定の条件下で、ストリーミングレプリケーションモードでクエリキャッシュが有効な場合、SELECTがハングアップする不具合を修正しました。(Tatsuo Ishii)
    </para>
    <para>
    <ulink url="http://www.pgpool.net/pipermail/pgpool-general-jp/2017-January/001440.html">pgpool-general-jp:1441</ulink>により報告されました。
    </para>
    </listitem>

    <listitem>
    <!--
    2017-01-11 [29b61eb]
    -->
    <para>
シグナルハンドラがelog/ereportを呼び出さないように修正しました。(Tatsuo Ishii)
    </para>
    <para>
詳しくは<ulink url="http://www.pgpool.net/pipermail/pgpool-hackers/2016-December/001950.html">[pgpool-hackers: 1950]</ulink>をご参照ください。
    </para>
    </listitem>

    <listitem>
    <!--
    2017-01-10 [39d24e7]
    -->
    <para>
FreeBSDでlisten_addresses = '*'の場合、INETドメインソケットが作成できない不具合を修正しました。(<ulink url="http://www.pgpool.net/mantisbt/view.php?id=202">bug 202</ulink>)(Bo Peng)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-01-04 [8598d5a]
    -->
    <para>
特定に場合にwatchdogがデエスカレーションに失敗する不具合を修正しました。(<ulink url="http://www.pgpool.net/mantisbt/view.php?id=249">bug 249</ulink>)(Muhammad Usama)
    </para>

    <para>
WNOHANGオプションなしで<function>waitpid()</function>システムコールを使用するように修正しました。
    </para>
    </listitem>

    <listitem>
    <!--
    2017-01-04 [bd92a11]
    -->
    <para>
authentication_timeoutが有効な場合、connection_life_timeが正しく処理されない不具合を修正しました。(Yugo Nagata)
    </para>
    </listitem>

    <listitem>
    <!--
    2016-12-28 [afebadf]
    -->
    <para>
クライアント接続直後に発生しうる認証タイムアウトを修正しました。(Yugo Nagata)
    </para>
    </listitem>

    </itemizedlist>

  </sect2>

</sect1>


<sect1 id="release-3-6-1">
<!--
  <title>release 3.6.1</title>
  -->
  <title>リリース 3.6.1</title>

  <note>
    <title>リリース日</title>
    <simpara>2016-12-26</simpara>
  </note>

  <sect2>
  <!--
    <title>Bug fixes</title>
    -->
    <title>不具合修正</title>

    <itemizedlist>

      <listitem>
	<!--
	    2016-12-23 [4124e5e]
	  -->
	<para>
    <!--
      Tightening up the watchdog security. (Muhammad Usama)
    -->
watchdog のセキュリティを強化しました。(Muhammad Usama)
    </para>

    <para>
    <!--
      Now wd_authkey uses the HMAC SHA-256 hashing.
    -->
wd_authkeyは、HMAC SHA-256ハッシングを使用するようになりました。
	</para>
      </listitem>

      <listitem>
	<!--
	    2016-12-22 [f8a157a]
	  -->
	<para>
	<!--
	  Add pgpool_adm extension. (Bo Peng)
    -->
<productname>Pgpool-II</productname>のRPM にpgpool_adm extension が含まれるように修正しました。(Bo Peng)
	</para>
      </listitem>

      <listitem>
	<!--
	    2016-12-20 [888ac16]
	  -->
	<para>
    <!--
	  Fix occasional segfault when query cache is enabled. (Tatsuo Ishii)
    -->
クエリキャッシュが有効になっている場合に、時々発生しうるセグメンテーション違反を修正しました。(bug 263) (Tatsuo Ishii)
	</para>
      </listitem>

      <listitem>
	<!--
	    2016-12-20 [9274f82]
	  -->
	<para>
    <!--
	  Fix packet kind does not match error in extended protocol per bug 231. (Tatsuo Ishii)
    -->
拡張プロトコルにおいて発生しうるkind mismatchエラーを修正しました。(bug 231) (Tatsuo Ishii)
	</para>
	<para>
    <!--
	  According to the bug231, the bug seem to bite you if all of
	  following conditions are met:
      -->
bug 231によると、以下の条件がすべて満たされていると、このバグが発生する可能性がありました。
	</para>
	<itemizedlist>
	  <listitem>
	    <para>
        <!--
	      Streaming replication mode
          -->
ストリーミングレプリケーションモード
	    </para>
	  </listitem>
	  <listitem>
	    <para>
        <!--
	      Load balance node is not node 0
          -->
 ロードバランスノードがnode 0ではない
	    </para>
	  </listitem>
	  <listitem>
	    <para>
        <!--
	      Extended protocol is used
          -->
拡張プロトコルを使用している
	      </para>
	  </listitem>
	  <listitem>
	    <para>
        <!--
	      SELECT is executed, the statement is closed, then a
	      transaction command is executed
          -->
SELECTが実行され、ステートメントがクローズされた後、トランザクションコマンドが実行されている
	    </para>
	  </listitem>
	</itemizedlist>
	<para>
    <!--
	The sequence of how the problem bites is:
    -->
問題の発生順序:
	<orderedlist>
	  <listitem>
	    <para>
        <!--
	      SELECT executes on statement S1 on the load balance node 1
          -->
ロードバランスノード1でステートメントS1のSELECTが実行されます。
	    </para>
	  </listitem>
	  <listitem>
	    <para>
        <!--
	      Frontend send Close statement
          -->
フロントエンドがクローズステートメントを送ります。
	    </para>
	  </listitem>
	  <listitem>
	    <para>
        <!--
	      Pgool-II forward it to backend 1
          -->
Pgpool-IIはそれをバックエンド1に転送します。
	    </para>
	  </listitem>
	  <listitem>
	    <para>
        <!--
	      Frontend sends Parse, Bind, Execute of COMMIT
          -->
フロントエンドは、COMMITのParse、Bind、Executeを送信します。
	    </para>
	  </listitem>
	  <listitem>
	    <para>
        <!--
	      Pgool-II forward it to backend 0 & 1
          -->
Pgpool-IIはそれをバックエンド0と1に転送します。
	    </para>
	  </listitem>
	  <listitem>
	    <para>
        <!--
	      Frontend sends sync message
          -->
フロントエンドが同期メッセージを送信します。
	    </para>
	  </listitem>
	  <listitem>
	    <para>
        <!--
	      Pgool-II forward it to backend 0 & 1
          -->
Pgpool-IIはそれをバックエンド0と1に転送します。
	    </para>
	  </listitem>
	  <listitem>
	    <para>
        <!--
	      Backend 0 replies back Parse complete ("1"), while
	      backend 1 replies back close complete ("3") because of
	      #3.
          -->
バックエンド0はParse complete（ "1"）を返しますが、バックエンド1は＃3によりclose complete（ "3"）を返します。
	    </para>
	  </listitem>
	  <listitem>
	    <para>
        <!--
	      Kind mismatch occurs
          -->
Kind mismatch が発生します。
	    </para>
	  </listitem>
	</orderedlist>

	</para>
	<para>
    <!--
	  The solution is, in #3, let Pgpool-II wait for response from backend
	  1, but do not read the response message. Later on Pgpool-II's state
	  machine will read the response from it before the sync message is sent
	  in #6. With this, backend 1 will reply back "1" in #8, and the kind
	  mismatch error does not occur.
      -->
解決策は、＃3では、Pgpool-IIがバックエンド1からの応答を待つようにしますが、応答メッセージは読み取らないようにします。 その後、Pgpool-IIの状態マシンは、＃6で同期メッセージが送信される前に、その応答を読み込みます。 これによりバックエンド1は＃8で "1"を返信し、kind mismatchエラーは発生しなくなります。
	</para>
	<para>
    <!--
	  Also, fix not calling pool_set_doing_extended_query_message() when
	  receives Close message.  (I don't know why it was missed).
      -->
また、Closeメッセージを受け取ったときにpool_set_doing_extended_query_message（）が呼び出されない不具合を修正しました。
	</para>
	<para>
    <!--
	  New regression test "067.bug231" was added.
      -->
新しいリグレッションテスト "067.bug231"を追加しました。
	</para>
      </listitem>

      <listitem>
	<!--
	    2016-12-06 [336e932]
	  -->
	<para>
    <!--
	  Fix a race condition in a signal handler per bug 265. (Tatsuo Ishii)
    -->
シグナルハンドラでの競合状態を修正しました。(bug 265) (Tatsuo Ishii)
	</para>
	<para>
    <!--
	  In child.c there's signal handler which calls elog. Since the signal
	  handler is not blocked against other signals while processing, deadlock
	  could occur in the system calls in the pgpool shutdown sequence. To
	  fix the problem, now the signal handler is blocked by using
	  POOL_SETMASK.
      -->
child.cには、elogを呼び出すシグナルハンドラがあります。 シグナルハンドラは処理中に他のシグナルに対してブロックされないため、pgpoolのシャットダウンシーケンスでシステムコールにデッドロックが発生する可能性がありました。 この問題を解決するために、シグナルハンドラはPOOL_SETMASKを使用してブロックされるように修正されました。
	</para>
	<para>
    <!--
	  Ideally we should avoid calling elog in signal handlers though.
      -->
理想的にはシグナルハンドラでelogを呼び出すことを避けるべきです。
	</para>
      </listitem>

      <listitem>
	<!--
	    2016-11-24 [cc452ad]
	  -->
	<para>
    <!--
	  Fix wrong minimum configuration value for client_idle_limit_in_recovery. (Tatsuo Ishii)
    -->
誤ったclient_idle_limit_in_recoveryの最小設定値を修正しました。(bug 264) (Tatsuo Ishii)
	</para>
      </listitem>

      <listitem>
	<!--
	    2016-11-22 [94d9378]
	  -->
	<para>
    <!--
	  Allow to execute "make xslthtml" under doc.ja. (Tatsuo Ishii)
      -->
doc.jaの下で "make xslthtml"を実行できるように修正しました。(Tatsuo Ishii)
	</para>
	<para>

	</para>
      </listitem>

    </itemizedlist>

  </sect2>

</sect1>




<sect1 id="release-3-6">
<!--
  <title>Release 3.6</title>
  -->
  <title>リリース 3.6</title>

  <note>
    <title>Release Date</title>
    <simpara>2016-11-21</simpara>
  </note>

  <sect2>
  <!--
    <title>Overview</title>
    -->
    <title>概要</title>

    <para>
    <!--
      Major enhancements in <productname>Pgpool-II</productname> 3.6 include:
      -->
      <productname>Pgpool-II</productname> 3.6 の主な改善点は以下のとおりです。
    </para>

    <!-- Items in this list summarize one or more items below -->

    <itemizedlist>

      <listitem>
    <!--
	  Improve the behavior of fail-over. In the steaming
	  replication mode, client sessions will not be disconnected
	  when a fail-over occurs any more if the session does not use
	  the failed standby server. If the primary server goes down,
	  still all sessions will be disconnected. Also it is possible
	  to connect to <productname>Pgpool-II</productname> even if
	  it is doing health checking retries. Before all attempt of
	  connecting to <productname>Pgpool-II</productname> failed
	  while doing health checking retries.
      -->
      <para>
      fail-over の挙動が改善されました。
      </para>
      <para>
      Streaming Replicationモードで、フェイルオーバーが発生した時に、ダウンしたスタンバイサーバを利用しなければ、クライアントセッションが切断されなくなります。
      プライマリサーバがダウンした場合、すべてのセッションが切断されます。
      また、ヘルスチェックのリトライの最中でも <productname>Pgpool-II</productname>に接続することが可能です。
<productname>Pgpool-II</productname>への接続リトライする最大回数までヘルスチェックのリトライが続きます。
	    </para>
      </listitem>

      <listitem>
	<para>
    <!--
	  New PGPOOL SET command has been introduced. Certain
	  configuration parameters now can be changed on the fly in a
	  session.
      -->
      新しいコマンド <link linkend="SQL-PGPOOL-SET">PGPOOL SET</link> が追加されました。
      このコマンドを使用することで、現行セッション内で設定パラメータを変更することができるようになりました。
	</para>
      </listitem>

      <listitem>
	<para>
    <!--
	  Watchdog is significantly enhanced. It becomes more reliable
	  than previous releases.
      -->
Watchdogが大幅に改善されました。
以前のバージョンよりも信頼性が向上しています。
	</para>
      </listitem>

      <listitem>
	<para>
    <!--
	  Handling of extended query protocol (e.g. used by Java
	  applications) in streaming replication mode speeds up if
	  many rows are returned in a result set.
      -->
問合せから大量の行が返される場合、ストリーミングレプリケーション時の拡張問い合わせプロトコル（例えば、Java アプリケーションで使用される場合）の処理速度が改善されました。
	</para>
      </listitem>

      <listitem>
	<para>
    <!--
	  Import parser of PostgreSQL 9.6.
      -->
      PostgreSQL 9.6 のパーサを取り込みました。
	</para>
      </listitem>

      <listitem>
	<para>
    <!--
	  In some cases pg_terminate_backend() now does not trigger a
	  fail-over.
      -->
特定の場合に<function>pg_terminate_backend()</function>がフェイルオーバを起こさないようになりました。
	</para>
      </listitem>

      <listitem>
	<para>
    <!--
	  Change documentation format from raw HTML to SGML.
      -->
      ドキュメントの形式が HTML から SGML に変更されました。
	</para>
      </listitem>

    </itemizedlist>

    <para>
    <!--
      The above items are explained in more detail in the sections below.
      -->
      上記の項目は以下のセクションで詳しく説明します。
    </para>

  </sect2>

  <sect2>
  <!--
    <title>Major Enhancements</title>
    -->
    <title>主な改善点</title>

    <itemizedlist>

      <listitem>
	<!--
	    2016-04-17 [259cdf9] Do not restart child process if certain conditions met
	    2016-04-21 [9cc243a] Minimize the chance of session disconnection while failover
	    2016-05-05 [0d66032] Allow to access to pgpool while doing health checking
	  -->
	<para>
    <!--
	  Improve the behavior of fail-over. (Tatsuo Ishii)
    -->
      fail-over の挙動が改善されました。(Tatsuo Ishii)
	</para>
	<para>
    <!--
	  In the steaming replication mode, client sessions will not
	  be disconnected when a fail-over occurs any more if the
	  session does not use the failed standby server. If the
	  primary server goes down, still all sessions will be
	  disconnected. Health check timeout case will also cause the
	  full session disconnection. Other health check error,
	  including retry over case does not trigger full session
	  disconnection.
      -->
      Streaming Replication モードで、フェイルオーバーが発生した時に、ダウンしたスタンバイサーバがそのセッションで使用されていなければ、クライアントセッションが切断されなくなりました。
プライマリサーバがダウンした場合は、すべてのセッションが切断されます。
ヘルスチェックタイムアウトした場合でも、すべてのセッションが切断されます。
リトライ最大回数を超えた場合を含めて、他のヘルスチェックエラーではすべてのセッションは切断されません。
	</para>

	<para>
    <!--
	  For user's convenience, "show pool_nodes" command shows the
	  session local load balance node info since this is important
	  for users in case of fail-over. If the load balance node is
	  not the failed node, the session will not be affected by
	  fail-over.
      -->
fail-over が発生する場合にローカル負荷分散ノードの情報が重要なので、<command>show pool_nodes</command> コマンドで、ローカル負荷分散ノードの情報が利用者の便宜のために表示されるようになりました。
負荷分散ノードがダウンしたノードではない場合、フェイルオーバーによる影響はありません。
	</para>

	<para>
    <!--
	  Also now it is possible to connect
	  to <productname>Pgpool-II</productname> even if it is doing
	  health checking retries. Before all attempt of connecting
	  to <productname>Pgpool-II</productname> failed while doing
	  health checking retries.  Before any attempt to connect to
	  <productname>Pgpool-II</productname> fails if it is doing a
	  health check against failed node even if
	  <xref linkend="guc-fail-over-on-backend-error"> is off
	  because <productname>Pgpool-II</productname> child first
	  tries to connect to all backend including the failed one and
	  exits if it fails to connect to a backend (of course it
	  fails). This is a temporary situation and will be resolved
	  once pgpool executes fail-over. However if the health check
	  is retrying, the temporary situation keeps longer depending
	  on the setting
	  of <xref linkend="guc-health-check-max-retries"> and
	  <xref linkend="guc-health-check-retry-delay">. This is not
	  good. Attached patch tries to mitigate the problem:
      -->
      また、ヘルスチェックのリトライの最中でも <productname>Pgpool-II</productname> に接続できるようになりました。
以前は、<xref linkend="guc-fail-over-on-backend-error">がオフの場合でも<productname>Pgpool-II</productname>への接続は、ヘルスチェックのリトライをしている間はすべて失敗していました。
これは、<productname>Pgpool-II</productname>の子プロセスがまず失敗したバックエンドを含めてすべてのバックエンドへの接続を試み、失敗した場合終了するためです（これはもちろん失敗します）。
これは一時的な状況であり、<productname>Pgpool-II</productname>がフェールオーバーを行えば解決します。
しかし、ヘルスチェックの再試行が行っている場合は、この一時的な状況は
      <xref linkend="guc-health-check-max-retries">と<xref linkend="guc-health-check-retry-delay">の設定次第で長時間続きます。
この状況は良くないので、以下のように修正しました。

	</para>
	<para>
    <!--
	  When an attempt to connect to backend fails, give up
	  connecting to the failed node and skip to other node, rather
	  than exiting the process if operating in streaming
	  replication mode and the node is not primary node.
      -->
ストリーミングレプリケーションモードにおいて、バックエンドへの接続に失敗したら、そのダウンしたノードがプライマリではなければ、このバックエンドへの接続をあきらめて、他のノードへの接続を試みます。
	</para>
	<para>
    <!--
	  Mark the local status of the failed node to "down".  This
	  will let the primary node be selected as a load balance node
	  and every queries will be sent to the primary node. If
	  there's other healthy standby nodes, one of them will be
	  chosen as the load balance node.
      -->
ローカルノードのステータスを"down"と記録します。
これによりプライマリーノードがロードバランスノードとして選択され、すべてのクエリがプライマリーノードへ転送されます。
他にスタンバイのノードが存在する場合、その中からロードバランスノードが選択されます。
	</para>
	<para>
    <!--
	  After the session is over, the child process will suicide to
	  not retain the local status.
      -->
セッションが終了した後、ローカルの状態を保持しないように子プロセスは自殺します。
	</para>
      </listitem>

      <listitem>
	<!--
	    2016-05-22 [b9955ce] Adding new PGPOOL SET and PGPOOL RESET commands.
	    2016-05-11 [25dc79e] Adding new SHOW command for pgpool-II configuration parameters.
	  -->
	<para>
    <!--
	  Add <link linkend="SQL-PGPOOL-SHOW">PGPOOL
	  SHOW</link>, <link linkend="SQL-PGPOOL-SET">PGPOOL
	  SET</link> and
	  <link linkend="SQL-PGPOOL-RESET">PGPOOL RESET</link>
	  commands. (Muhammad Usama)
    -->
	  <link linkend="SQL-PGPOOL-SHOW">PGPOOL
	  SHOW</link>, <link linkend="SQL-PGPOOL-SET">PGPOOL
	  SET</link> と
	  <link linkend="SQL-PGPOOL-RESET">PGPOOL RESET</link>
	  コマンドが追加されました。 (Muhammad Usama)
	</para>
	<para>
    <!--
	  These are similar to the PostgreSQL's SET and SHOW commands
	  for GUC variables, adding the functionality
	  in <productname>Pgpool-II</productname> to set and reset the
	  value of config parameters for the current session, and for
	  that it adds a new syntax
	  in <productname>Pgpool-II</productname> which is similar to
	  PostgreSQL's SET and RESET variable syntax with an addition
	  of <literal>PGPOOL</literal> keyword at the start.
      -->
これは<productname>Pgpool-II</productname>に現在のセッションの設定パラメータを設定またはリセットする機能を追加するという点で<productname>PostgreSQL</productname>のSET、SHOW、RESETコマンドと似ていますが、PostgreSQLのSET、RESETコマンドコマンドと区別するために、<literal>PGPOOL</literal>というキーワードが前に挿入してあります。
	</para>
	<para>
    <!--
	  Currently supported configuration parameters by PGPOOL
	  SHOW/SET/RESET are: <xref linkend="guc-log-statement">,
      -->
      現在 PGPOOL SHOW/SET/RESET に対応している設定パラメータは以下です。
	  <xref linkend="guc-log-per-node-statement">, <xref linkend="guc-check-temp-table">,
	  <xref linkend="guc-check-unlogged-table">, <xref linkend="guc-allow-sql-comments">,
	  <xref linkend="guc-client-idle-limit">, <xref linkend="guc-log-error-verbosity">,
	  <xref linkend="guc-client-min-messages">, <xref linkend="guc-log-min-messages">,
	  <xref linkend="guc-client-idle-limit-in-recovery">.
	</para>
      </listitem>

      <listitem>
	<!--
	    2016-08-02 [bda946e] Fix for 218: Inconsistent status of
	    Postgresql nodes in pgPool instances after
	    restart. Watchdog not syncing status.
	  -->
	<para>
    <!--
	  Sync inconsitent status
	  of <productname>PostgreSQL</productname> nodes
	  in <productname>Pgpool-II</productname> instances after
	  restart. (Muhammad Usama)
    -->
<productname>Pgpool-II</productname>再起動後、<productname>PostgreSQL</productname>ノードの状態の不整合がある場合、これを同期するようにしました。(bug 218) (Muhammad Usama)
	</para>
	<para>
    <!--
    Watchdog does not synchronize status.
    -->
    watchdog がバックエンドノードを同期させなかったのが原因でした。
	</para>
      </listitem>

      <listitem>
	<!--
	    2016-09-06 [c0eb0ee] Enhance performance of SELECT when lots of rows involved.
	  -->
	<para>
    <!--
	  Enhance performance of SELECT when lots of rows involved. (Tatsuo Ishii)
    -->
多くの行が出力されるSELECTの性能を改善しました。(Tatsuo Ishii)
	</para>
	<para>
    <!--
	  <productname>Pgpool-II</productname> flushes data to network
	  (calling write(2)) every time it sends a row data ("Data
	  Row" message) to frontend. For example, if 10,000 rows
	  needed to be transfer, 10,000 times write()s are
	  issued. This is pretty expensive. Since after repeating to
	  send row data, "Command Complete" message is sent, it's
	  enough to issue a write() with the command complete
	  message. Also there are unnecessary flushing are in handling
	  the command complete message.
      -->
<productname>Pgpool-II</productname> がフロントエンドに行データ（"Data Row"メッセージ）を送るたびにネットワークにデータを（<function>write(2)</function>を呼び出して）フラッシュしていました。
例えば、10,000行を転送する必要がある場合、write()が10,000 回呼び出されます。
これは非常にコストが高いです。
繰り返し行データを送信した後、"Command Complete"メッセージが送られるので、Command Completeメッセージの時に併せてwrite()を発行すれば十分です。
また、command completeメッセージの取り扱いにおいて、不必要なフラッシュがありました。
	</para>
	<para>
    <!--
	  <ulink url="http://www.pgpool.net/pipermail/pgpool-hackers/2016-September/001784.html">Quick
	  testing</ulink> showed that from 47% to 62% performance
	  enhancements were achieved in some cases.
      -->
<ulink url="http://www.pgpool.net/pipermail/pgpool-hackers/2016-September/001784.html">Quick testing</ulink>のテスト結果から、この修正により、特定の場合で、47%から62%の性能向上が得られたことが分かりました。
	</para>
	<para>
    <!--
	  Unfortunately, performance in workloads where transferring
	  few rows, will not be enhanced since such rows are needed to
	  flush to network anyway.
      -->
しかし、問い合わせが返す行が少ない場合は、まだ改善されていません。
そうした行はいずれにせよネットワークへのフラッシュが必要だからです。
	</para>
      </listitem>

      <listitem>
	<!--
	    2016-08-26 [d768944] import PostgreSQL 9.6 parser
	  -->
	<para>
    <!--
	  Import <productname>PostgreSQL</productname> 9.6's SQL
	  parser. (Bo Peng)
    -->
	  <productname>PostgreSQL</productname> 9.6's のパーサを取り込みました。 (Bo Peng)
	</para>
	<para>
    <!--
	  This allows <productname>Pgpool-II</productname> to fully
	  understand the newly added SQL syntax such as <literal>COPY
	  INSERT RETURNING</literal>.
      -->
      これにより、<productname>Pgpool-II</productname> は <productname>PostgreSQL</productname>
      9.6 で導入された新しい構文 (<literal>COPY INSERT/UPDATE/DELETE ... RETURNING</literal> など) を理解可能です。
	</para>
      </listitem>

      <listitem>
	<!--
	    2016-08-26 [f284be4] Handling of pg_terminate_backend for simple query protocol
	  -->
	<para>
    <!--
	  In some cases pg_terminate_backend() now does not trigger a
	  fail-over. (Muhammad Usama)
    Because PostgreSQL returns exactly the same error code as postmaster
    down case and <function>pg_terminate_backend()</function> case, using
    <function>pg_terminate_backend()</function> raises a failover which user might not want. To
    fix this, now <productname>Pgpool-II</productname> finds a pid of backend which is the target of
    <function>pg_terminate_backend()</function> and does not trigger failover if so.
    This functions is limited to the case of simple protocol and the pid
    is given to <function>pg_terminate_backend()</function> as a constant. So if you call
    <function>pg_terminate_backend()</function> via extended protocol (e.g. Java) still
    <function>pg_terminate_backend()</function> triggers a failover.
    -->
ある場合では、pg_terminate_backend() 関数が failover を引き起さないようになりました。(Muhammad Usama)
	</para>
    <para>
<function>pg_terminate_backend()</function>でバックエンドを終了させた場合、
<productname>PostgreSQL</productname>がpostmasterをシャットダウンしたときと同じメッセージを返しますので、
ユーザが望まないかもしれないフェールオーバーを発生させます。
</para>
<para>
これを修正するために、<productname>Pgpool-II</productname>は、
<function>pg_terminate_backend()</function>の対象バックエンドのPIDを検出し、フェールオーバーを発生させません。
</para>
<para>
この修正は単純なプロトコルの場合、または<function>pg_terminate_backend()</function>
に渡されたPIDが定数の場合にのみ適用します。
拡張プロトコル（Javaなど）の場合、<function>pg_terminate_backend()</function>はフェールオーバーを起こします。
</para>
      </listitem>

      <listitem>
	<!--
	    2016-03-15 [47d9af9] Mega patch to add SGML docs.
	  -->
	<para>
<!--
          HTML documents are now generated from SGML documents.
          (Muhammad Usama, Tatsuo Ishii, Bo Peng)
-->
HTMLドキュメントが、SGMLドキュメントから生成されるようになりました。(Muhammad Usama, Tatsuo Ishii, Bo Peng)
	</para>
	<para>
<!--
	  It is intended to have better construction, contents and
          maintainability. Also man pages are now generated from SGML.
	  However, still there's tremendous room to
          enhance the SGML documents. Please help us!
-->
これはより良い構成、内容、保守の容易性をもたらすためです。
また、manページがSGMLから生成されるようになりました。
しかし、SGMLドキュメントにはまだたくさんの改良の余地があります。
どうか私達を助けてください！
	</para>
      </listitem>

    </itemizedlist>
  </sect2>

  <sect2>
  <!--
    <title>Other Enhancements</title>
    -->
    <title>他の改善点</title>

    <itemizedlist>

      <listitem>
	<!--
	    2016-08-24 [0f4d1de] Make authentication error message more user friendly.
	  -->

	<para>
    <!--
	  Make authentication error message more user friendly. (Tatsuo Ishii)
    -->
	  認証エラーメッセージをわかりやすくしました。 (Tatsuo Ishii)
	</para>
	<para>
    <!--
	  When attempt to connect to backend (including health
	  checking), emit error messages from backend something like
	  "sorry, too many clients already" instead of "invalid
	  authentication message response type, Expecting 'R' and
	  received '%c'"
      -->
バックエンドに接続する時に(ヘルスチェックを含む)、"invalid authentication message response type, Expecting 'R' and received '%c'" メッセージではなく"sorry, too many clients already"のようなメッセージを返すようにしました。
	</para>
      </listitem>

      <listitem>
	<!--
	    2016-08-22 [2088a17] Tighten up health check timer expired condition in pool_check_fd()
	  -->
	<para>
    <!--
	  Tighten up health check timer expired condition in pool_check_fd(). (Muhammad Usama)
    -->
      pool_check_fd()のヘルスチェックタイマーの期限切れ条件を強化しました。(Muhammad Usama)
	</para>
      </listitem>

      <listitem>
	<!--
	    2016-07-29 [6ff2ac0] Add new script called "watchdog_setup".
	    2016-08-18 [d3211dc] Let watchdog_setup to be installed.
	  -->
	<para>
    <!--
	  Add new script called "watchdog_setup". (Tatstuo Ishii)
      -->
	  新しいスクリプト "watchdog_setup" が追加されました。 (Tatstuo Ishii)
	</para>
	<para>
    <!--
	  <xref linkend="WATCHDOG-SETUP"> is a command to create a
	  temporary installation
	  of <productname>Pgpool-II</productname> clusters with
	  watchdog for mainly testings.
      -->
<xref linkend="WATCHDOG-SETUP"> は watchdog 機能を有効にした<productname>Pgpool-II</productname>クラスタのテスト環境を構築するコマンドです。
	</para>
      </listitem>

      <listitem>
	<!--
	    2016-07-29 [cf319c4] Add "-pg" option to pgpool_setup.
	    2016-08-16 [d5c3cf2]  Let pgpool_setup install into dist bin.
	  -->
	<para>
    <!--
	  Add "-pg" option to pgpool_setup. (Tatsuo Ishii)
      -->
	  pgpool_setup に "pg" オプションが追加されました。(Tatsuo Ishii)
	</para>
	<para>
    <!--
	  This is useful when you want to assign specific port numbers to
	  <productname>PostgreSQL</productname> while
	  using <xref linkend="PGPOOL-SETUP">. Also
	  now <command>pgpool_setup</command> is installed in the
	  standard bin directory which is same
	  as <command>pgpool</command>.
      -->
これは<xref linkend="PGPOOL-SETUP">を使用する時に、<productname>PostgreSQL</productname>に特定のポート番号を割り当てたい場合に便利です。
また、<command>pgpool</command> と同じように、<command>pgpool_setup</command>は標準binディレクトリにインストールされるようになりました。
	</para>
      </listitem>

      <listitem>
	<!--
	    2016-08-12 [9db83a8] Add "replication delay" column to "show pool_nodes".
	  -->
	<para>
    <!--
	  Add "replication delay" column to "show pool_nodes". (Tatsuo Ishii)
      -->
	  <link linkend="SQL-SHOW-POOL-NODES">show pool_nodes</link> の出力結果に replication delay カラムが追加されました。(Tatsuo Ishii)
	</para>
	<para>
    <!--
	  This column
	  shows the <link linkend="runtime-streaming-replication-check">
	  replication delay</link> value in bytes if operated in
	  streaming replication mode.
      -->
      streaming replication モードの場合、
      このカラムは <link linkend="runtime-streaming-replication-check">replication delay</link> の値を bytes 単位で表示します。
	</para>
      </listitem>

      <listitem>
	<!--
	    2016-07-12 [726cb5d] Do not update status file if all backend nodes are in down status.
	  -->
	<para>
    <!--
	  Do not update status file if all backend nodes are in down status. (Chris Pacejo, Tatsuo Ishii)
    -->
     すべてのノードがダウンした場合、 status ファイルを更新しないように変更されました。(Chris Pacejo, Tatsuo Ishii)
	</para>
	<para>
    <!--
	  This commit tries to remove the data inconsitency in
	  replication mode found
	  in <ulink url="http://www.pgpool.net/pipermail/pgpool-general/2015-August/003974.html">[pgpool-general:
	  3918]</ulink> by not recording the status file when all
	  backend nodes are in down status.  This surprisingly simple
	  but smart solution was provided by Chris Pacejo.
      -->
レプリケーションモードにおいて、すべてのノードがダウン状態の場合にstatusファイルに記録しないようにすることで、<ulink url="http://www.pgpool.net/pipermail/pgpool-general/2015-August/003974.html">[pgpool-general:3918]</ulink> で報告されたデータの不整合を修正しました。
この驚ほど単純ですが、スマートな解決方法はChris Pacejoにより提供されました。
	</para>
      </listitem>

      <listitem>
	<!--
	    2016-05-23 [9342472] Permit pgpool to support multiple SSL cipher protocols
	  -->
	<para>
    <!--
	  Allow to use multiple SSL cipher protocols. (Muhammad Usama)
    -->
     <productname>Pgpool-II</productname> が 複数 SSL cipher protocols に対応できるように修正しました。(Muhammad Usama)
	</para>
	<para>
    <!--
	  By replacing TLSv1_method() with SSLv23_method() while
	  initializing the SSL session, we can use more protocols than
	  TLSv1 protocol.
      -->
SSLセッションを初期化する際の処理でTLSv1_method()を<function>SSLv23_method()</function>で置き換えることにより、TLSv1プロトコルよりも多くのプロトコルを使うことができるようになりました。
	</para>
      </listitem>

      <listitem>
	<!--
	    2016-04-07 [0e01d32] removing the limit on the maximum number
        of items in the black_function_list and white_function_list lists.
	  -->
	<para>
    <!--
	  Allow to use arbitrary number of items in the
	  black_function_list/white_function_list. (Muhammad Usama)
    -->
	  black_function_list/white_function_list
      に任意のアイテムの数が使用できるようになりました。(Muhammad Usama)
	</para>
	<para>
    <!--
	  Previously there were fixed limits for those.
      -->
      これまで、このアイテムの数には固定の上限がありました。
	</para>
      </listitem>

      <listitem>
	<!--
	    2016-02-17 [f2a5081] Properly process empty query (all comments)
	  -->
	<para>
    <!--
	  Properly process empty queries (all comments). (Tatsuo Ishii)
    -->
     コメントのみを含む空クエリを適切に処理できるよう修正しました。(Tatsuo Ishii)
	</para>
	<para>
    <!--
	  <productname>Pgpool-II</productname> now recognizes an empty
	  query consisted of all comments (for example "/* DBD::Pg
	  ping test v3.5.3 */") (note that no ';') as an empty query.
      -->
この修正で、<productname>Pgpool-II</productname>"/* DBD::Pg ping test v3.5.3 */" (';' を含まないことに注意)のような空クエリを正しく識別できるようになりました。
	  </para>
	<para>
    <!--
	  Before such that query was recognized an error.
      -->
      これまではエラークエリとして処理していました。
	</para>
      </listitem>

      <listitem>
	<!--
        2016-02-01 [44f43cc]  Add some warning messages for wd_authkey hash calculation failure
	  -->
	<para>
    <!--
	  Add some warning messages for wd_authkey hash calculation failure. (Yugo Nagata)
    -->
      wd_authkey ハッシュ計算失敗時に警告メッセージを出力するようにしました。(Yugo Nagata)
	</para>
	<para>
    <!--
	  Sometimes wd_authkey calculation fails for some reason other
	  than authkey mismatch. The additional messages make these
	  distinguishable for each other.
      -->
      たまに、認証キー不一致以外の何らかの理由で wd_authkey 計算に失敗することがあります。
      メッセージ出力を追加することでこれらを互いに区別できるようにしました。
	</para>
      </listitem>

    </itemizedlist>

  </sect2>

  <sect2>
  <!--
    <title>Changes</title>
    -->
    <title>変更点</title>

    <itemizedlist>

      <listitem>
        <!--
            2016-11-09 [f6ec434] Fix the broken log_destination = syslog functionality.
        -->
        <para>
        <!--
        Fix the broken log_destination = syslog functionality.
        -->
log_destination = syslog 設定の不具合を修正しました。(Muhammad Usama)
        </para>
        <para>
        <!--
        Fixing the logging to the syslog destination, which got broken by the
        PGPOOL SET/SHOW command commit, and also enhancing the log_destination
        configuration parameter to be assigned with the comma separated list of multiple
        destinations for the <productname>Pgpool-II</productname> log. Now, after this commit log_destination can
        be set to any combination of 'syslog' and 'stderr' log destinations.
        -->
PGPOOL SET/SHOW コマンド追加の修正によって、ログの出力先がsyslogの場合、不具合がありましたので、修正しました。また、log_destinationパラメータがカンマ区切りで複数出力先を指定することができるようになりました。この修正によって、log_destination は "syslog" と "stderr" の任意の組み合わせに設定できるようになりました。
        </para>
      </listitem>
      <listitem>
	<!--
	    2016-09-24 [cc33fe3] Change the default value of search_primary_node_timeout from 10 to 300.
	  -->
			<para>
            <!--
            Change the default value of
            <xref linkend="guc-search-primary-node-timeout"> from 10 to 300. (Tatstuo Ishii)
            -->
<xref linkend="guc-search-primary-node-timeout">のデフォルト値を10から300に変更しました。(Tatstuo Ishii)
			</para>
			<para>
            <!--
            Prior default value 10 seconds is sometimes too short for a standby to
            be promoted.
            -->
これまでのデフォルト値10秒は、スタンバイを昇格する際には小さすぎでした。
			</para>
      </listitem>

      <listitem>
          <!--
            2016-06-09 [7671794] Change the Makefile under directory src/sql/,that is proposed by [pgpool-hackers: 1611]
            -->
			<para>
            <!--
			Change the <filename>Makefile</filename> under directory
            <filename>src/sql/</filename>, that is proposed by
            <ulink url="http://www.pgpool.net/pipermail/pgpool-hackers/2016-June/001611.html">
            [pgpool-hackers: 1611]</ulink>. (Bo Peng)
            -->
            src/sql/ 配下の Makefile が修正されました。(Bo Peng)
            </para>
            <para>
            詳しくは  <ulink url="http://www.pgpool.net/pipermail/pgpool-hackers/2016-June/001611.html">
            [pgpool-hackers: 1611]</ulink> を参照してください。
			</para>

      </listitem>
      <listitem>
			  <!--
				  2016-04-20 [883d761] Change the PID length of pcp_proc_count command output to 6 characters long
				-->
			<para>
            <!--
				Change the PID length of <link linkend="PCP-PROC-COUNT">pcp_proc_count</link> command output to 6 characters long. (Bo Peng)
                -->
                pcp_proc_count コマンドの出力結果のプロセス ID を 6 桁まで表示 できるよう修正しました。(Bo Peng)
			</para>
            <para>
            <!--
                If the <productname>Pgpool-II</productname> process ID are over 5 characters, the 6th character of each process ID
                will be removed. This commit changes the process ID length of <link linkend="PCP-PROC-COUNT">pcp_proc_count</link> command
                output to 6 characters long.
                -->
                 特定の環境において、pcp_proc_count コマンドの出力結果のプロセス ID が6 桁の場合、
                 6 番目の文字が表示されませんでした。 この修正で、プロセス ID が最大 6 桁まで表示するよう変更しました。
            </para>
      </listitem>
      <listitem>
            <!--
		        2016-04-15 [9b62eca] Redirect all user queries to primary server
            -->
            <para>
            <!--
			    Redirect all user queries to primary server. (Tatsuo Ishii)
            -->
                すべてのクエリがプライマリサーバに送信されるように変更しました。(Tatsuo Ishii)
            </para>
            <para>
            <!--
               Up to now some user queries are sent to other than the primary server
               even if <xref linkend="guc-load-balance-mode"> = off. This commit changes the behavior: if
               load_balance_mode = off in streaming replication mode, now all the
               user queries are sent to the primary server only.
               -->
<xref linkend="guc-load-balance-mode"> = off の場合でも、一部のクエリがプライマリサーバ以外にも転送されていました。
               この修正で、 streaming replication モードで load_balance_mode = off
               の場合はすべてのクエリをプライマリサーバにのみ送るようにしました。
            </para>
      </listitem>
    </itemizedlist>
  </sect2>

  <sect2>
  <!--
    <title>Bug fixes</title>
    -->
    <title>不具合修正</title>

    <itemizedlist>
      <listitem>
      <!--
      2016-11-14 [266b67a]  Fixing a potential crash in pool_stream functions.
      -->
      <para>
      <!--
      Fixing a potential crash in pool_stream functions.
      -->
pool_stream関数の潜在的なクラッシュを修正しました。(Muhammad Usama)
      </para>
      <para>
      <!--
      POOL_CONNECTION->con_info should be checked for null value before de-referencing when read or write fails on backend socket.
      -->
POOL_CONNECTION-> con_infoは、バックエンドソケットで読み取りまたは書き込みが失敗したときに、逆参照する前にヌル値をチェックする必要があります。
      </para>
      </listitem>
      <listitem>
      <!--
      2016-11-14 [ef6c0c8] Fixing the design of failover command propagation on watchdog cluster
      -->
      <para>
      <!--
      Fixing the design of failover command propagation on watchdog cluster
      -->
watchdogクラスタでのフェイルオーバーコマンドの転送処理が改善されました。(Muhammad Usama)
      </para>
      <para>
      <!--
      Overhauling the design of how failover, failback and promote node commands are
      propagated to the watchdog nodes. Previously the watchdog on pgpool-II node that
      needs to perform the node command (failover, failback or promote node) used to
      broadcast the failover command to all attached pgpool-II nodes. And this
      sometimes makes the synchronization issues, especially when the watchdog cluster
      contains a large number of nodes and consequently the failover command sometimes
      gets executed by more than one <productname>Pgpool-II</productname>.
      -->
これまでは、<productname>Pgpool-II</productname> ノードの watchdogがすべての接続されたノードにフェイルオーバーコマンド(failover、 failback 及び promote node)を転送していました。多数のノードが含まれているwatchdogクラスタでは、フェールオーバーコマンドが複数の<productname>Pgpool-II</productname>によって実行されることによって、データの同期問題を引き起こす可能性がありました。このコミットでは、すべてのフェイルオーバーコマンド(failover、 failback 及び promote node)が master/coordinator watchdog に転送され、master/coordinator watchdogはすべてのスタンバイノードに転送するようになりました。
      </para>
      <para>
      <!--
      Now with this commit all the node commands are forwarded to the
      master/coordinator watchdog, which in turn propagates to all standby nodes.
      Apart from above the commit also changes the failover command interlocking
      mechanism and now only the master/coordinator node can become the lock holder
      so the failover commands will only get executed on the master/coordinator node.
      -->
また、今回の修正では、インターロック機能も変更されました。master/coordinatorノーのみがロックホルダになり、フェイルオーバコマンドはmaster/coordinatorノードでのみ実行されます。
      </para>
      </listitem>
      <listitem>
        <!--
            2016-09-27 [a7e459f] Fix the case when all backends are down then 1 node attached.
            -->
        <para>
        <!--
        Fix the case when all backends are down then 1 node attached. (Tatsuo Ishii)
        -->
        すべてのバックエンドがダウンした後に、1つのノードを復帰させる時の不具合が修正されました。(Tatsuo Ishii)
        </para>
        <para>
        <!--
        When all backends are down, no connection is accepted. Then 1
        <productname>PostgreSQL</productname> becomes up, and attach the node using pcp_attach_node. It
        successfully finishes. However, when a new connection arrives, still
        the connection is refused because<productname>Pgpool-II</productname> child process looks into the
        cached status, in which the recovered node is still in down status if
        mode is streaming replication mode (native replication and other modes
        are fine). Solution is, if all nodes are down, force to restart all
        pgpool child.
        -->
すべてのノードがダウンすると、すべてのコネクションを受け付けなくなります。
その状態で1つの<productname>PostgreSQL</productname>が起動し、<command>pcp_attach_node</command>コマンドでそのノードを復帰させます。
そしてこのコマンドは成功しました。
しかし、新しい接続が拒否されました。
これは<productname>Pgpool-II</productname> の子プロセスがキャッシュされた古い情報を参照したのが原因でした。
ストリーミングレプリケーションモードでは、このキャッシュされた情報において、復帰させたノードの状態がdownのままでした。
（ネィティブレプリケーションモード、およびそれ以外のモードでは問題ありません）
解決法として、全ノードがダウンした場合、強制的に全 <productname>Pgpool-II</productname>子プロセスを再起動するようにしました。
        </para>
      </listitem>
      <listitem>
        <!--
        2016-09-19 [e89e365] Fix for: [pgpool-general: 4997] Avoiding downtime when pgpool changes require a restart
            -->
        <para>
        <!--
	    Fix for avoiding downtime when <productname>Pgpool-II</productname> changes require a restart. (Muhammad Usama)
        -->
再起動が必要なパラメータの設定を変更した際の<productname>Pgpool-II</productname>停止が起こらないようにしました。(Muhammad Usama)
        </para>
        <para>
        <!--
        To fix this, the verification mechanism of configuration parameter values is
        reversed, previously the standby nodes used to verify their parameter values
        against the respective values on the master <productname>Pgpool-II</productname> node and when the
        inconsistency was found the FATAL error was thrown, now with this commit the
        verification responsibility is delegated to the master <productname>Pgpool-II</productname> node.
        Now the master node will verify the configuration parameter values of each
        joining standby node against its local values and will produce
        a WARNING message instead of an error in case of a difference.
        This way the nodes having the different configurations will also be allowed to
        join the watchdog cluster and the user has to manually look out for the
        configuration inconsistency warnings in the master <productname>Pgpool-II</productname> log to avoid the
        surprises at the time of <productname>Pgpool-II</productname> master switch over.
        -->
この修正のために、設定パラメータの検証機構の順序を逆にしました。
以前はスタンバイノードが<productname>Pgpool-II</productname>マスターノードに対して設定パラメータの値を検証し、不整合が見つかった場合にはFATALエラーが出力されていました。
この修正で、<productname>Pgpool-II</productname>マスターノードに検証の役割が移譲されました。
マスターノードは参加している個々のスタンバイノードの設定値をローカルの設定値と比較し、違っている場合にはエラーではなくてWARNINGメッセージを出力します。
この方法では、ユーザは、手動でマスター<productname>Pgpool-II</productname>ログの中から不整合ワーニングを見つけて、<productname>Pgpool-II</productname>マスターのスイッチオーバが起きたときに驚くようなことが起こらないようにしなければなりません。
        </para>
      </listitem>
      <listitem>
        <!--
            2016-09-19 [233ae46] Fixing a problem with the watchdog failover_command locking mechanism
            -->
        <para>
        <!--
	    Fix a problem with the watchdog <xref linkend="guc-failover-command"> locking mechanism. (Muhammad Usama)
        -->
        watchdog が有効な場合、<xref linkend="guc-failover-command"> コマンドのロック取得時の処理が改善されました。(Muhammad Usama)
        </para>
      </listitem>
      <listitem>
      <!--
            2016-09-12 [b412da2] Disable strict aliasing optimization.
        -->
        <para>
        <!--
        Add compiler flag "-fno-strict-aliasing" in <filename>configure.ac</filename> to fix compiler error. (Tatsuo Ishii)
        -->
        コンパイルエラーを修正するために、<filename>configure.ac</filename>
        ファイルにコンパイルフラグ "-fno-strict-aliasing" が追加されました。(Tatsuo Ishii)
        </para>
      </listitem>
      <listitem>
      <!--
        2016-09-09 [650c660] Do not use random() while generating MD5 salt.
        -->
        <para>
        <!--
	    Do not use <function>random()</function> while generating MD5 salt. (Tatsuo Ishii)
        -->
        MD5 salt を生成するときに、<function>random()</function> を使用しないように修正しました。(Tatsuo Ishii)
        </para>
        <para>
        <!--
        <function>random()</function> should not be used in security related applications.  To
        replace <function>random()</function>, import <function>PostmasterRandom()</function> from PostgreSQL.
        -->
<function>random()</function>関数はセキュリティ関連のアプリケーションで使用すべきではありません。
<function>random()</function>の代わりに<productname>PostgreSQL</productname>の<function>PostmasterRandom()</function> 使用するように変更しました。
        </para>

      </listitem>
      <listitem>
      <!--
        2016-09-05 [455df3d] Don't ignore sync message from frontend when query cache is enabled.
        -->
        <para>
        <!--
	    Don't ignore sync message from frontend when query cache is enabled. (Tatsuo Ishii)
        -->
        クエリキャッシュが有効な場合、sync メッセージが廃棄されないよう修正しました。(Tatsuo Ishii)
        </para>
      </listitem>
      <listitem>
      <!--
        2016-08-29 [4c23c9b] Fix for 237: Pgpool-II fails to start if listen_addresses is empty string
        -->
        <para>
        <!--
	    Fix bug that <productname>Pgpool-II</productname> fails to start if <xref linkend="guc-listen-addresses"> is empty string. (bug 237) (Muhammad Usama)
        -->
<xref linkend="guc-listen-addresses">が空文字の場合、Pgpool-II が起動できない不具合を修正しました。(bug 237) (Muhammad Usama)
        </para>
        <para>
        <!--
        The socket descriptor array (fds[]) was not getting the array end marker
        when TCP listen addresses are not used.
        -->
        TCP listen addresses が空の場合、socket descriptor 配列（fds[]）の終了マークがないのが原因でした。
        </para>
      </listitem>
      <listitem>
      <!--
        2016-08-22 [879d16a] Create regression log directory if it does not exist yet.
        -->
        <para>
        <!--
	    Create regression log directory if it does not exist yet. (Tatsuo Ishii)
        -->
リグレッションログディレクトリが存在しない場合、作成されるようになりました。(Tatsuo Ishii)
        </para>
      </listitem>
      <listitem>
      <!--
        2016-08-17 [37e376e] Fixing the error messages when the socket operation fails
        -->
        <para>
        <!--
	    Fixing the error messages when the socket operation fails. (Muhammad Usama)
        -->
        ソケットの操作に失敗したときのエラーメッセージを修正しました。(Muhammad Usama)
        </para>
      </listitem>
      <listitem>
      <!--
        2016-08-15 [f2b5d17]  Fix regression failure of 003.failover.
        -->
        <para>
        <!--
	    Update regression test 003.failover to reflect the changes made to
        <link linkend="SQL-SHOW-POOL-NODES">show pool_nodes</link>. (Tatsuo Ishii)
        -->
        <link linkend="SQL-SHOW-POOL-NODES">show pool_nodes</link> コマンドの修正を反映し、レグレッションテスト 003.failover を変更しました。
        </para>
      </listitem>
      <listitem>
      <!--
        2016-08-09 [a7bc4c8] Fix hang when portal suspend received
        -->
        <para>
        <!--
	    Fix hang when portal suspend received. (bug 230) (Tatsuo Ishii)
        -->
        Portal suspend を受け取ったときのハングが修正されました。(bug 230) (Tatsuo Ishii)
        </para>
      </listitem>
      <listitem>
      <!--
        2016-08-04 [3b2db66] Fix for 228: pgpool doesn't de-escalate IP in case network restored
        -->
        <para>
<!--
	    Fix pgpool doesn't de-escalate IP in case network restored. (bug 228) (Muhammad Usama)
-->
ネットワークが復旧した時にIPを降格しない問題を修正しました。(bug 228) (Muhammad Usama)
        </para>
        <para>
<!--
        set_state function is made to de-escalate, when it is changing the local node's
        state from the coordinator state to some other state.
-->
ローカルノードの状態が調停者状態から他の状態に変わった時に降格させるために、set_state関数が実装されました。
        </para>
      </listitem>
      <listitem>
      <!--
        2016-08-02 [9b122ab]  SIGUSR1 signal handler should be installed before watchdog initialization.
        -->
        <para>
        <!--
	    SIGUSR1 signal handler should be installed before watchdog initialization. (Muhammad Usama)
        -->
        SIGUSR1 シグナルハンドラーを watchdog の初期化前にインストールするように修正しました。(Muhammad Usama)
        </para>
        <para>
        <!--
        Since there can be a case where a failover request from other watchdog nodes
        arrive at the same time when the watchdog has just been initialized,
        and if we wait any longer to install a SIGUSR1 signal handler, it can
        result in a potential crash
        -->
        watchdog 初期化直後に 他のwatchdog ノードから failover リクエストがあった場合、
        SIGUSR1 シグナルハンドラーのインストールを待っていれば、クラッシュが発生する可能性がありました。
        </para>
      </listitem>
      <listitem>
      <!--
        2016-08-01 [024eaea]  Fix for 215: pgpool doesnt escalate ip in case of another node inavailability
        -->
        <para>
        <!--
        Fix <productname>Pgpool-II</productname> doesn't escalate ip in case of another node inavailability. (bug 215) (Muhammad Usama)
        -->
        他のノードが利用できない場合、<productname>Pgpool-II</productname> が
        IPアドレスをエスカレートしない不具合を修正しました。(bug 215) (Muhammad Usama)
        </para>
        <para>
        <!--
        The heartbeat receiver fails to identify the heartbeat sender watchdog node when
        the heartbeat destination is specified in terms of an IP address while
        wd_hostname is configured as a hostname string or vice versa.
        -->
        Heartbeat destination が IPアドレスで指定され、wd_hostname が hostname で設定される場合、
        heartbeat receiver が heartbeat sender watchdog ノードを識別できなかったのが原因でした。
        逆の場合でも同様なエラーが起こります。
        </para>
      </listitem>
      <listitem>
      <!--
        2016-07-29 [5bce300]  Fixing a coding mistake in watchdog code.
        -->
        <para>
        <!--
        Fixing a coding mistake in watchdog code. (Muhammad Usama)
        -->
        watchdog に関するコーデイングミスを修正しました。(Muhammad Usama)
        </para>
        <para>
        <!--
        <function>wd_issue_failover_lock_command()</function> function is supposed to forward command type
        passed in as an argument to the <function>wd_send_failover_sync_command()</function> function instead
        it was passing the NODE_FAILBACK_CMD command type.
        -->
<function>wd_issue_failover_lock_command()</function>関数は、渡ってきたコマンドタイプを<function>wd_send_failover_sync_command()</function>関数の引数に渡すように想定されていますが、その代わりにNODE_FAILBACK_CMDコマンドタイプを渡していました。
        </para>
        <para>
        <!--
        The commit also contains some log message enhancements.
        -->
        この修正で、いくつかのログメッセージも改善しました。
        </para>
      </listitem>
      <listitem>
      <!--
        2016-07-28 [541451e]  Display human readable output for backend node status.
        -->
        <para>
        <!--
	    Display human readable output for backend node status. (Muhammad Usama)
        -->
        <link linkend="PCP-PROC-INFO">pcp_node_info</link> コマンドの標準出力の「Status」がわかりやすくように変更されました。(Muhammad Usama)

        </para>
        <para>
        <!--
        Changed the output of <link linkend="PCP-PROC-INFO">pcp_node_info</link> utility and show commands display human
        readable backend status string instead of internal status code.
        -->
        <link linkend="PCP-PROC-INFO">pcp_node_info</link> コマンドの標準出力の「Status」が内部状態コードから人間がわかりやすい状態の文字列に変更されました。
        </para>
      </listitem>
      <listitem>
      <!--
        2016-07-27 [3cbce4e]  Replace "MAJOR" macro to prevent occasional failure.
        -->
        <para>
        <!--
          Replace "MAJOR" macro to prevent occasional failure. (Tatsuo Ishii)
          -->
          「MAJOR」マクロによる発生しうるセグメンテーションフォルトを修正しました。(Tatsuo Ishii)
        </para>
        <para>
        <!--
          The macro calls <function>pool_virtual_master_db_node_id()</function> and then access
          backend->slots[id]->con using the node id returned. In rare cases, it
          could point to 0 (in case when the DB node is not connected), which
          gives access to con->major, then it causes a segfault.
          -->
          MAJOR が <function>pool_virtual_master_db_node_id()</function> を呼出し、
          戻り値 idを使ってbackend->slots[id]->con にアクセスします。
可能性は低いですが、conが0を指し（DB にアクセスできない場合）、con->major にアクセスし、セグメンテーションフォルトを引き起す可能性がありました。
        </para>
      </listitem>
      <listitem>
      <!--
        2016-07-14 [866575c]  Fix for  [pgpool-hackers: 1501]  kind does not match error
        -->
        <para>
        <!--
        Fix "kind mismatch" error message in <productname>Pgpool-II</productname>. (Muhammad Usama)
        -->
        "kind mismatch" エラーメッセージの処理について修正しました。(Muhammad Usama)
        </para>
        <para>
        <!--
        Many of "kind mismatch..." errors are caused by notice/warning
        messages produced by one or more of the DB nodes. In this case now
        <productname>Pgpool-II</productname> forwards the messages to frontend, rather than throwing the
        "kind mismatch..." error. This would reduce the chance of "kind
        mismatch..."  errors.
        -->
        多くの"kind mismatch..."エラーは、NOTICE や WARNING メッセージが
        DBノードのいくつかで起こることによるものです。
        この修正では、そうしたケースにおいて、"kind mismatch..."エラーを引き起こすのではなく、
        NOTICE や WARNINGメッセージをフロントエンドに送るようになりました。
        これにより、"kind mismatch..."エラーの発生が減少します。
        </para>
      </listitem>
      <listitem>
      <!--
        2016-07-14 [680e329]  Fix handling of pcp_listen_addresses config parameter.
        -->
        <para>
        <!--
	    Fix handling of <xref linkend="guc-pcp-listen-addresses"> config parameter. (Muhammad Usama)
        -->
        <xref linkend="guc-pcp-listen-addresses"> パラメータの処理の不具合を修正しました。(Muhammad Usama)
        </para>
      </listitem>
      <listitem>
      <!--
        2016-07-07 [e245587]  Save and restore errno in each signal handler.
        -->
        <para>
        <!--
	    Save and restore errno in each signal handler. (Tatsuo Ishii)
        -->
        シグナルハンドラ中でエラー番号が保存されるようになりました。 (Tatsuo Ishii)
        </para>
      </listitem>
      <listitem>
      <!--
	    commit 0d1cdf96feb77de6f1dfc2d46ecd7467325d1f79
        2016-07-07 [0d1cdf9] Fix usage of wait(2) in pgpool main process
        -->
        <para>
        <!--
	    Fix usage of <function>wait(2)</function> in pgpool main process. (Tatsuo Ishii)
        -->
        pgpool メインプロセスの <function>wait(2)</function> の扱いを修正しました。(Tatsuo Ishii)
        </para>
        <para>
        <!--
        The usage of <function>wait(2)</function> in <productname>Pgpool-II</productname>
        main could cause infinite wait in the system call. Solution is,
        to use <function>waitpid(2)</function> instead of <function>wait(2)</function>.
        -->
<productname>Pgpool-II</productname> メインプロセスから呼び出される<function>wait(2)</function>はそのシステムコール内で永久に待つ可能性があります。
        この修正で、 <function>wait(2)</function> の代わりに、<function>waitpid(2)</function> を使うように変更しました。
        </para>
      </listitem>
      <listitem>
      <!--
        2016-06-28 [bb41a1e]  Fix confusing error messages.
        -->
        <para>
        <!--
	    Fix confusing error messages. (Tatsuo Ishii)
        -->
        <xref linkend="guc-fail-over-on-backend-error"> が off の場合、
        <function>read(2)</function> が -1 を返しても
        <function>pool_read()</function> がエラーメッセージを発行しない不具合が修正されました。(Tatsuo Ishii)
        </para>
      </listitem>
      <listitem>
      <!--
        2016-06-24 [a01624f]  Fix buffer over run problem in "show pool_nodes".
        -->
        <para>
        <!--
        Fix buffer over run problem in "show pool_nodes". (Tatsuo Ishii)
        -->
        <command>show pool_nodes</command> でのバッファオーバーランを修正しました。(Tatsuo Ishii)
        </para>
        <para>
        <!--
        While processing "show pool_nodes", the buffer for hostname was too
        short. It should be same size as the buffer used for <filename>pgpool.conf</filename>.
        -->
        <command>show pool_nodes</command> を実行時、hostname に割り当てられたバッファが十分ではないのが原因でした。
        <filename>pgpool.conf</filename> のバッファサイズと同じようにしました。
        </para>
      </listitem>
      <listitem>
      <!--
        2016-06-17 [4c63d10]  Fixing [pgpool-hackers: 1638] pgpool-II does not use default configuration
        -->
        <para>
        <!--
        Fix <ulink url="http://www.pgpool.net/pipermail/pgpool-hackers/2016-June/001638.html">
        [pgpool-hackers: 1638]</ulink> pgpool-II does not use default configuration. (Muhammad Usama)
        -->
        <ulink url="http://www.pgpool.net/pipermail/pgpool-hackers/2016-June/001638.html">
        [pgpool-hackers: 1638]</ulink> で報告された、<productname>Pgpool-II</productname>
        がデフォルトの設定を使用しない不具合が修正されました。(Muhammad Usama)
        </para>
        <para>
        <!--
         Configuration file not found should just throw a WARNING message
         instead of ERROR or FATAL.
         -->
         設定ファイルが見つからない場合は、 ERROR または FATAL ではなく、WARNING を返すように修正しました。
        </para>
      </listitem>
      <listitem>
      <!--
        2016-06-15 [226a21b]  Fix bug with load balance node id info on shmem
        -->
        <para>
        <!--
	    Fix bug with load balance node id info on shmem. (Tatsuo Ishii)
        -->
        共有メモリ上のロードバランスノードの書き込みに関するバグを修正しました。(Tatsuo Ishii)
        </para>
        <para>
        <!--
        There are few places where the load balance node was mistakenly put on
        wrong place. It should be placed on:
        -->
2, 3の箇所で、ロードバランスノードが間違ったことろに置かれてしまいました。
        </para>
        <para>
        [正しい場所]
        </para>
        <programlisting>
ConnectionInfo *con_info[child id, connection pool_id, backend id].load_balancing_node].
        </programlisting>
        <!--
        In fact it was placed on:
        -->
        <para>
        [実際に置かれた場所]
        </para>
        <programlisting>
*con_info[child id, connection pool_id, 0].load_balancing_node].
        </programlisting>
        <para>
        <!--
        As long as the backend id in question is 0, it is ok. However while
        testing <productname>Pgpool-II</productname> 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.
        -->
バックエンド id が 0 の場合、上記バグが発生しませんが、<productname>Pgpool-II</productname> 3.6 のフェイルオーバーテストで、プライマリノードが 1 (ロードバランスノード)、スタンバイノードが 0 の場合、ノード1 の接続が切断され、フェイルオーバーが起きています。
これは想定外のことだったのでこのバグが見つかりました。
        </para>
        <para>
        <!--
        It seems the bug was there since long time ago but it had not found
        until today by the reason above.
        -->
このバグはかなり前からありましたが、上記の理由で、今まで見つかっておリませんでした。
        </para>
      </listitem>
      <listitem>
      <!--
        2016-06-09 [6ae42e7]  fix for 0000197: pgpool hangs connections to database.
        -->
        <para>
        <!--
	    Fix for bug that pgpool hangs connections to database. (bug 197) (Muhammad Usama)
        -->
#197 で報告されたpgpoolのハングを修正しました。(bug 197) (Muhammad Usama)
        </para>
        <para>
        <!--
        The client connection was getting stuck when backend node and remote <productname>Pgpool-II</productname>
        node becomes unavailable at the same time. The reason was a missing command
        timeout handling in the function that sends the IPC commands to watchdog.
        -->
watchdog が有効で、バックエンドノードとリモート <productname>Pgpool-II</productname>ノードが同時接続できなくなった場合、クライアント接続がスタックします。
        原因は watchdog に IPC コマンドを送信する関数を呼び出すコマンドタイムアウトがなかったからです。
        </para>
      </listitem>
      <listitem>
      <!--
        2016-06-08 [294cf4a]  Fix a posible hang during health checking
        -->
        <para>
        <!--
	    Fix a posible hang during health checking. (bug 204) (Yugo Nagata)
        -->
        ヘルスチェックで発生し得るハングアップを修正しました。(bug 204) (Yugo Nagata)
        </para>
        <para>
        <!--
        Helath checking was hang when any data wasn't sent
        from backend after <function>connect(2)</function> succeeded. To fix this,
        <function>pool_check_fd()</function> returns 1 when <function>select(2)</function> exits with
        EINTR due to SIGALRM while health checkking is performed.
        -->
        <function>connect(2)</function> が成功し、
        その後バックエンドからデータが送信されない場合、ヘルスチェックがハングしていました。
ヘルスチェック中に、<function>select(2)</function>がSIGALRMのためにEINTRで終了した場合、<function>pool_check_fd()</function>が1を返すように修正しました。
        </para>
      </listitem>
      <listitem>
      <!--
        2016-05-25 [a2d04ab]  Deal with the case when the primary is not node 0 in streaming replication mode.
        -->
        <para>
        <!--
         Deal with the case when the primary is not node 0 in streaming replication mode. (Tatsuo Ishii)
        -->
         streaming replication モードで、プライマリノードが 0 ではない場合に発生する不具合が修正されました。 (Tatsuo Ishii)
        </para>
        <para>
        <!--
         <ulink url="http://www.pgpool.net/mantisbt/view.php?id=194#c837">
         http://www.pgpool.net/mantisbt/view.php?id=194#c837</ulink> 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 <function>do_query()</function> sends queries
         to wrong node (this is not clear from the report but I confirmed it in
         my investigation).
         -->
<ulink url="http://www.pgpool.net/mantisbt/view.php?id=194#c837">http://www.pgpool.net/mantisbt/view.php?id=194#c837</ulink>の報告により、bug194-3.3.diff を適用しても、プライマリノードが 0 ではない場合、ステートメントタイムアウトが発生する可能性がありました。
         調査した結果、MASTER マクロがプライマリノードまたはロードバランスノード
         以外のノードを返したからです。
そのため、<function>do_query()</function>がクエリを間違ったノードに送信していました（これは報告では明確ではありませんでしが、 調査で確認できました）。
        </para>
        <para>
        <!--
         <function>pool_virtual_master_db_node_id()</function>, 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.
         -->
MASTER マクロから呼ばれる<function>pool_virtual_master_db_node_id()</function> は、クエリコンテキストが存在する場合、query_context->virtual_master_node_id を返します。
その変数がまだ初期化されていない場合、この関数が間違ったノード を返す可能性があります。
そのため、<function>pool_virtual_master_db_node_id()</function> 関数を以下のように修正しました。
変数にプライマリノードもロード バランスノードも設定されていない場合、プライマリノードを返します。
        </para>
      </listitem>
      <listitem>
      <!--
        2016-05-24 [69d3fae]  If statement timeout is enabled on backend and do_query() sends a
        -->
        <para>
        <!--
	    If statement timeout is enabled on backend and <function>do_query()</function>
        sends a 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. (bug 194) (Tatsuo Ishii)
        -->
バックエンドのステートメントタイムアウトが有効で、<function>do_query()</function>がクエリをプライマリノードに送信し、それ以降のユーザクエリがスタンバイノードに送信された場合、次のコマンド、例えば、ENDコマンドが、プライマリノードのステートメントタイムアウトを引き起こし、kind mismatch error が発生する可能性がありました。(bug 194) (Tatsuo Ishii)
        </para>
        <para>
        <!--
        This fix tries to mitigate the problem by sending sync message instead
        of flush message in <function>do_query()</function>, 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".
        -->
        この問題を軽減するために、<function>do_query()</function>
        がフラッシュメッセージを送信する代わりに、sync メッセージ送信するように修正しました。
明示的トランザクションのときは、sync メッセージを送信することで、ステートメントタイムアウトタイマーがリセットされます。
暗黙的なトランザクションでは、このやり方は使えません。
なぜなら、unnamed portal が存在する場合、sync メッセージが unnamed portalを削除するからです。
        </para>
        <para>
<!--
        Plus, pg_stat_statement will no longer show the query issued by
        <function>do_query()</function> as "running".
-->
更にこれにより、pg_stat_statement が <function>do_query()</function> が発行したクエリを "running" で表示しなくなります。
        </para>
      </listitem>
      <listitem>
      <!--
        2016-05-22 [0c0e727]  Fix extended protocol handling in raw mode
        -->
        <para>
        <!--
	    Fix extended protocol handling in raw mode. (Tatsuo Ishii)
        -->
        拡張プロトコルのraw モードでのバグを修正しました。(bug 152) (Tatsuo Ishii)
        </para>
        <para>
        <!--
        Bug152 reveals that extended protocol handling in raw mode (actually
        other than in stream mode) was wrong in <function>Describe(</function>) and <function>Close()</function>.
        Unlike stream mode, they should wait for backend response.
        -->
        Bug 152の報告により、拡張プロトコルの raw モード（実は stream モード以外）で
        <function>Describe()</function> と <function>Close()</function>
        の処理に誤りがありました。stream モードとは異なり、バックエンドからの応答を待つべきでした。
        </para>
      </listitem>
      <listitem>
      <!--
        2016-05-20 [78c5d56]  Fix confusing comments in pgpool.conf
        -->
        <para>
        <!--
	    Fix confusing comments in <filename>pgpool.conf</filename>. (Tatsuo Ishii)
        -->
        <filename>pgpool.conf</filename> の不正確なコメントを修正しました。(Tatsuo Ishii)
        </para>
      </listitem>
      <listitem>
      <!--
        2016-05-11 [de905f6]  Fix documetation bug about raw mode
        -->
        <para>
        <!--
	    Fix  Japanese and Chinese documetation bug about raw mode. (Yugo Nagata, Bo Peng)
        -->
日本語と中国語ドキュメントのraw モードに関する内容の誤りを修正しました。(Yugo Nagata, Bo Peng)
        </para>
        <para>
        <!--
        Connection pool is avalilable in raw mode.
        -->
        raw モードでも、コネクションプーリングが有効です。
        </para>
      </listitem>
      <listitem>
      <!--
        2016-05-09 [9512999] Fix is_set_transaction_serializable() when
        SET default_transaction_isolation TO 'serializable'.
        -->
        <para>
        <!--
	    Fix is_<function>set_transaction_serializable()</function> when
        SET default_transaction_isolation TO 'serializable'. (bug 191) (Bo Peng)
        -->
<function>is_set_transaction_serializable()</function>関数の<command>SET default_transaction_isolation TO 'serializable'</command>の扱いに関するバグを修正しました。(bug 191) (Bo Peng)
        </para>
        <para>
        <!--
        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.
        -->
        <productname>Pgpool-II</productname> は <command>SET default_transaction_isolation TO 'serializable'</command>
        をプライマリだけではなく、スタンバイにも送信してしまい、エラーが起きていました。
        この修正で、streaming replication モードの場合、<command>SET default_transaction_isolation TO 'serializable'</command>
        がプライマリサーバのみに送信されます。
        </para>
      </listitem>
      <listitem>
      <!--
        2016-04-13 [a5fdf78]  Fix extended protocol hang with empty query
        -->
        <para>
        <!--
        Fix extended protocol hang with empty query. (bug 190) (Tatsuo Ishii)
        -->
        拡張プロトコルにおける空クエリの場合、発生し得るハングアップを修正しました。(Tatsuo Ishii)
        </para>
        <para>
        <!--
        The fixes related to extended protocol cases in 3.5.1 broke the case
        of empty query.  In this case backend replies with "empty query
        response" which is same meaning as a command complete message. Problem
        is, when empty query response is received, pgpool does not reset the
        query in progress flag thus keeps on waiting for backend. However,
        backend will not send the ready for query message until it receives a
        sync message. Fix is, resetting the in progress flag after receiving
        the empty query response and reads from frontend expecting it sends a
        sync message.
        -->
この修正は3.5.1で空のクエリの場合の拡張プロトコルの扱いに関係しています。
この場合バックエンドはcommand complete messageと同じ意味を持つ"empty query response"を返します。
問題は、"empty query response"を受信した際に、<productname>Pgpool-II</productname>がクエリ進行中フラグをリセットせず、 バックエンドの応答を待ち続けることことです。
しかし、バックエンドはsyncメッセージをを受け取るまではready for queryメッセージを返しません。
解決方法は、"empty query response"を受信した際に、クエリ進行中フラグをリセットし、フロントエンドがsync メッセージを送信することを期待してフロントエンドからの応答を待つことです。
        </para>
      </listitem>
      <listitem>
      <!--
        2016-04-05 [64696fd]  Fix for [pgpool-general: 4569] PGPoolII-3.5 : segfault
        -->
        <para>
        <!--
	    Fix for <ulink url="http://www.pgpool.net/pipermail/pgpool-general/2016-March/004627.html">
        [pgpool-general: 4569]</ulink> segfault during trusted_servers check. (Muhammad Usama)
        -->
	    <ulink url="http://www.pgpool.net/pipermail/pgpool-general/2016-March/004627.html">
        [pgpool-general: 4569]</ulink> により報告された
        trusted_servers チェック時のセグメンテーションフォルトを修正しました。 (Muhammad Usama)
        </para>
        <para>
        <!--
        PostgreSQL's memory and exception manager APIs adopted by the <productname>Pgpool-II</productname> 3.4 are not
        thread safe and are causing the segmentation fault in the watchdog lifecheck
        process, as it uses the threads to ping configured trusted hosts for checking
        the upstream connections.
        Fix is to remove threads and use the child process approach instead.
        -->
        <productname>Pgpool-II</productname> 3.4 からは <productname>PostgreSQL</productname>
        のメモリマネージャおよび 例外マネージャ API を流用していますが、
        それはスレッドセーフ ではありません。上位接続を確認するため ping の応答で信頼できるサーバ確認時、
        watchdog lifecheck プロセスでセグメンテ ーションフォルトを引き起こしていました。
        スレッドを削除し、 子プロセスを使うように修正しました。
        </para>
      </listitem>
      <listitem>
      <!--
        2016-03-29 [f7723c8]  Validating the PCP packet length
        -->
        <para>
        <!--
        Validating the PCP packet length. (Muhammad Usama)
        -->
PCP パケットの長さを検証するよう修正しました。(Muhammad Usama)
        </para>
        <para>
        <!--
        Without the validation check, a malformed PCP packet can crash the PCP child
        and/or can run the server out of memory by sending the packet with a
        very large data size.
        -->
        この検証がない場合、非常に巨大なデータサイズのパケットを送信することで、
        不正な PCP パケットが PCP 子プロセスをクラッシュさせたり、サーバで out of memory を発生させることが可能でした。
        </para>
      </listitem>
      <listitem>
      <!--
        2016-03-26 [d1c03f2]  Fix pgpool_setup to not confuse log output
        -->
        <para>
        <!--
         Fix <link linkend="PGPOOL-SETUP">pgpool_setup </link> to not confuse log output. (Tatsuo Ishii)
         -->
         <link linkend="PGPOOL-SETUP">pgpool_setup</link>がログ出力を混乱させないように修正しました。(Tatsuo Ishii)
        </para>
        <para>
        <!--
         Before it simply redirects the stdout and stderr of pgpool process to
         a log file. This could cause log contents being garbled or even
         missed because of race condition caused by multiple process being
         writing concurrently.
         -->
         以前は <productname>Pgpool-II</productname> プロセスの stdout および stderr
         は単にログファイルにリダイレクトされていました。
         これは複数プロセスが同時に書き込みを行うため競合が発生し、
         ログの文字化けや消失の原因となっていました。
         </para>

         <para>
         <!--
         To fix this, <link linkend="PGPOOL-SETUP">pgpool_setup </link> now generates startall script so that pgpool
         now sends stdout/stderr to cat command and cat writes to the log file
         (It seems the race condition does not occur when writing to a pipe).
         -->
         このため、<link linkend="PGPOOL-SETUP">pgpool_setup </link>
         が生成する startall スクリプトでは、<productname>Pgpool-II</productname>
         は stdout/stderr を cat コマンドにパイプで送信し、
         cat がログファイルの書き込みを行うように修正されました。
（パイプに書き込む際にはこの競合状態は発生しないようです）
        </para>
      </listitem>
      <listitem>
      <!--
        2016-03-07 [e55c230]  Fix for [pgpool-general: 4519] Worker Processes Exit and Are Not Re-spawned
        -->
        <para>
        <!--
	    Fix for <ulink url="http://www.pgpool.net/pipermail/pgpool-general/2016-March/004577.html">
	    [pgpool-general: 4519]</ulink> Worker Processes Exit and Are Not Re-spawned. (Muhammad Usama)
        -->
<ulink url="http://www.pgpool.net/pipermail/pgpool-general/2016-March/004577.html">[pgpool-general: 4519]</ulink> により報告されたワーカープロセスが終了し再生成されなくなる不具合を修正しました。(Muhammad Usama)
        </para>
        <para>
        <!--
        The problem was due to a logical mistake in the code for checking the exiting
        child process type when the watchdog is enabled.
        I have also changed the severity of the message from FATAL to LOG, emitted
        for child exits due to max connection reached.
        -->
        この問題は watchdog が有効のときに終了した子プロセスのタイプをチェックするコードにロジック間違いがあったのが原因でした。
        また、接続が max connection に達して子プロセスが終了する際に出力されるメッセージの重要度を FATAL からLOG に変更されました。
        </para>
      </listitem>
      <listitem>
      <!--
        2016-03-04 [67ac541]  Fix pgpool hung after receiving error state from backend
        -->
        <para>
        <!--
	    Fix pgpool hung after receiving error state from backend. (bug #169) (Tatsuo Ishii)
        -->
バックエンドからエラー状態を受信した後のハングを修正しました。 (bug #169) (Tatsuo Ishii)
        </para>
        <para>
        <!--
        This could happend if we execute an extended protocol query and it fails.
        -->
        これは拡張プロトコル問い合わせを実行しそれが失敗したときに発生し得ました。
        </para>
      </listitem>
      <listitem>
      <!--
        2016-03-03 [bb295a2]  Fix query stack problems in extended protocol case.
        -->
        <para>
        <!--
	    Fix query stack problems in extended protocol case. (bug 167, 168) (Tatstuo Ishii)
        -->
        ストリーミングレプリケーションモードで拡張プロトコル問い合わせを使用したときに
        スタックが発生する問題を修正しました。(bug 167, 168) (Tatsuo Ishii)
        </para>
        <para>
        </para>
      </listitem>
      <listitem>
      <!--
        2016-03-03 [63a0b70]  Fix yet another reset query stuck problem
        -->
        <para>
        <!--
	    Fix <ulink url="http://www.pgpool.net/pipermail/pgpool-hackers/2016-March/001440.html">
        [pgpool-hackers: 1440]</ulink> yet another reset query stuck problem. (Tatsuo Ishii)
        -->
	    <ulink url="http://www.pgpool.net/pipermail/pgpool-hackers/2016-March/001440.html">
        [pgpool-hackers: 1440]</ulink> により報告されたリセットクエリがスタックする問題を修正しました。(Tatsuo Ishii)
        </para>
        <para>
        <!--
        After receiving X message from frontend, if <productname>Pgpool-II</productname> detects EOF on
        the connection before sending reset query, <productname>Pgpool-II</productname> could wait for
        backend which had not received the reset query. To fix this, if EOF
        received, treat this as FRONTEND_ERROR, rather than ERROR.
        -->
        フロントエンドから 'X' メッセージを受信した後、リセットクエリ送信前に <productname>Pgpool-II</productname> が
        EOF をその接続で検出すると、<productname>Pgpool-II</productname>
        がリセットクエリを受信していないバックエンドからの応答を待ち続けることがありました。
        EOF を受信した場合には、これを ERROR ではなく FRONTEND_ERROR として扱うことで修正しました。
        </para>
      </listitem>
      <listitem>
      <!--
        2016-02-22 [f1cfeb6]  Yet another reset query stuck problem fix. [pgpool-general: 4265]
        -->
        <para>
        <!--
	    Fix for <ulink url="http://www.pgpool.net/pipermail/pgpool-general/2015-December/004323.html">
	    [pgpool-general: 4265]</ulink> another reset query stuck problem. (Muhammad Usama)
        -->
	    <ulink url="http://www.pgpool.net/pipermail/pgpool-general/2015-December/004323.html">[pgpool-general: 4265]</ulink>
        より報告されたリセットクエリがスタックする問題を修正しました。(Muhammad Usama)
        </para>
        <para>
        <!--
        The solution is to report FRONTEND_ERROR instead of simple ERROR when
        pool_flush on front-end socket fails.
        -->
        フロントエンドソケットにおける pool_flush が失敗したときには、ERRORではなく FRONTEND_ERROR を発生させることで解決しました。
        </para>
      </listitem>
      <listitem>
      <!--
        2016-02-12 [c50f357] Fixing pgpool-recovery module compilation issue with PostgreSQL 9.6
        -->
        <para>
        <!--
	    Fixing pgpool-recovery module compilation issue with <productname>PostgreSQL</productname> 9.6. (Muhammad Usama)
        -->
<productname>PostgreSQL</productname> 9.6における pgpool-recovery モジュールのコンパイルエラーを修正しました。(Muhammad Usama)
        </para>
        <para>
        <!--
        Incorporating the change of function signature for
        <function>GetConfigOption()</function> functions in <productname>PostgreSQL</productname> 9.6
        -->
        <productname>PostgreSQL</productname> 9.6 の <function>GetConfigOption()</function>
        関数の関数定義の変化に対応しました。
        </para>
      </listitem>
      <listitem>
      <!--
        2016-02-03 [48e9d4b]  Fix for [pgpool-II 0000166]: compile issue on freebsd
        -->
        <para>
        <!--
            Fix compile issue on freebsd. (Muhammad Usama)
        -->
            FreeBSD でのコンパイルエラーを修正しました。(Muhammad Usama)
        </para>
        <para>
        <!--
        Add missing include files. The patch is contributed by
        the bug reporter and enhanced a little by me.
        -->
        不足していた include ファイルを追加しました。
        パッチはバグ報告者によって作成され、Usama により改善されました。
        </para>
      </listitem>
      <listitem>
      <!--
        2016-02-01 [6688332]  Fix regression test to check timeout of each test
        -->
        <para>
        <!--
	    Fix regression test to check timeout of each test. (Yugo Nagata)
        -->
        個々のテストのタイムアウトをチェックできるようレグレッションテストを修正しました。(Yugo Nagata)
        </para>
      </listitem>

    </itemizedlist>

  </sect2>

</sect1>

