Add Aurora setting example.

Add description about "ALWAYS_MASTER" flag.

Fix indentation.

Support AWS Aurora.

Add new backend flag "ALWAYS_MASTER" to control the primary node
detecting logic. Since we cannot use pg_is_in_recovery() in Aurora, we
assign the new flag to a backend which is specified as "writer" in
Aurora. Since Aurora always use the same hostname for the master (it's
called "writer"), find_primary_node() just returns the node id which
has ALWAYS_MASTER flag on.

Other than that, user can use the streaming replication mode with
Aurora. Notice that replication delay cannot be performed in Aurora,
sr_check_period should be always 0.

Add 3.6.5 - 3.2.21 release-notes.

Fix for [pgpool-hackers: 2400] Garbage output

Mostly the log messages fixes and few code cleanups.

Importing the latest changes in the MemoryManager API from PostgreSQL code.

Pgpool-II has borrowed the MemoryManager from PostgreSQL source and recently
there have been some performance updates made to the PostgreSQL's
memory manager, from which Pgpool-II can also benefit from.
This need was identified by the reporter of issue: "315: High CPU usage when
commiting large transactions and using in (shared) memory cache"

Fixing 0000306: Pgpool steals back MASTER status

This is next in the series of the patches, and hopefully the last one to fix
bug where the unworthy master node gets its way while the watchdog cluster
recovers from the split - brain syndrome. It's a relatively small patch that
makes a little tweak in the area which handles the split-brain when the
split-brain is detected by one of the standby node.

Fixing: [pgpool-hackers: 2390] Problems with the relative paths in daemon mode

Pgpool-II does all the path related calculations based on CWD
(current working directory) which only works as expected and intended
until the CWD does not change.
But in daemon mode the first thing Pgpool-II do after becoming the daemon
process is, it changes it's CWD to system root ("/") and after that all the
relative paths becomes invalid.
This means in daemon mode if the pgpool.conf file is specified as an argument
using the relative path, Pgpool-II will not be able to find the pool_passwd
or other required file whose location depends on the location of pgpool.conf
file, and will eventually fail to start, or even worst may read/write
some wrong file.

The solution to this is to convert the relative path of the pgpool.conf and
all file paths provided in the argument list to the Pgpool-II to the absolute
paths at the startup and later use those absolute paths for all path related
calculations.

Apart from using the absolute paths for pgpool.conf, pcp.conf and pool_hba.conf
files, The commit also modifies the behaviour of pid_file_name configuration
parameter, when the relative path is used for this config in pgpool.conf,
that relative path is considered with relative to the pgpool.conf path,
instead of the current working directory.

Adjust function name change in PostgreSQL 10 dev head.

pg_current_wal_location -> pg_current_wal_lsn
pg_last_wal_replay_location -> pg_last_wal_replay_lsn

Fix a posible hang with streaming replication and extended protocol

This hang occured under a certain condition. The following is an example.

- 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.

Without using JDBC, we can reproduce the problem by pgproto with the followeing messages.
--------------------------------------------

'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'
---------------------------------------------

In practice, such Describe message can be sent by JDBC when executing PreparedStatement
with a parameter of timestamp type more than prepare_threshold times. In addition,
queries can be issued outside of a transaction block when autocommit is enabled.

When a writing query is issued in a transaction block, writing_transaction flag
is set, but after commiting the transaction this flag is not unset. The problem
is that parse_before_bind() is always called when writing_transaction is set.

Alhough Parse of the select and Describe following are sent to standby
due to load balancing, another Parse and Bind, Execute are to be sent to
primary due to parse_before_bind.

In this situation, Pgpool-II waits for the responces of Describe from
standby forever because any messages after Describe is not sent to the
standby and any responce is not returned.

To fix it, parse_before_bind() should be called only if we are in a transaction
block so that we can send Bind and Execute to the right backend.

Remove unnecessary log messages.

See [pgpool-hackers: 2378] Debug log

Fix Pgpool-II hang when used by erlang applications.

Erlang client sends "Describe" message followed by "Flush".  So the
backend returns "Row description." However Pgpool-II forgets to reset
the query in progress flag upon receiving "Row description" message,
then Pgpool-II keeps on waiting for response from backend. This is the
cause of erlang client hanging.

Fix is, just reset the query in progress flag upon receiving "Row
description" message. Same thing can be said to "no data" message.

