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

<sect1 id="release-3-5-9">
  <title>リリース 3.5.9</title>

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

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

    <itemizedlist>
    <listitem>
    <!--
    2017-07-07 [d845be6]
    -->
    <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 [e83a274]
    -->
    <para>
    <productname>PostgreSQL</productname>の<productname>MemoryManager API</productname>に関する最新の変更をインポートしました。(Muhammad Usama)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-06-21 [cc0b21d]
    -->
    <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 [d1013ac]
    -->
    <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 [b86e7b7]
    -->
    <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>を利用し以下のデータでこの問題を再現できます。
    </para>

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

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

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

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

    <listitem>
    <!--
    2017-05-23 [27a516a]
    -->
    <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-10 [7b2ef18]
    -->
    <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-5-8">
  <title>リリース 3.5.8</title>

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

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

    <itemizedlist>

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

    <listitem>
    <!--
    2017-05-04 [b97c38f]
    -->
    <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-5-7">
  <title>リリース 3.5.7</title>

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

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

    <itemizedlist>

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

    <listitem>
    <!--
    2017-04-12 [f99053c]
    -->
    <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-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-04-12 [ab32ae7]
    -->
    <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-04-11 [8ffd1fa]
    -->
    <para>
     複数の並行コマンドを処理するためにwatchdog内部コマンドのメカニズムを強化しました。(Muhammad Usama)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-04-12 [79f219a]
    -->
    <para>
     コードの互換性のためにboolエンコードおよびデコード関数をJSONフレームワークに追加します。(Muhammad Usama)
    </para>
    </listitem>

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

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

    <listitem>
    <!--
    2017-03-30 [4b28556]
    -->
    <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 [a504a9f]
    -->
    <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 [d726c3a]
    -->
    <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-5-6">
  <title>リリース 3.5.6</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 [5b4f78c]
     -->
    <para>
READMEに最新リリースノートへのリンクを追加しました。(Bo Peng)
    </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-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-5-5">
<!--
  <title>Release 3.5.5</title>
  -->
  <title>リリース 3.5.5</title>

  <note>
  <!--
    <title>Release Date</title>
    -->
    <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-26 [045a59f]
	  -->
	<para>
    <!--
	  Back porting the improved failover command propagation mechanism from Pgpool-II 3.6 (Muhammad Usama)
    -->
<productname>Pgpool-II</productname> 3.6 でのフェイルオーバーコマンドの転送処理の改善がバックポートされました。(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 pgpool-II.
      -->
これまでは、Pgpool-II ノードの watchdogがすべての接続されたノードにフェイルオーバーコマンド(failover、 failback 及び promote node)を転送していました。多数のノードが含まれているwatchdogクラスタでは、フェールオーバーコマンドが複数のPgpool-IIによって実行されることによって、データの同期問題を引き起こす可能性がありました。このコミットでは、すべてのフェイルオーバーコマンド(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-10-27 [f37c592]
	  -->
	<para>
    <!--
	  Do not cancel a query when the query resulted in an error other than in native replication mode. (Tatsuo Ishii)
    -->
ネイティブレプリケーションモード以外の場合、エラーが発生した場合は、クエリをキャンセルしないように修正しました。(Tatsuo Ishii)
	</para>
	<para>
    <!--
	  It was intended to keep the consistency, but there's no point in other
	  than native replication mode.
      -->
本来は一貫性を維持するためにキャンセルされるようになっていましたが、ネイティブレプリケーションモード以外の場合ではキャンセルする必要がないので、修正しました。
	</para>
      </listitem>

      <listitem>
	<!--
	    2016-10-27 [c9e203d]
	  -->
	<para>
    <!--
	  Remove obsoleted option "-c" in pgpool command. (Tatsuo Ishii)
      -->
pgpool コマンドで廃止されたオプション"-c"を削除しました。(Tatsuo Ishii)
	</para>
	<para>
    <!--
	  Also fix typo in the help message.
      -->
また、helpメッセージのタイポを修正しました。
	</para>
      </listitem>

      <listitem>
	<!--
	    2016-10-18 [8da0e7f]
	  -->
	<para>
    <!--
	  Fix for 0000252: authentication failed error when PCP command is cancelled... (Muhammad Usama)
    -->
    PCPコマンドがキャンセルされたときの認証失敗エラーが修正されました。(bug 252) (Muhammad Usama)
	</para>
      </listitem>

      <listitem>
	<!--
	    2016-09-24 [8aa7586]
	  -->
	<para>
    <!--
	  Change the default value of search_primary_node_timeout from 10 to 300. (Tatsuo 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-09-21 [b306e04]
	  -->
	<para>
    <!--
	  Fix the case when all backends are down then 1 node attached. (Tatsuo Ishii)
    -->
すべてのバックエンドがダウンした後に、1つのノードを復帰させる時の不具合が修正されました。(bug 248) (Tatsuo Ishii)
	</para>
	<para>
    <!--
	  When all backends are down, no connection is accepted. Then 1
	  PostgreSQL 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 pgpool 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-20 [a38fa09]
	  -->
	<para>
    <!--
	  Fix for: [pgpool-general: 4997] Avoiding downtime when pgpool 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 pgpool-II node and when the
	  inconsistency was found the FATAL error was thrown, now with this commit the
	  verification responsibility is delegated to the master pgpool-II 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 pgpool-II log to avoid the
	  surprises at the time of pgpool-II 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-13 [1c99580]
	  -->
	<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 [8231f65]
	  -->
	<para>
    <!--
	  Do not use random() 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-06 [891ce0f]
	  -->
	<para>
    <!--
	  Don't ignore sync message from frontend when query cache is enabled. (Tatsuo Ishii)
      -->
クエリキャッシュが有効な場合、sync メッセージが廃棄されないよう修正しました。(Tatsuo Ishii)
	</para>
      </listitem>

    </itemizedlist>

  </sect2>

</sect1>

