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

<sect1 id="release-3-6-5">
  <title>Release 3.6.5</title>

  <note>
    <title>Release Date</title>
    <simpara>2017-07-11</simpara>
  </note>

  <sect2>
    <title>Bug fixes</title>

    <itemizedlist>
    <listitem>
    <!--
    2017-07-07 [33fd84c]
    -->
    <para>
    Fix for <ulink url="http://www.sraoss.jp/pipermail/pgpool-hackers/2017-June/002400.html">[pgpool-hackers: 2400]</ulink> Garbage output (Muhammad Usama)
    </para>
    <para>
    Mostly the log messages fixes and few code cleanups.
    </para>
    </listitem>

    <listitem>
    <!--
    2017-06-29 [85392b8]
    -->
    <para>
    Importing the latest changes in the <productname>MemoryManager API</productname> from <productname>PostgreSQL</productname> code. (Muhammad Usama)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-06-24 [2ad4abd]
    -->
    <para>
    Fixing 0000306: Pgpool steals back MASTER status.  <ulink url="http://www.pgpool.net/mantisbt/view.php?id=306">(bug 306)</ulink> (Muhammad Usama)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-06-21 [045e516]
    -->
    <para>
    Fixing  <ulink url="http://www.sraoss.jp/pipermail/pgpool-hackers/2017-June/002390.html">[pgpool-hackers: 2390]</ulink>Problems with the relative paths in daemon mode (Muhammad Usama)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-06-19 [16db1f1]
    -->
    <para>
    Adjust function name change in <productname>PostgreSQL</productname> 10 dev head. (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>
    Fix a posible hang with streaming replication and extended protocol. (Yugo Nagata)
    </para>

    <para>
    This hang occured under a certain condition. The following is an example.
    </para>

    <programlisting>
    - pgpool.conf is configured so that all read queries are sent to the standby.
    - First, issue a writing query in a transaction block
    - After commiting the transaction, issue a select query.
    - When processing the query, send Describe (statement) message just after Parse.
    </programlisting>

    <para>
    Without using <productname>JDBC</productname>, we can reproduce the problem by <productname>pgproto</productname> with the followeing messages.
    </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>
    To fix it, <function>parse_before_bind()</function> should be called only if we are in a transaction block so that we can send <command>Bind</command> and <command>Execute</command> to the right backend.
    </para>
    </listitem>

    <listitem>
    <!--
    2017-06-07 [204b08e]
    -->
    <para>
    Fix <productname>Pgpool-II</productname> hang when used by <productname>erlang</productname> applications. (Tatsuo Ishii)
    </para>
    <para>
    <productname>Erlang</productname> client sends "Describe" message followed by "Flush".  So the
    backend returns "Row description." However <productname>Pgpool-II</productname> forgets to reset
    the query in progress flag upon receiving "Row description" message,
    then <productname>Pgpool-II</productname> keeps on waiting for response from backend. This is the
    cause of erlang client hanging.
    </para>
    <para>
    Fix is, just reset the query in progress flag upon receiving "Row
    description" message. Same thing can be said to "no data" message.
    </para>
    <para>
    See <ulink url="http://www.pgpool.net/pipermail/pgpool-general/2017-June/005613.html">[pgpool-general: 5555]</ulink> for more details.
    </para>
    </listitem>

    <listitem>
    <!--
    2017-06-07 [e310167]
    -->
    <para>
    Fix bug with sending bind message to wrong target node. (<ulink url="https://www.pgpool.net/mantisbt/view.php?id=314">bug 314</ulink>) (Tatsuo Ishii)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-05-31 [bc84c0b]
    -->
    <para>
    Fix query cache hang when used by node.js. (Tatsuo Ishii)
    </para>
    <para>
    See <ulink url="http://www.pgpool.net/pipermail/pgpool-general/2017-May/005569.html">[pgpool-general: 5511]</ulink> for more details.
    </para>
    </listitem>

    <listitem>
    <!--
    2017-05-28 [6e6b022]
    -->
    <para>
    Deal with <productname>PostgreSQL</productname> 10 in streaming replication delay checking. (Tatsuo Ishii)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-05-27 [e4f37e4]
    -->
    <para>
    Fix query cache memory leak. (Tatsuo Ishii)
    </para>
    <para>
    Clearing cache buffers in case of no oid queries (like <command>BEGIN</command>,
    <command>CHECKPOINT</command>, <command>VACUUM</command>, etc) should have been done, but it did not.
    </para>
    </listitem>

    <listitem>
    <!--
    2017-05-23 [f1b8877]
    -->
    <para>
    Fix extended query hang in certain case. (Tatsuo Ishii)
    </para>
    <para>
    <productname>errlang</productname> PostgreSQL API produces <command>Parse ('P')</command>, <command>Describe ('D')</command>,
    <command>Flush ('H')</command>, <command>Bind ('B')</command>, and <command>Execute ('E')</command>. Notice the 'H' message (this
    does not happen in <productname>JDBC</productname>. I suspect that's the reason why this problem
    is not popular before). After that, <productname>Pgpool-II</productname> dropped the extended
    query mode, it failed to find which backend to read data. Thus <productname>Pgpool-II</productname> simply tries to read all of backend which causes hang
    because it may have not send a message to some of backends.
    </para>
    <para>
    Solution is, after receiving the flush message set doing extended query flag.
    </para>
    </listitem>

    <listitem>
    <!--
    2017-05-23 [512fbae]
    -->
    <para>
    Fix for <ulink url="http://www.pgpool.net/pipermail/pgpool-hackers/2017-May/002354.html">[pgpool-hackers: 2354]</ulink> segfault with <command>pg_md5</command>. (Muhammad Usama)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-05-31 [02ad737]
    2017-05-17 [6fe79be]
    -->
    <para>
    Fix descriptions of <function>white/black_memcache_table_list</function>. (Tatsuo Ishii)
    </para>
    <para>
    They are far from actual implementations.
    </para>
    <para>
    See <ulink url="http://www.sraoss.jp/pipermail/pgpool-general/2017-May/005537.html">[pgpool-general: 5479]</ulink> for more details.
    </para>
    </listitem>

    <listitem>
    <!--
    2017-05-10 [c901024]
    -->
    <para>
    Fix corner case bug in <productname>Pgpool-II</productname> starting up. (Tatsuo Ishii)
    </para>
    <para>
    It is possible that a failover request is accepted before primary node
    is searched.  This leads <productname>Pgpool-II</productname> to a strange state: there's no
    primary node if the failed node was a primary node (even if new
    primary node exists as a result of promotion of existing standby).
    </para>

    <para>
    See <ulink url="http://www.pgpool.net/pipermail/pgpool-hackers/2017-May/002321.html">[pgpool-hackers: 2321]</ulink> for more details.
    </para>
    </listitem>
    </itemizedlist>
  </sect2>
</sect1>

<sect1 id="release-3-6-4">
  <title>Release 3.6.4</title>

  <note>
    <title>Release Date</title>
    <simpara>2017-05-11</simpara>
  </note>

  <sect2>
    <title>Bug fixes</title>

    <itemizedlist>

    <listitem>
    <!--
    2017-05-10 [c99e0fc]
    -->
    <para>
    Fixing a few corner cases in the failover request handling of the watchdog. (Muhammad Usama)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-05-10 [ee0a415]
    -->
    <para>
    Tightening up the watchdog cluster membership criteria. (Muhammad Usama)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-05-10 [54aa688]
    -->
    <para>
    Enhance document for load balancing. (Tatsuo Ishii)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-05-08 [eb83f0b]
    -->
    <para>
    Add node 0 failover test. (Tatsuo Ishii)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-05-04 [2b0edb1]
    -->
    <para>
    Fix <productname>Pgpool-II</productname> child process segfault reported in <ulink url="http://www.sraoss.jp/pipermail/pgpool-hackers/2017-May/002312.html">[pgpool-hackers: 2312]</ulink>. (Tatsuo Ishii)
    </para>
    </listitem>
    </itemizedlist>
  </sect2>
</sect1>

<sect1 id="release-3-6-3">
  <title>Release 3.6.3</title>

  <note>
    <title>Release Date</title>
    <simpara>2017-04-28</simpara>
  </note>

  <sect2>
    <title>Bug fixes</title>

    <itemizedlist>
    <listitem>
    <!--
    2017-04-18 [b8eb551]
    -->
    <para>
    Fix "show pool_cache" segfault when memcached is used.
     <ulink url="http://www.pgpool.net/mantisbt/view.php?id=301">(Bug 301)</ulink> (Tatsuo Ishii)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-04-14 [bedb509]
    -->
    <para>
    Fix for some more code warnings. (Muhammad Usama)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-04-14 [8b25ca3]
    -->
    <para>
    Fixing some annoying compiler warnings. (Muhammad Usama)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-04-14 [50fb9a4]
    -->
    <para>
    Removing the function defined but not used warnings from pool_config_vatiable.c (Muhammad Usama)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-04-14 [9007558]
    -->
    <para>
    Removing the references of obsolete debug_level configuration parameter. (Muhammad Usama)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-04-12 [7105243]
    -->
    <para>
    Fixing a mistake in the watchdog code. (Muhammad Usama)
    </para>
    <para>
    commit also adds some debug messages in the watchdog code.
    </para>
    </listitem>

    <listitem>
    <!--
    2017-04-12 [f5f42be]
    -->
    <para>

     Fix for 0000299: Errors on the reloading of configuration.
     <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>
    Add pgpool_adm English and Japanese docs. (Tatsuo Ishii)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-04-11 [a6cc0c9]
    -->
    <para>
    Fix document indentation. (Tatsuo Ishii)
    </para>
    <para>

    </para>
    </listitem>

    <listitem>
    <!--
    2017-04-11 [2997b3a]
    -->
    <para>
    Fix for 0000289: Inconsistent backend state.
     <ulink url="http://www.pgpool.net/mantisbt/view.php?id=289">(Bug 289)</ulink> (Muhammad Usama)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-03-30 [be9d634]
    -->
    <para>
    Enhancing the handling of split-brain scenario by the watchdog. (Muhammad Usama)
    </para>
    <para>
    Previously, the watchdog cluster was used to call for re-election of the
    master/coordinator node whenever the split-brain situation was detected. And
    consequently every node was required to rejoin the watchdog network, Which was
    essentially similar to the re-booting of the whole watchdog cluster.
    </para>
    <para>
    The candidate for the master/coordinator node is selected on the following criteria.

    </para>
    <para>
    1-- When two watchdog nodes are claiming to be the cluster master, the master
    node that has performed the escalation keeps the master status and the other
    node is asked to step down.
    </para>
    <para>

    2-- If the conflict could not be resolved by the escalation status of the nodes,
    The node which holds the quorum remains the master/coordinator.
    </para>
    <para>

    3-- If the quorum status of both contenders is also same. The node with higher
    number of connected alive nodes get the preference.
    </para>
    <para>

    4-- Finally, if all above three yields no winner, the older master (The node
    that has the coordinator status for longer duration) remains the master.
    </para>
    </listitem>

    <listitem>
    <!--
    2017-03-21 [deaa822]
    -->
    <para>
    Enhancing the watchdog internal command mechanism to handle multiple concurrent commands. (Muhammad Usama)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-04-07 [e989242]
    -->
    <para>
    Fix compiler warnings. (Tatsuo Ishii)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-04-06 [d87f93d]
    -->
    <para>
    Comment out unsupported Java method in new JDBC drivers to prevent regression failure. (Tatsuo Ishii)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-04-05 [e5541d7]
    -->
    <para>
    Downgrade parse before bind log message to debug1. (Tatsuo Ishii)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-04-04 [aa4e308]
    2017-04-04 [24d9770]
    2017-04-03 [7d8482a]
    -->
    <para>
    Fix coverity warnings. (Tatsuo Ishii, Muhammad Usama)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-03-31 [c4f816b]
    -->
    <para>
    Fix for <ulink url="http://www.sraoss.jp/pipermail/pgpool-general/2017-March/005454.html">[pgpool-general: 5396]</ulink> pam ldap failure. (Muhammad Usama)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-03-31 [6899b7d]
    -->
    <para>
    Mention that SQL type commands cannot be used in extended query mode. (Tatsuo Ishii)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-03-31 [9cd2f8a]
    -->
    <para>
    Consider SHOW command as kind of a read query. (Tatsuo Ishii)
    </para>
    <para>
    In streaming replication mode, if SHOW is issued then subsequent
    SELECTs are sent to the primary node in an explicit transaction. This
    is not a reasonable and unnecessary limitation.

    Also fix hang when parse command returns error.

    </para>
    </listitem>

    <listitem>
    <!--
    2017-03-30 [9aaec32]
    -->
    <para>
    Fix memory leak problem caused by commit adcb636. (Tatsuo Ishii)
    </para>
    <para>
    Commit adcb636 introduces "pending message queue". When a message
    arrives, the info is added to the queue and a copy of object is
    created at the same time, but forgot to free the object. Fix is,
    creating a new function pool_pending_message_free_pending_message()
    and call it after pool_pending_message_add(),
    pool_pending_message_get() and pool_pending_message_pull_out().

    Problem reported by Sergey Kim.

    </para>
    </listitem>

    <listitem>
    <!--
    2017-03-29 [18f9501]
    -->
    <para>
    Mega patch to fix "kind mismatch" (or derived) errors in streaming replication mode.
     <ulink url="http://www.pgpool.net/mantisbt/view.php?id=271">(Bug 271)</ulink> (Tatsuo Ishii)
    </para>
    <para>
    The errors are caused by wrong prediction in which (or both) database
    node will send response to Pgpool-II. Previous implementation using
    "sync map" are weak and sometimes fail in the prediction.

    </para>
    <para>
    This patch introduces new implementation using "pending message
    queue", which records all sent message to backends. The element of the
    queue stores info regarding messages types
    (parse/bind/execute/describe/close/sync), to which database node the
    message was sent and so on. It's a simple FIFO queue. When a message
    arrives from backend, by looking at the head of the "pending message
    queue", it is possible to reliably predict what kind of message and
    from which database node it will arrive. After receiving the message,
    the element is removed from the queue.
    </para>
    <para>

    I would like to thank to Sergey Kim, who has been helping me in
    testing series of patches.

    </para>
    <para>
    See <ulink url="http://www.pgpool.net/mantisbt/view.php?id=271">Bug 271</ulink>
    and discussion in pgpool-hackers mailing list
    <ulink url="http://www.sraoss.jp/pipermail/pgpool-hackers/2017-February/002043.html">[pgpool-hackers: 2043]</ulink> and
    <ulink url="http://www.sraoss.jp/pipermail/pgpool-hackers/2017-March/002140.html">[pgpool-hackers: 2140]</ulink>
     for more details.

    </para>
    </listitem>

    <listitem>
    <!--
    2017-03-24 [c2a0cc5]
    -->
    <para>
    Fix for 0000296: PGPool v3.6.2 terminated by systemd because the service Type has been set to 'forking'.
    <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>Release 3.6.2</title>

  <note>
    <title>Release Date</title>
    <simpara>2017-03-17</simpara>
  </note>

  <sect2>
    <title>Bug fixes</title>

    <itemizedlist>

    <listitem>
    <!--
    2017-03-17 [ba1bcc3]
    -->
    <para>
    Add "Wants=network.target" to pgpool.service file.
    (<ulink url="http://www.pgpool.net/mantisbt/view.php?id=294">bug 294</ulink>) (Bo Peng)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-03-09 [1ddb7f1]
    -->
    <para>
    Fix  <link linkend="PCP-PROMOTE-NODE">pcp_promote_node</link> bug that fails promoting node 0. (Yugo Nagata)
    </para>
    <para>
    The master node could not be promoted by pcp_promote_node with
    the following error;
    </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>
    In streaming replication mode, there is a case that Pgpool-II
    regards the status of primary node as "standby" for some reasons,
    for example, when pg_ctl promote is executed manually during
    Pgpool-II is running, in which case, it seems to Pgpool-II
    that the primary node doesn't exist.
    </para>

    <para>
    This status mismatch should be fixe by pcp_promote_node, but when the node
    is the master node (the first alive node), it fails as mentioned above.
    </para>

    <para>
    The reason is as following. before changing the status, pcp_promote_node
    checks if the specified node is already primary or not by comparing the
    node id with PRIMARY_NODE_ID. However, if the primary doesn't exist from
    Pgpool-II's view, PRIMARY_NODE_ID is set to 0, which is same as MASTER_NODE_ID.
    Hence, when the master node is specified to be promoted, pcp_promote_node
    is confused that this node is already primary and doesn't have to be
    promoted, and it exits with the error.
    </para>

    <para>
    To fix this, pcp_promote_node should check the node id by using
    REAL_PRIMARY_NODE_ID, which is set -1 when the primary doesn't exist,
    rather than PRIMARY_NODE_ID.

    </para>
    </listitem>

    <listitem>
    <!--
    2017-02-28 [b1060bd]
    2017-01-10 [1e4e494]
    2017-02-09 [767eff3]
    -->
    <para>
    Fix document error. (Tatsuo Ishii, Bo Peng)
    </para>
    <para>

    </para>
    </listitem>

    <listitem>
    <!--
    2017-02-23 [2b7217e]
    -->
    <para>
    <productname>Pgpool-II</productname>should not perform ping test after bringing down the VIP. (Muhammad Usama)
    </para>

    <para>
    This issue was reported by the reporter of
    bug:[pgpool-II 0000249]: watchdog sometimes fails de-escalation
    </para>
    </listitem>

    <listitem>
    <!--
    2017-02-23 [7ed400b]
    -->
    <para>
    Fix to release shared memory segments when <productname>Pgpool-II</productname>exits. (<ulink url="http://www.pgpool.net/mantisbt/view.php?id=272">bug 272</ulink>) (Tatsuo Ishii)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-02-14 [c1cd41c]
    -->
    <para>
    Fix for  <ulink url="http://www.pgpool.net/pipermail/pgpool-general/2017-February/005373.html">[pgpool-general: 5315]</ulink> pg_terminate_backend (Muhammad Usama)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-02-06 [8fa731a]
    -->
    <para>
    Adding the missing ExecStop and ExecReload commands to the systemd service configuration file. (Muhammad Usama)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-01-30 [6362ba6]
    -->
    <para>
    Fix for 281: "segmentation fault" when execute <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>
    Fix load balancing bug in streaming replication mode. (Tatsuo Ishii)
    </para>
    <para>
    In an explicit transaction, any SELECT will be load balanced until
    write query is sent. After writing query is sent, any SELECT should be
    sent to the primary node. However if a SELECT is sent before a sync
    message is sent, this does not work since the treatment of writing
    query is done after ready for query message arrives.
    </para>
    <para>
    Solution is, the treatment for writing query is done in executing the writing query as well.
    </para>

    <para>
    The bug has been there since V3.5.
    </para>
    </listitem>

    <listitem>
    <!--
    2017-01-30 [8371649]
    -->
    <para>
    Fix yet another kind mismatch error in streaming replication mode. (Tatsuo Ishii)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-01-27 [4f98bf0]
    -->
    <para>
    Fix <function>do_query()</function>hangs after close message. (Tatsuo Ishii)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-01-27 [7512482]
    -->
    <para>
    Fixing stack smashing detected. (<ulink url="http://www.pgpool.net/mantisbt/view.php?id=280">bug 280</ulink>) (Muhammad Usama)
    </para>
    <para>
    It was a buffer overflow in <function>wd_get_cmd</function> function

    </para>
    </listitem>

    <listitem>
    <!--
    2017-01-19 [839a709]
    -->
    <para>
    Fixing the issue with the watchdog process restart. (Muhammad Usama)
    </para>
    <para>
    When the watchdog process gets abnormally terminated because of some problem
    (e.g. Segmentation fault) the new spawned watchdog process fails to start and
    produces an error "bind on ... failed with reason: Address already in use".
    </para>
    <para>
    Reason is the abnormally terminating watchdog process never gets the time to
    clean-up the socket it uses for IPC and the new process gets an error because
    the socket address is already occupied.
    </para>

    <para>
    Fix is, the Pgpool main process sets the flag in shared memory to mark the
    watchdog process was abnormally terminated and at startup when the watchdog
    process see that the flag is set, it performs the clean up of the socket file and
    also performs the de-escalation (If the watchdog process was crashed when it
    was master/coordinator node) if required before initializing itself.
    </para>
    </listitem>

    <listitem>
    <!--
    2017-01-19 [779d029]
    -->
    <para>
    Fix query cache bug reported in  <ulink url="http://www.pgpool.net/pipermail/pgpool-general-jp/2017-January/001440.html">pgpool-general-jp:1441</ulink>. (Tatsuo Ishii)
    </para>
    <para>
    In streaming replication mode with query cache enabled, SELECT hangs
    in the following scenario:
    </para>

    <programlisting>
    1) a SELECT hits query cache and returns rows from the query cache.
    2) following SELECT needs to search meta data and it hangs.
    </programlisting>

    <para>
    In #1, while returning the cached result, it misses to call
    pool_unset_pending_response(), which leave the pending_response flag
    be set. In #2, do_query() checks the flag and tries to read pending
    response from backend. Since there's no pending data in backend, it
    hangs in reading data from backend.
    </para>

    <para>
    Fix is, just call <function>pool_unset_pending_response()</function> in #1 to reset the
    flag.
    </para>

    <para>
    Bug report and fix provided by Nobuyuki Nagai.

    New regression test item (068) added by me.
    </para>

    </listitem>

    <listitem>
    <!--
    2017-01-11 [29b61eb]
    -->
    <para>
    Remove elog/ereport calls from signal handlers. (Tatsuo Ishii)
    </para>
    <para>
    See  <ulink url="http://www.pgpool.net/pipermail/pgpool-hackers/2016-December/001950.html">[pgpool-hackers: 1950]</ulink> for details.
    </para>
    </listitem>

    <listitem>
    <!--
    2017-01-10 [39d24e7]
    -->
    <para>
    Fix bug failed to create INET domain socket in FreeBSD if listen_addresses = '*'.
    (<ulink url="http://www.pgpool.net/mantisbt/view.php?id=202">bug 202</ulink>) (Bo Peng)
    </para>
    </listitem>

    <listitem>
    <!--
    2017-01-04 [8598d5a]
    -->
    <para>
    Fix for 0000249: watchdog sometimes fails de-escalation. (<ulink url="http://www.pgpool.net/mantisbt/view.php?id=249">bug 249</ulink>) (Muhammad Usama)
    </para>

    <para>
    The solution is to use the <function>waitpid()</function> system call without WNOHANG option.

    </para>
    </listitem>

    <listitem>
    <!--
    2017-01-04 [bd92a11]
    -->
    <para>
    Fix connection_life_time broken by authentication_timeout. (Yugo Nagata)
    </para>
    </listitem>

    <listitem>
    <!--
    2016-12-28 [afebadf]
    -->
    <para>
    Fix authentication timeout that can occur right after client connecttions. (Yugo Nagata)
    </para>
    </listitem>

    </itemizedlist>

  </sect2>

