Fixing coverity scan reported issues in watchdog

CID:1381301 Missing break in switch
CID:1381300 Dereference after null check
CID:1379622 Missing break in switch

Fix typo in previous commit.

Add new test 011.watchdoc_quorum_failover.

Also modify Makefiles and health_check.c so that only when made with
"HEALTHCHECK_DEBUG=1" option to enable the health_check's "fake
failover" functionality which is necessary for the new test.  Always
enabling the functionality is dangerous for a production environment.

New Feature: Quorum and Consensus for backend failover

Add ability in the Pgpool-II to considers the existence of quorum and seek the
majority node (Pgpool-II nodes part of the watchdog cluster) consensus to
validate the backend node failover request.

The addition of this feature also made some modification in the execution
behaviour of the failover (failover, failback, promote-node) command.

Now Only the Pgpool-II of master watchdog node executes the failover
=====================================================================
The mechanism of synchronised failover across the cluster has given the way to
the failover on master. Now, only the Pgpool-II of master watchdog node performs
the failover, and rest of the Pgpool-II nodes (standby nodes in the watchdog
cluster) re-sync the backend statuses with master after it is finished with
the execution of failover.

No More Failover locks
======================
Since with this new failover mechanism we do not require any synchronisation and
guards against the execution of failover_commands by multiple Pgpool-II nodes,
So the commit removes all the distributed locks from failover function,
This makes the failover simpler and faster.

NODE_QUARANTINE_REQUEST operation
==================================
The commit adds the new kind of backend node operation NODE_QUARANTINE which is
effectively same as the NODE_DOWN, but with node_quarantine the configured
failover_command is not triggered,
Also the NODE_DOWN_REQUEST is automatically converted to the
NODE_QUARANTINE_REQUEST when the failover is requested on the backend node but
is rejected by the watchdog cluster because of missing quorum or consensus.
This means in the absence of quorum or consensus the failed backend nodes are
quarantined and when the quorum and consensus becomes available again the
Pgpool-II performs the failback operation on all the quarantine nodes.
And again when the failback is performed on the quarantine backend node the
failover function does not trigger the failback_command.

Controlling the Failover behaviour.
===================================
The commit adds three new configuration parameters to configure the failover
behaviour from user side.

failover_when_quorum_exists
===========================
When enabled the failover command will only be executed when the watchdog cluster
holds the quorum. And when the quorum is absent and failover_when_quorum_exists
is enabled, the failed backend nodes will get quarantine until the quorum becomes
available again. disabling it will enable the old behaviour of failover commands.

failover_require_consensus
==========================
This new configuration parameter can be used to make sure we get the majority
vote before performing the failover on the node. When failover_require_consensus
is enabled then the failover is only performed after receiving the failover
request from the majority (From at least 50% nodes) of Pgpool-II nodes.
For example: In three nodes cluster the failover will not be performed until at
least two nodes ask to perform the failover on the particular backend node.

It is worthwhile to mention here that failover_require_consensus only works
when failover_when_quorum_exists is enables.

enable_multiple_failover_requests_from_node
===========================================
This parameter works in connection with failover_require_consensus config. When
enabled a single Pgpool-II node can vote for failover multiple times.
For example: In the three nodes cluster if one Pgpool-II node sends the failover
request of particular node twice that would be counted as two votes in favour of
failover and the failover will be performed even if we do not get a vote from
other two nodes.

And when enable_multiple_failover_requests_from_node is disabled, Only the first
vote from each Pgpool-II will be accepted and all other subsequent votes will
be marked duplicate and rejected.
So in that case Pgpool-II will require a majority votes from distinct nodes to
execute the failover.
Again this enable_multiple_failover_requests_from_node only becomes effective
when both failover_when_quorum_exists and failover_require_consensus are enabled.

Controlling the failover: The Coding perspective.
=================================================
Although the failover functions are made quorum and consensus aware but there is
still a way to bypass the quorum conditions, and requirement of consensus.