Discussion: [pgpool-general: 5555]
http://www.pgpool.net/pipermail/pgpool-general/2017-June/005613.html

Fix bug with sending bind message to wrong target node.

When a close portal message received, Pgpool-II forwards it to both
primary and load balance node in streaming replication mode. Later on
a close complete message returned from backend, and
read_kind_from_backend gets called, then it calls
pool_pending_message_query_context_dest_set, which rewrites
where_to_send map in the current query context accordingly. If a bind
message using the same query is received, it will be forwarded to both
primary and load balance node because the where_to_send map was
rewritten so. Unfortunately, the prepared statement might not exist on
primary node, if the query was parsed only on the load balance
node. So we get an error.

Fix is, restoring the where_to_send map after processing the close
complete message. For this sake, where_to_send map back up area is
added to session context. Also new flag need_to_restore_where_to_send
is added. Those new data is handled inside
pool_pending_message_query_context_dest_set. The where_to_send map is
restored in pool_unset_query_in_progress. There were several places
which do not call pool_unset_query_in_progress. They are also fixed to
call it.

Per bug #314.
https://www.pgpool.net/mantisbt/view.php?id=314

To reproduce the problem, following pgproto data can be used. Also you
need to set the weight parameter on primary to 0 and standby to 1 to reliably
reproduce the problem.

'P' "S_1" "SELECT 1" 0
'B' "C_1" "S_1" 0 0    0
'E' "C_1" 0
'S'
'Y'

'C' 'P' "C_1"

'B' "C_2" "S_1" 0 0 0
'E' "C_2" 0
'S'
'Y'

'X'

Allow to fork new health check process when it exits.

Add new group "health_check" to PGPOOL SHOW command doc.

Add description about per node health check parameters.

Fix descriptions of white/black_memcache_table_list.

They are far from actual implementations.
See [pgpool-general: 5479] for more details.

Fix query cache hang when used by node.js.

node.js sends a query in following pattern:

Parse
Bind
Describe
Execute
Flush
Sync

Notice the "Flush" message. This is unnecessary message and Pgpool-II
did not prepare for it. Since Pgpool-I supposed that next message to
Execute is "Sync" in pool_fetch_from_memory_cache(), it actually read
the "Flush" message and forwarded to backend, then discarded
subsequent "Ready for query" message, which was actually a "Sync"
message. That results in no "ready for query" message from backend.

Fix is, do not have any assumption regarding messages after Execute,
instead returns to the message processing loop. This way, whatever
messages coming after Execute should be properly processed.

Following is the test data for pgproto.

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

'P' "S2" "SELECT 1 FROM pgproto_test1" 0
'B' "" "S2" 0 0 0
'D' 'S' "S2"
'E' "" 0
'H'
'C' 'S' "S2"
'S'
'Y'

'P' "S2" "SELECT 1 FROM pgproto_test1" 0
'B' "" "S2" 0 0 0
'D' 'S' "S2"
'E' "" 0
'H'
'C' 'S' "S2"
'S'
'Y'
'X'

Discussion: http://www.pgpool.net/pipermail/pgpool-general/2017-May/005569.html

Deal with PostgreSQL 10 in streaming replication delay checking.

From PostgreSQL 10 or later, some built in function names which are
used in streaming replication delay checking are changed. To deal with
this, get server_version_num from backend to change the calling
functions and cache them. Using 'S' message to extract the server
version string while connecting backend could be an idea, but
unfortunately connecting function used in streaming replication delay
checking does not handle 'S' parameter. Also converting from the
server version string to the server_version_num can be backend
dependent, so to extract the server_version_num would be safer.

Fix query cache memory leak.

Clearing cache buffers in case of no oid queries (like BEGIN,
CHECKPOINT, VACUUM, etc) should have been done, but it did not.
Patch from Dang Minh Huong.

Fix extended query hang in certain case.

While digging into "[pgpool-general: 5487] pgpool and erlang - request hangs",
http://www.pgpool.net/pipermail/pgpool-general/2017-May/005545.html
I found a certain sequence of messages which cause Pgpool-II hang.

errlang PostgreSQL API produces Parse ('P'), Describe ('D'), Flush
('H'), Bind ('B'), and Execute ('E'). Notice the 'H' message (this
does not happen in JDBC. I suspect that's the reason why this problem
is not popular before). After that, Pgpool-II dropped the extended
query mode, it failed to find which backend to read data. Thus
Pgpool-II simply tries to read all of backend which causes hang
because it may have not send a message to some of backends.