</sect1>

<sect1 id="release-3-6-1">
  <title>Release 3.6.1</title>

  <note>
    <title>Release Date</title>
    <simpara>2016-12-26</simpara>
  </note>

  <sect2>
    <title>Bug fixes</title>

    <itemizedlist>

      <listitem>
	<!--
	    2016-12-23 [4124e5e]
	  -->
	<para>
      Tightening up the watchdog security. (Muhammad Usama)
    </para>

    <para>
      Now wd_authkey uses the HMAC SHA-256 hashing.
	</para>
      </listitem>

      <listitem>
	<!--
	    2016-12-22 [f8a157a]
	  -->
	<para>
	  Add pgpool_adm extension in <productname>Pgpool-II</productname> RPM. (Bo Peng)
	</para>
      </listitem>

      <listitem>
	<!--
	    2016-12-20 [888ac16]
	  -->
	<para>
	  Fix occasional segfault when query cache is enabled. (bug 263) (Tatsuo Ishii)
	</para>
      </listitem>

      <listitem>
	<!--
	    2016-12-20 [9274f82]
	  -->
	<para>
	  Fix packet kind does not match error in extended protocol. (bug 231) (Tatsuo Ishii)
	</para>
	<para>
	  According to the bug231, the bug seem to bite you if all of
	  following conditions are met:
	</para>
	<itemizedlist>
	  <listitem>
	    <para>
	      Streaming replication mode
	    </para>
	  </listitem>
	  <listitem>
	    <para>
	      Load balance node is not 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
	    </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
	    </para>
	  </listitem>
	  <listitem>
	    <para>
	      Frontend send Close statement
	    </para>
	  </listitem>
	  <listitem>
	    <para>
	      Pgool-II forward it to backend 1
	    </para>
	  </listitem>
	  <listitem>
	    <para>
	      Frontend sends Parse, Bind, Execute of COMMIT
	    </para>
	  </listitem>
	  <listitem>
	    <para>
	      Pgool-II forward it to backend 0 & 1
	    </para>
	  </listitem>
	  <listitem>
	    <para>
	      Frontend sends sync message
	    </para>
	  </listitem>
	  <listitem>
	    <para>
	      Pgool-II forward it to backend 0 & 1
	    </para>
	  </listitem>
	  <listitem>
	    <para>
	      Backend 0 replies back Parse complete ("1"), while
	      backend 1 replies back close complete ("3") because of
	      #3.
	    </para>
	  </listitem>
	  <listitem>
	    <para>
	      Kind mismatch occurs
	    </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.
	</para>
	<para>
	  Also, fix not calling pool_set_doing_extended_query_message() when
	  receives Close message.  (I don't know why it was missed).
	</para>
	<para>
	  New regression test "067.bug231" was added.
	</para>
      </listitem>

      <listitem>
	<!--
	    2016-12-06 [336e932]
	  -->
	<para>
	  Fix a race condition in a signal handler. (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.
	</para>
	<para>
	  Ideally we should avoid calling elog in signal handlers though.
	</para>
      </listitem>

      <listitem>
	<!--
	    2016-11-24 [cc452ad]
	  -->
	<para>
	  Fix wrong minimum configuration value for 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)
	</para>
	<para>

	</para>
      </listitem>

    </itemizedlist>

  </sect2>

</sect1>


<sect1 id="release-3-6">
  <title>Release 3.6</title>

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

  <sect2>
    <title>Overview</title>

    <para>
      Major enhancements in <productname>Pgpool-II</productname> 3.6 include:
    </para>

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

    <itemizedlist>

      <listitem>
	<para>
	  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>
      </listitem>

      <listitem>
	<para>
	  New PGPOOL SET command has been introduced. Certain
	  configuration parameters now can be changed on the fly in a
	  session.
	</para>
      </listitem>

      <listitem>
	<para>
	  Watchdog is significantly enhanced. It becomes more reliable
	  than previous releases.
	</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.
	</para>
      </listitem>

      <listitem>
	<para>
	  Import parser of PostgreSQL 9.6.
	</para>
      </listitem>

      <listitem>
	<para>
	  In some cases pg_terminate_backend() now does not trigger a
	  fail-over.
	</para>
      </listitem>

      <listitem>
	<para>
	  Change documentation format from raw HTML to SGML.
	</para>
      </listitem>

    </itemizedlist>

    <para>
      The above items are explained in more detail in the sections below.
    </para>

  </sect2>

  <sect2>
    <title>Major Enhancements</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)
	</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.
	</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.
	</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:
	</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.
	</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)
	</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.
	</para>
	<para>
	  Currently supported configuration parameters by PGPOOL
	  SHOW/SET/RESET are: <xref linkend="guc-log-statement">,
	  <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. (bug 218) (Muhammad Usama)
	</para>
	<para>
    Watchdog does not synchronize status.
	</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)
	</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.
	</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.
	</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)
	</para>
	<para>
	  This allows <productname>Pgpool-II</productname> to fully
	  understand the newly added SQL syntax such as <literal>COPY
	  INSERT RETURNING</literal>.
	</para>
      </listitem>

      <listitem>
	<!--
	    2016-08-26 [f284be4] Handling of pg_terminate_backend for simple query protocol
	  -->
	<para>
	  In some cases <function>pg_terminate_backend()</function> now does not trigger a fail-over. (Muhammad Usama)
	</para>
	<para>
    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.
    </para>
    <para>
    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.
    </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)
	</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!
	</para>
      </listitem>

    </itemizedlist>
  </sect2>

  <sect2>
    <title>Other Enhancements</title>

    <itemizedlist>

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

	<para>
	  Make authentication error message more user friendly. (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'"
	</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)
	</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)
	</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.
	</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)
	</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>.
	</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)
	</para>
	<para>
	  This column
	  shows the <link linkend="runtime-streaming-replication-check">
	  replication delay</link> value in bytes if operated in
	  streaming replication mode.
	</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)
	</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.
	</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)
	</para>
	<para>
	  By replacing TLSv1_method() with SSLv23_method() while
	  initializing the SSL session, we can use more protocols than
	  TLSv1 protocol.
	</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)
	</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)
	</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.
	  </para>
	<para>
	  Before such that query was recognized an error.
	</para>
      </listitem>

      <listitem>
	<!--
	    2016-02-01 [342471f] Add some warning messages for wd_authkey hash calculation failure
	  -->
	<para>
	  Add some warning messages for wd_authkey hash calculation failure. (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.
	</para>
      </listitem>

    </itemizedlist>

  </sect2>

  <sect2>
    <title>Changes</title>

    <itemizedlist>
      <listitem>
        <!--
            2016-11-09 [f6ec434] Fix the broken log_destination = syslog functionality.
        -->
        <para>
        Fix the broken log_destination = syslog functionality. (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.
        </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)
			</para>
			<para>
            Prior default value 10 seconds is sometimes too short for a standby to
            be promoted.
			</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)
			</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)
			</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.
            </para>
      </listitem>
      <listitem>
            <!--
		        2016-04-15 [9b62eca] Redirect all user queries to primary server
            -->
            <para>
			    Redirect all user queries to primary server. (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.
            </para>
      </listitem>
    </itemizedlist>
  </sect2>

  <sect2>
    <title>Bug fixes</title>

    <itemizedlist>
      <listitem>
      <!--
      2016-11-14 [266b67a]  Fixing a potential crash in pool_stream functions.
      -->
      <para>
      Fixing a potential crash in pool_stream functions. (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.
      </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. (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>.
      </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.
      </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)
        </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.
        </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)
        </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.
        </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)
        </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)
        </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)
        </para>
        <para>
        <function>random()</function> should not be used in security related applications.  To
        replace <function>random()</function>, import <function>PostmasterRandom()</function> from PostgreSQL.  Also
        store current time at the start up of <productname>Pgpool-II</productname> main process for later
        use.
        </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)
        </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)
        </para>
        <para>
        The socket descriptor array (fds[]) was not getting the array end marker
        when TCP listen addresses are not used.
        </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)
        </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)
        </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)
        </para>
      </listitem>
      <listitem>
      <!--
        2016-08-09 [a7bc4c8] Fix hang when portal suspend received
        -->
        <para>
	    Fix hang when portal suspend received. (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)
        </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.
        </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)
        </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
        </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)
        </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.
        </para>
      </listitem>
      <listitem>
      <!--
        2016-07-29 [5bce300]  Fixing a coding mistake in watchdog code.
        -->
        <para>
        Fixing a coding mistake in watchdog code. (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.
        </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)
        </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.
        </para>
      </listitem>
      <listitem>
      <!--
        2016-07-27 [3cbce4e]  Replace "MAJOR" macro to prevent occasional failure.
        -->
        <para>
          Replace "MAJOR" macro to prevent occasional failure. (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.
        </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)
        </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.
        </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)
        </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)
        </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)
        </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>.
        </para>
      </listitem>
      <listitem>
      <!--
        2016-06-28 [bb41a1e]  Fix confusing error messages.
        -->
        <para>
        Fix that <function>pool_read()</function> does not emit error messages when <function>read(2)</function> returns -1 if
        <xref linkend="guc-fail-over-on-backend-error"> is off. (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)
        </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>.
        Problem reported by a twitter user who is using pgpool on AWS (which
        could have very long hostname).
        </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)
        </para>
        <para>
         Configuration file not found should just throw a WARNING message
         instead of ERROR or FATAL.
        </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)
        </para>
        <para>
        There are few places where the load balance node was mistakenly put on
        wrong place. It should be placed on:
        <programlisting>