For this the commit adds new request_details flags to control the
failover behaviour.
Below are the newly added flags values.

REQ_DETAIL_WATCHDOG:
====================
Setting this flag while issuing the failover command will not send the failover
request to the watchdog. But this flag may not be useful in any other place
other than where it is already used.
Mostly this flag can be used to avoid the failover command from going to
watchdog that is already originated from watchdog. Otherwise we may end up in
the infinite loop.

REQ_DETAIL_CONFIRMED:
=====================
Setting this flag will bypass the failover_require_consensus configuration and
immediately perform the failover if quorum is present. This flag can be used to
issue the failover request originated from PCP command.

REQ_DETAIL_UPDATE:
==================
This flag is used for the command where we are failing back the quarantine nodes.
Setting this flag will not trigger the failback_command.

Add timeout functionality to extended-query-test.

Also change the report format of extended-query-test to match with
existing regression test.

Add new test suits.

The new test suit "extended-query-test" is intended to test extended
queries using pgproto command.

Deal with OpenSSL 1.1.

Patch by me and Usama.

Add debugging aid to check pending message and backend response.

New function pool_check_pending_message_and_reply() added.  If pending
message kind and backend reply message kind is not inconsistent, it
prints a debug message. Currently the only client of the function is
read_kind_from_backend().

Add debugging/testing aid for health check.

By creating logidr/backend_down_request file, an artificial backend
error can be raised in heal check. The file should contain:

    node_id[TAB]down

Example:
1 down

If the health check process finds such a line in the file, failover is
triggered.
After this, the line is rewritten to:
1     already_down

to prevent infinite failover requests.

This feature can only be enabled by defining the C compiler definition
in the source src/main/health_check.c around line 75.

Fix wrong comment.

The comment for pool_discard_except_sync_and_ready_for_query() did not
match with what the actual code does.

Fix table about replicate_select behavior

Add release-notes of 3.6.6 - 3.2.2.

Remove pending message when Close Complete received.

When parse_before_bind() is called and a close message is sent, a
pending message is created but it is not removed later on. For usual
close message read_kind_from_backend() does not remove the pending
message because CloseComplete() does it later on. But in the code path
for parse_before_bind() gets called, CloseComplete() did not remove
the pending message. This brings loosing sync of pending messages and
messages from backend, which could cause a hang in
read_kind_from_backend().

Fix Pgpool-II hanging when error occurs in streaming replication mode and extended query.

If backend returns ERROR, Pgpool-II reads message from frontend until
a sync message is sent. Previous code assumed next message is sync.
However it is possible that more message coming before the sync
message, it's a low probability though. Fix it to continue reading
messages until the sync message is read.

Fix wd_authkey bug in that a request to add new node to the clusetr is rejected by master

This is a bug is due to the following commit.

commit 39de4a11d48b0ca50a4e8a9538265441994298b8
Author: Muhammad Usama <m.usama@gmail.com>
Date:   Thu Mar 30 02:00:49 2017 +0500

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

This changed the definition of tv_sec that is used to check wd_authkey so
that this was affected by the clock of OS. So, if there is a lag between
two nodes' clocks, the wd_authkey check fails.

Fix load balance test driver.

Some tests only for native replication mode was executed in streaming
replication mode as well.

Add "slony mode" to pgpool_setup.

Change master_slave_sub_mode default to 'stream'.

This is necessary since the default value for the
pool_config_variable.c is STREAM_MODE.

Fix not working slony mode in extended query.

When response returned from backend, in progress flag was not reset in
slony mode, which cause waiting for next message from backend in vain.

Fix ancient bug of stream write modules.

- Fix bug with pool_write_noerror() when requested length exceeds
  remaining write buffer size. This could lead to a buffer overrun
  problem, which has not been reported in the field as far as I know
  though.