Solution is, after receiving the flush message set doing extended
query flag.

For the record, here is the pgproto data to reproduce the problem.

--------------------------------------------------------
'Q' "DROP TABLE IF EXISTS pgproto_test1"
'Y'
'Q' "CREATE TABLE pgproto_test1(i INT)"
'Y'
'Q' "INSERT INTO pgproto_test1 VALUES(1)"
'Y'

'P' "S2" "SELECT 1 FROM pgproto_test1" 0
'D' 'S' "S2"
'H'
'B' "" "S2" 0 0 0
'E' "" 0
'C' 'S' "S2"

'S'
'Y'
'X'
--------------------------------------------------------

Note that the cause of original complain seems to different from this
because it is operated in replication mode. So it needs more
investigation.

Back patched to 3.6 and 3.5 stable branches.

Fix for [pgpool-hackers: 2354] segfault with pg_md5

It was a stupid coding mistake.
Also fixing memory leak issues reported by valgrind in pg_md5 utility.

Fix debug print.

The debugging line after an if statement should be included in a curly
brance. Otherwise report wrong information.

Revert "Use volatile pointer for Req_info variable."

This reverts commit a4de4bfc1421d787b53789eb62eb7e9cb26e91c1.

Fix descriptions of white/black_memcache_table_list.

They are far from actual implementations.
See [pgpool-general: 5479] for more details.

Fix indentation.

Allow to configure health check parameters for each individual node.

This is the next in series patch to implement an infrastructure to support
per-node health check parameters, and enables all health-check related parameter
to be configured for each individual backend nodes. With this commit If the
node-id postfix is used at the end of the health-check parameter name it will
configure the parameter value for specific node-id while the same name parameter
without the node-id can still be used and its value will serve as the default
global value for the individual node parameters where the value is
not explicitly provided.

For example if we have 3 backend nodes and do following configurations.

health_check_period = 10
health_check_period0 = 5

Then will set the health_check_period for node 0 to 5 while
node-id 1 and 2 will get the value 10

Use volatile pointer for Req_info variable.

Since Req_info points to shared memory area, using volatile pointer
will allow to fetch the fresh value.

Add 3.6.4, 3.5.8 release notes.

Fixing a few corner cases in the failover request handling of the watchdog.

Watchdog keeps track of the failover requests it receives from the local and
remote Pgpool-II nodes, propagate that request to the whole cluster and trigger
the failover on local Pgpool-II. And while that failover is in progress it keep
denying the requests for similar failover (same failover kind and same
backend node) until it receives the finish failover intimation for that
failover from Pgpool-II.

But if due to some reason the failover end command is not received by watchdog,
that failover in progress status gets stuck in forever and watchdog keep
rejecting the similar failover requests until it is restarted.
To solve the failover stuck problem this commit adds the timeout to the
failover requests on watchdog side and automatically marks the failover as
finished if it does not receive the end failover intimation within
the timeout period.

Apart from above there was another issue, The functions for sending the failover
request to Pgpool-II main process had void return type and returns no indication
if the request was successfully registered or not. So that fix is also part of
the commit and now they return boolean value indicating the
request registration status.

Tightening up the watchdog cluster membership criteria.

The watchdog node should only be considered as the part of the cluster either
if it is the Master node or if it is connected to that master node as a standby.
The nodes in the transient states (which are yet in the process of joining the
Mater node) or standby having the different master record should not be
considered the part of the watchdog cluster and should not be counted in the
quorum calculation.

Before this commit every node was considered as the part of the cluster as soon
as it becomes reachable to the master watchdog node, The problem with that
philosophy was, at the time of recovering from network partitioning/split-brain
situation both cluster leaders could have similar number of reachable
nodes and deciding the rightful master becomes difficult.

Enhance document for load balancing.

Also fix primary tag in indexterm tags in "SHOW" commands. They were
just "SHOW", which should have been more specific like "SHOW
POOL_NODES".

Fix corner case bug in Pgpool-II starting up.

It is possible that a failover request is accepted before primary node
is searched.  This leads Pgpool-II 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).

See [pgpool-hackers: 2321] for more details.

Add node 0 failover test.

Previously only node 1 failover test is performed in 003.failover.

Fix pgpool child process segfault reported in [pgpool-hackers: 2312].