ConnectionInfo *con_info[child id, connection pool_id, backend id].load_balancing_node].
        </programlisting>
        In fact it was placed on:
        <programlisting>
*con_info[child id, connection pool_id, 0].load_balancing_node].
        </programlisting>
        </para>
        <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.
        </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)
        </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.
        </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)
        </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.
        </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)
        </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).
        </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.
        </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)
        </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.
        </para>
        <para>
        Plus, pg_stat_statement will no longer show the query issued by
        do_query() as "running".
        </para>
        <para>
        Plus, pg_stat_statement will no longer show the query issued by
        <function>do_query()</function> as "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)
        </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.
        </para>
      </listitem>
      <listitem>
      <!--
        2016-05-20 [78c5d56]  Fix confusing comments in pgpool.conf
        -->
        <para>
	    Fix confusing comments in <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)
        </para>
        <para>
        Connection pool is avalilable in raw mode.
        </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)
        </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.
        </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)
        </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.
        </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)
        </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.
        </para>
      </listitem>
      <listitem>
      <!--
        2016-03-29 [f7723c8]  Validating the PCP packet length
        -->
        <para>
        Validating the PCP packet length. (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.
        </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)
        </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. I and Usama found this while investigating the
         regression failure of 004.watchdog.

         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).
        </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)
        </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.
        </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)
        </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)
        </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)
        </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.
        </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)
        </para>
        <para>
        The solution is to report FRONTEND_ERROR instead of simple ERROR when
        pool_flush on front-end socket fails.
        </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)
        </para>
        <para>
        Incorporating the change of function signature for
        <function>GetConfigOption()</function> functions in <productname>PostgreSQL</productname> 9.6
        </para>
      </listitem>
      <listitem>
      <!--
        2016-02-03 [48e9d4b]  Fix for [pgpool-II 0000166]: compile issue on freebsd
        -->
        <para>
	    Fix compile issue on freebsd. (Muhammad Usama)
        </para>
        <para>
        Add missing include files. The patch is contributed by
        the bug reporter and enhanced a little by me.
        </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)
        </para>
      </listitem>
      <listitem>
      <!--
        2016-02-01 [44f43cc]  Add some warning messages for wd_authkey hash calculation failure
        -->
        <para>
	    Add some warning messages for <xref linkend="guc-wd-authkey"> hash calculation failure. (Yugo Nagata)
        </para>
        <para>
        Sometimes <xref linkend="guc-wd-authkey"> calculation fails for some reason other than
        authkey mismatch. The additional messages make these distingushable
        for each other.
        </para>
      </listitem>

    </itemizedlist>

  </sect2>

</sect1>