- When write buffer is full, pool_flush_it() is called, which could
  write data to socket in the middle of message. I found this by using
  following pgproto data. To fix the problem directly write requested
  data if the write buffer is going to be full.

  'P' "" "SELECT * FROM pgbench_accounts LIMIT 100" 0
  'B' "" "" 0 0 0
  'E' "" 0
  'S'
  'Y'
  'X'

- Enhance performance of pool_unread(). When retrieving large number
  of rows in streaming replication and extended query, pool_unread is
  very slow because it needs to memmove large number of bytes in the
  read buffer. This happens in read_kind_from_backend() since it uses
  pool_unread() to check 'A' packet. To optimize the situation, modify
  pool_unread(). If there's enough room in front of cp->po, copies the
  data there to avoid memmove.

Some miscellanies small fixes in regression test scripts

Fix documentation about load-balancing

Change Makefile to copy figure files to tarball.

Add figures for document.

Add new document of "Pgpoo-II + Watchdog Setup Example".

Update pgpool_setup manual.

Logical replication mode is supported.

Fist cut patch to deal with logical replication.

Fix infinite loop while resetting connection.

If there was an error, bogus sent_message is registered and it causes
an infinite loop because removing the bogus list does not work in the
current implementation. Solution is, not to register bogus sent
message in the error case.

Fix core dump and mishandling of temp tables.

Fix two issues:

1) Protect pool_remove_sent_message() and pool_get_sent_message()
   against null parameters.

2) Fix bug while determining if the created table is temporary or not.

Fix failing "make dist".

doc.ja/src/Makefile seemed to be broken.

Fix ancient bug of pool_unread.

When realloc() is called in pool_unread(), it did not update the
buffer size.  This could cause variety of memory corruption and
unexpected data reading from backend. The reason why we did not found
that is, probably recently Pgpool-II starts extensively to use
pool_unread().

Fix handling of empty queries.

When empty query (empty string or all comment query) is sent, command
complete message was returned to frontend.  This is not correct. An
empty query response should be returned to frontend.

Per bug328.

Fix query cache bug with streaming replication mode and extended query case.

- Commit cache upon receiving a command complete message, rather than
  upon receiving a "ready for query" message, except in an explicit
  transaction. Doing it upon the receiving ready for query message had
  serious problem with streaming replication mode and extended query
  case, because it is possible that multiple selects get executed
  before the ready for query message arrives. The older way cannot
  handle it because it only looked at the last command before the
  ready for query message.

- When query cache hits, do not forward cached messages to frontend in
  Execute(). Instead "inject" cached messages into the backend
  buffer. This is better than older way since it respects the pending
  messages and necessary treatment while receiving messages including
  parse complete and bind complete. Note that now the cached messages
  are returned only after a flush or a sync message sent. Before they
  are returned immediately while executing execute message. The newer
  behavior more resembles to the ordinary messages (no cached message).

  To avoid adding cache by the injected messages twice,
  "skip_cache_commit" flags is introduced in query context. The flag
  is set to true in Execute() if the injection
  happens. handle_query_cache() checks the flag and skips registering
  query results to the query cache if the flag is true. The flags is
  set to false if cache is not hit.

- Introduce new function pool_at_command_success() which were the code
  fragments in ReadyForQuery() to take care misc treatments including
  unsettling writing transaction flags in CommandComplete() as
  well. Also ReadyForQuery() now calls it.

- Fix memory leak. If a close request is not issued (this is typically
  the case when unnamed statements/portals used), temp cache buffer
  remains until the session end (at the session end, the memory for
  the buffer will be freed because they are in the session context
  memory. Thus only long running sessions hit the bug). Before we
  prepared new buffer when query cache committed. Now do not create
  new buffer there. Rather create a buffer when memqcache_register
  gets called if the temp buffer is not allocated yet.

Fix memory leak with streaming replication mode/extended query case.