When MASTER macro calls, pool_virtual_master_db_node_id() which calls
pool_get_preferred_master_node_id() if there's no query context
exists. The segfault happens in deciding the load balance node while
initializing the session context in the child process starting up. The
session context is first initialized with all 0, then
pool_get_preferred_master_node_id() returns 0 as the preferred node
id. This is fine as long as node 0 is healthy. However if node 0 goes
down and failover happens, this is not fine any more since the
connection slot 0 is empty and it causes the segfault.

Fix it by removing preferred_master_node_id staffs since it seems it
is not used anymore.

Fix compile error.

Enable AM_MAINTAINER_MODE.

This allows to automatically create bison/flex derived files.  Should
be reverted once 3.7 beta released.

Add release notes.

Add 3.6.3 - 3.2.20 release note.

Add per node health check parameters and sample configurations.

This is just adding new data structure.

Implement infrastructure for supporting per node health check parameters.

Now pgpool main process forks health check process for each DB node.
Also autotools is now updated from 1.14 to 1.15.

TODO:
- Implement per node health check parameters.

Fix "show pool_cache" segfault when memcached is used.

The problem is reported in:
http://www.pgpool.net/mantisbt/view.php?id=301

pool_get_shmem_storage_stats() was mistakenly modified when 3.6 was
developed.

The bug was introduced in 3.6.0. Previous versions do not have the
problem.

Fix for some more code warnings.

uint64 definition was not uniform across the code.

Fixing some annoying compiler warnings.

Removing the function defined but not used warnings from pool_config_vatiable.c

Removing the references of obsolete debug_level configuration parameter.

configuration parameter 'debug_level' has given way to
'log_min_messages' after the adoption of exception manager.

Fixing a mistake in the watchdog code.

wrong conditional statement in the get_wd_command_from_reply() function was
making the watchdog to not reliably identify the internal command responses,
and in one case the completed watchdog internal command were not getting
cleaned up.
commit also adds some debug messages in the watchdog code.

Fix for 0000299: Errors on the reloading of configuration

Pgpool-II should load the hba_file after evaluating all the
command line options at startup.
It is wrong to load hba file before evaluating all the command line arguments,
because when the Pgpool-II is invoked with reload or stop options, all it needs
to do is to signal the running Pgpool-II and exit, So loading hba file for
Pgpool reload/stop is not only unnecessary but it also emits the misleading
WARNING message of "failed while loading hba configuration" when alternative
path for hba file was used.

Remove old html docs and related files.

Add pgpool_adm Japanese docs.

Also fix some pgpool_adm English docs.

Add installation procedure of pgpool_adm.

Add missing pgpool_adm manuals.

They were missing while migrating to SGML. Still Japanese docs need to
be updated.

Fix indentation.

Fix for 0000289: Inconsistent backend state

Pgpool-II syncs the backend node states at the time of startup which works fine
for almost all cases except when the watchdog cluster becomes partitioned
(because of some network problem) and after recovering from it the Pgpool-II
nodes (that are already up and serving) joins back the cluster. At that time the
backend node status among different nodes can become In-sync among the Pgpool-II
nodes, if the backend node status on the newly joined Pgpool-II is different
from the status on existing watchdog cluster nodes.

Now with this commit, every time the Pgpool-II node joins the watchdog cluster
as a standby either at startup or after some problem recovery, it realigns its
backend node statuses with the cluster leader, by fetching the statuses from
the master/coordinator and updating the local statuses of each backend.

The patch also borrows the logic of smart restarting of Pgpool-II children
from the failover() function to minimise the chances of session disconnection
when the backend node statuses are updated from the master/coordinator Pgpool-II.

Fix compiler warnings.

Also remove unused code.

Comment out unsupported Java method in new JDBC drivers to prevent regression failure.

That is this: Driver.setLogLevel(2);

Downgrade parse before bind log message to debug1.

This was mistakenly left at debugging. Patch provided by Sergey Kim.

Fix coverity warning CID#1373258 "Uninitialized scalar variable"

Fix coverity reported issues of buffer overrun.

Per coverity CID#1332216, CID#1332218, CID#1373253, CID#1373254 and CID#1373255

Fix coverity warnings.

Fix for [pgpool-general: 5396] pam ldap failure

Do not use Palloc and friends to allocate memory for pam_response in the
PAM conversation function, Since that memory is freed by PAM library who
knows nothing about our MemoryManager and can cause the segmentation fault.

Mention that SQL type commands cannot be used in extended query mode.

Consider SHOW command as kind of a read query.

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.

Fix memory leak problem caused by commit adcb636.

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 forgoto 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.

Enhancing the handling of split-brain scenario by the watchdog.

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.

Although the technique of calling for re-election at split-brain is good enough
to tackle the situation, but it is very inefficient and prone to the service
disruption for the time when the cluster is rebooting. Also in some cases, like
when the split-brain happens because of temporary network partitioning the new
elections could elect master that has the outdated or invalid backend states.

Now with this enhancement when the cluster detects the split-brain, instead of
blindly calling for new master node election and rebooting every node,
The watchdog nodes try to solve the master/coordinator node contention by
choosing the best candidate.

The candidate for the master/coordinator node is selected on the following criteria.

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.

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.

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

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.

Mega patch to fix "kind mismatch" (or derived) errors in streaming replication mode.

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.

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.

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

See bug 271:
http://www.pgpool.net/mantisbt/view.php?id=271

and discussion in pgpool-hackers mailing list [pgpool-hackers: 2043]
and [pgpool-hackers: 2140] for more details.

Add new regression test "069.memory_leak_extended".

This is almost same as 060.memory_leak" but it uses extended query
protocol.

Fix for 0000296: PGPool v3.6.2 terminated by systemd because the service Type
has been set to 'forking'

Removing the "-n" value assigned to OPTS variable in pgpool.sysconfig.
The problem was the systemd service with Type=forking expects the parent process
to exit after the startup is complete, but because the -n command line option
disables the daemon mode and systemd keeps on waiting for the Pgpool-II's parent
process to exit after startup, which never happens and eventually systemd
terminate the Pgpool-II after timeout.
As part of this commit I have also added a new variable STOP_OPTS which is
passed to ExecStop and can be used to pass extra command line options to
Pgpool-II stop command.

Enhancing the watchdog internal command mechanism to handle
multiple concurrent commands.

Add release-notes 3.6.2-3.2.19.

Fix pcp_promote_node bug that fails promoting node 0

The master node could not be promoted by pcp_promote_node with
the following error;

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

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.

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.

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.

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.

Fix tag error (excessive ">").

Pgpool-II should not perform ping test after bringing down the VIP

At the time de-escalation from the master watchdog node, we should not perform
the ping test to verify if the VIP was successfully brought down or not.
The reason is, if the new master watchdog node acquires the VIP while the
resigning node is still performing the de-escalation steps, then the resigning
Pgpool-II node will falsely assume that it has failed to bring down the
delegate IP, Since it will get the positive ping result from the new master node
who has already acquired the same VIP.

Secondly, not having the delegate-IP in the configuration should not be
considered as an error case by wd_IP_up() and wd_IP_down() functions.
Since there are many possible valid scenarios where a user would not want to
have a delegate-IP. So now both wd_IP_* functions return WD_OK instead of WD_ND
when delegate_IP configuration is empty.

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

The commit also contains some log message fixes.

Fix to release shared memory segments when Pgpool-II exits.

Per bug272. From the bug report.
"This cause the creation of a lot of segments if you start and stop
pgpool continuously (and in a testing fase it could be normal). Lot of
segments bring to reach the shmem OS configuration limit and than
suddenly stops (pgpool) working."

Fix for [pgpool-general: 5315] pg_terminate_backend

Pgpool-II process the pg_terminate_backend by setting the swallow_termination
flag of the backend connection_info referred in the pg_terminate_backend
function, and latter resets that flag when the query execution completes.

The problem with this approach is that if the command complete for
the pg_terminate_backend is received before the connection termination,
This termination is regarded as the backend failure since the
swallow_termination flag was already cleared by the Pgpool-II child after
receiving the query completion message.

The solution is to reset the swallow_termination flag only when the
pg_terminate_query query fails otherwise leave it as it is when the query
is successful, Since, after the termination of the connection the flag
will not matter anyway.

Enhance document.

Add note about %m in failover command. Add indexes to "streaming
replication mode", "master slave mode" and "native replication mode".

Adding the missing ExecStop and ExecReload commands to the systemd
service configuration file.

The patch was contributed by supp_k and enhanced by me.

Fix for 281: "segmentation fault" when execute pcp_attach_node

A DEBUG message was trying to de-reference a NULL value.

Fix load balancing bug in streaming replication mode.

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. Solution is, the
treatment for writing query is done in executing the writing query as
well.

The bug has been there since V3.5.