When Close Complete message arrives, Pgpool-II did not remove sent
message because at this point the pending message, which includes info
to remove the sent message, has been already removed by
read_kind_from_backend(). To fix the problem read_kind_from_backend()
does not remove the pending message for Close Complete and let
CloseComplete() to extract and remove the pending message to remove
the sent message data.

Per bug#324.

Fix Java program in 005.regression test.

The program forgot issue commit and always ended up with ABORT.  This
does not affect the test result itself, it would be better to finish
the test with commit, rather than ABORT.

Fix bug #303.

When failover is triggered by worker process, it is possible that
wrong DB node could failover. This is due to the db_node_id member in
the POLL_CONNECTION structure is not initialized in the process (in
child process the member is properly initialized). To solve the
problem, add new function pool_set_db_node_id() to set the structure
member variable and call it inside
make_persistent_db_connection(). For this purpose also the new
parameter "db_node_id" is added to make_persistent_db_connection and
friends.

Fix starting unnecessary transaction when SET command is issued.

In streaming replication mode, there's no point to start internal
transaction when SET command is issued. The existing behavior is
harmless but waste of CPU cycle.

Fix bug with memory leak tests and add new memory leak test.

They did not correctly detect the memory leak.

Also add new memory leak test for extended query/query cache.

Fix Pgpool-II hung up bug or other errors in error case in extended query in replication mode.

In extended query in streaming replication mode, responses supposed to
be returned from backend is managed by the pending messages. However,
if an error response returned from backend, the sequence of returned
message from backend is not what we expect. The mismatch was partially
solved in the code but it turned out they were not sufficient.

The cause of hung is basically when an error response is received from
backend before frontend sends 'S' (sync) message. If backend detects
errors while doing extended query, it does not return any response
until it receives sync message. Of course at this point frontend is
expected to send sync message to Pgpool-II, but it may not reach to
the socket of Pgpool-II. So it is possible that Pgpool-II does not
notice the sync message is coming, and does not forward the sync
message to backend. As a result, nothing goes on and Pgpool-II is
stuck. To fix the problem following modifications are made in this
commit:

- When error response is received from backend, after forwarding the
  error response to frontend, remove all pending messages and backend
  message buffer data except POOL_SYNC pending message and ready for
  query (before we removed all messages including ready for query,
  which is apparently wrong).  If sync message is not received yet,
  call ProcessFrontendResponse() to read data from frontend. This
  ensures eliminating the expectation of receiving messages from backend
  in normal cases, and receiving the sync message from frontend.

- When 'S' (sync) message is received from frontend, forward it to
  backends and wait till "ready for query" message is received from
  the backends. This ensures Pgpool-II to receive the read for query
  message and goes into the proper sync point.

- It is still possible after receiving the ready for query message,
  different messages arrived from each backend. If the numbers of
  messages are same, "kind mismatch" error will occur. If the number
  of messages are different, it is possible that Pgpool-II is stuck,
  because read_kind_from_backend() will wait till a message coming
  from backend. To fix this if either load balance node or primary
  node returns 'Z' (ready for query), try to skip messages on the
  other node. This is done in read_kind_from_backend(). See comments
  around in line 3391 of pool_process_query.c for more details.

Other fixes in this commit.

- Do not send intended error query to backend in streaming replication
  mode in ErrorResponse3(). This is not necessary in streaming
  replication mode.

- Fix pool_virtual_master_db_node_id() to return the
  virtual_master_node_id only when query is in progress and query
  context exists. Before in progress state was not checked and may
  return bogus node id.

Fix document typo.

Add Pgpool-II + Watchdog configuration example.

Fix Pgpool-II document typo.

Allow make dist to include pgpool.service

Add log after health check retrying succeeds.

Previously only health check retry logs were produced. So it was not
clear if the retry succeeded or not in the end.

Add more settings to Aurora example.

Add neccessary setting for health check retry in the Aurora example.

Add Aurora setting documentation in Japanese.

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.