Fix yet another kind mismatch error in streaming replication mode.

1) Parse "BEGIN" using statement S1, and it is sent to both node 0 and 1.

2) Close S1.

3) Parse SELECT using S1, and it is sent to node 0 (or 1).

4) Bind retrieves info (sent_messages) regarding S1. Since Pgpool-II
   only removes info on S1 when CloseComplete received, Bind decides
   to send bind message to both node 0 & 1 because it was the info
   regarding BEGIN. Node 0 or 1 tries to bind to non existent
   statement S1.

   As a result, something like "failed to read kind from backend.
   kind mismatch among backends. Possible last query was: "BEGIN" kind
   details are: 0[E: prepared statement "S1" does not exist] 1[3]
   check data consistency among db nodes" occurs.

Note that in 3) if other than S1 is used, the problem does not occur.
Solution is, removing S1 when Close message is received. This problem
has been there since 3.5.0 was out.

Fix do_query() hangs after close message.

This is an en-bug in 3.6.1.

If an extend query appears right after a close message, do_query() is
called to check system catalogs, it hangs because it expects to read
pending data. This is caused by being mistakenly set the pending flag
after Close().

Back patch to 3.6-stable and 3.5-stable.

Fixing 0000280: stack smashing detected

It was a buffer overflow in wd_get_cmd function

Fix indentations of query cache documents.

Enhance query cache documents.

Fixing the issue with the watchdog process restart.

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".

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

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.

Fix query cache bug reported in pgpool-general-jp:1441.

In streaming replication mode with query cache enabled, SELECT hangs
in the following scenario:

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

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.

Fix is, just call pool_unset_pending_response() in #1 to reset the
flag.

Bug report and fix provided by Nobuyuki Nagai.

New regression test item (068) added by me.

Remove elog/ereport calls from signal handlers.

elog/ereport calls malloc(), which is not safe to be called inside
signal handlers, per discussion in [pgpool-hackers: 1950].  I ifdef
out them, rather than simply remove them in a hope we someday find a
better solution which make calling the functions inside signal
handlers.

Not that I did not touch exit_handler() of pgpool_main.c because
removing elog/ereport from them loses informative message like
"received smart shutdown request". Pgpool-II main process do not
heavily use malloc(), so the risk is minimum, I guess.

Fix typo in Japanese release notes.

Fix bug failed to create INET domain socket in FreeBSD if listen_addresses = '*'.

per bug202.

Fix for 0000249: watchdog sometimes fails de-escalation.

The logic in pgpool-II main process exit_handler and terminate_all_childrens was
not making sure that pgpool-II main process should only exit after all its
children have exited. And the problem occurs when the main process shutdowns
itself before watchdog and de-escalation child processes.

The solution is to use the waitpid() system call without WNOHANG option.

Fix connection_life_time broken by authentication_timeout

When authentication_timeout is enabled,
connection_life_time could never be expired, because
alarm(0) is called at reading start-up packet.

When there only one connection pool is used, this
problem doesn't occur because the signal handler
for connection_life_time is always set at the end
of the session. However, if more than one connection
pools exist, the handler isn't set but only the time
to colse the connection is calculated.

To fix it, when authentication_timeout is enabled,
save the signal handler for conneciont_life_time
and the remaining time, and undo the handler when
authentication_timeout is disabled.

Fix authentication timeout that can occur right after client connecttions

This is possible when connection_life_time is enabled.

SIGALRM signal is used for both connection_life_time and
authentication_timeout. Usually, SIGALRM is for connection_life_time,
but when the new connection is arrive, read_startup_packet() is called,
and the handler for authentication_timeout is set by pool_signal() and
alarm(authentication_timeout) is called in enable_authentication_timeout().

However, if connection_life_time is expired **between pool_signal() and
alarm()**, authenticate_timeout() will be called when connection_life_time
is expired instead of pool_backend_timer_handler().

To fix this, call alarm() before pool_signal() to prevent the signal
handler from being with wrong timing.

Some changes in release note 3.1-3.6.

Add Japanese release note 3.1-3.6.

Tightening up the watchdog security

Now wd_authkey uses the HMAC SHA-256 hashing.

Add pgpool_adm extension.

Add release 3.1-3.6 release notes.

The contents are not accurate at this moment except 3.6.1. They are
just copy of 3.5.5 release note.

Add 3.5.5 release note.

Update Pgpool-II version to "3.7devel".