Prepare 4.0.9

Doc: Add release-note.

Remove more duplicate global data.

This causes a link error on some system (Fedra 32).

Discussion: https://www.pgpool.net/pipermail/pgpool-hackers/2020-April/003593.html

Fix: 0000608: pgpool ssl front end accept all ciphers. not working as expected.

SSL  cipher_list needed to be set for server-side SSL context
instead for the client-side context.

Downgrade too verbose authentication logs.

When frontend authentication succeeds with clear text password and md5
authentication, message is out with log priority LOG. This floods
Pgpool-II log on busy systems. To fix this, downgrade the LOG message
to DEBUG1. Note that CERT auth related log level is still
LOG. Downgrading it causes regression 024 and 029 failure.

Discussion:
https://www.pgpool.net/mantisbt/view.php?id=606
https://www.pgpool.net/pipermail/pgpool-general/2020-April/007064.html

Remove duplicate global data.

This causes a link error on some system (Fedra 32).

Discussion: https://www.pgpool.net/pipermail/pgpool-hackers/2020-April/003593.html

Fix unnecessary checks.

Patch contributed by sherlockcpp.
Discussion: https://www.pgpool.net/pipermail/pgpool-general/2020-April/007062.html

Doc: fix typo.

Patch contributed by Umar Hayat.
Discussion: https://www.pgpool.net/pipermail/pgpool-hackers/2020-April/003587.html

Fix for segmentation fault in PCP processor: Bug 598

The crash was caused by an unconditionally pfree on buf without verifyingif it
was actually allocated or not. And freeing the but was not actually required at
the first places since the associated MemoryContext always gets resets anyway
after each loop iteration.

reference: https://www.pgpool.net/mantisbt/view.php?id=598

Fix a warning message is never output in watchdog.

Patch provided by sherlockcpp.
Discussion: https://www.pgpool.net/pipermail/pgpool-general/2020-April/007014.html

Fix for Coverity scan defect: 1424125 Resource leak

Doc: fix typo in failover.sgml.

Patch provided by sherlockcpp.

Fix pool show command code.

Enhance common function send_complete_and_ready() so that it uses
local variable in more sane way.

Also fix unnecessary limitation of number of rows affected by the
command.

Patch provided by sherlockcpp and Tatsuo Ishii.

Minor improvement in configure script

While checking for libpq the configure script was not honoring the LDFLAGS
settings.This sometimes breaks the configure when libraries are not present at
the defaultlocations# Please enter the commit message for your changes

Doc: fix document typos.

Patch is provided by sherlockcpp@foxmail.com.

Fix for [pgpool-general: 6951] Fix-condition-tok-is-always-true

Fix contributed by: sherlockcpp <sherlockcpp@foxmail.com>

Add regression test for previous commit.

Fix bug with query cache.

If an execute message is issued right after Sync message and query
cache hits, Pgpool-II hangs in inject_cached_message() because there's
no data to be read from backend. Fix is, change the code block which
checks the data availability in backend to the beginning of the loop
from the end of the loop. Also teach is_cache_empty() to call
pool_is_suspend_reading_from_frontend() so that if we suspend reading
from frontend. If so, return that cache is empty even if there's data
in frontend cache to receive a ready for query message from backend.

Fix problems in watchdog processing json data.

Comment on the patch from the author:

In the watchdog source code (src/watchdog/wd_json_data.c), there are some instances of bad handling of values read from json data.
For example:
1) The boolean pool configuration settings "load_balance_mode" and "master_slave_mode" are read using json_get_int_value_for_key(), resulting in 4-bytes being written into their location within the POOL_CONFIG, yet (being bool) they are only 1-byte long. This corrupts the values of the structure members following them.
2) Similarly, when parsing node function json data, "Flags" is read using json_get_int_value_for_key(), resulting in 4-bytes being written into an "unsigned char flags" variable on the stack, overwriting 3-bytes of stack memory following it. On a big-endian system (e.g. Solaris-sparc or Linux for IBM Z), this causes regression test "013.watchdog_failover_require_consensus" to fail, since 0 is written into Flags, rather than the intended value which is in the least significant byte of the int value written.

Bug reported in:
https://www.pgpool.net/mantisbt/view.php?id=596

Patch author:
Greg Nancarrow (Fujitsu Australia)

Fix SCRAM auth handling bug.

Comment on the patch from the author:

The code is currently checking if "len <= 8", but len is is
network-byte-order (big-endian).  It is surely meant to be checking
"message_length" instead, which is "len" coverted to host-byte-order
(see previous line of code).  Under (Intel) Linux, which is
little-endian, the value of "len" will be a large number and thus
render the current error condition check ineffective [for example, in
one case that I debugged, an example value of len was 134217728
(0x08000000), meaning that message_length was actually 8].
Additionally, it seems the "<=" check should actually be "<", based on
the length values that I see when debugging this code.

Bug reported in:
https://www.pgpool.net/mantisbt/view.php?id=595

Patch author:
Greg Nancarrow (Fujitsu Australia)

Fix possible data inconsistency in native replication mode.

There is a long standing bug with native replication mode. As reported
in pgpool-general, it is possible to lost sync of database if slave
DB's postgres process is killed. This is due to an oversight in
read_packets_and_process().

In replication mode if slave server's postgres is killed, then local
backend status is set to down.

*(my_backend_status[i]) = CON_DOWN;

So next DDL/DML in the same session is only issued to master node (and
other slave if there are multiple slave nodes). Of course this leads
to serious data inconsistency problem because in native replication
mode all DB nodes must receive DDL/DML at the same time.

Fix is triggering failover in thiscase.

Discussions:
https://www.pgpool.net/pipermail/pgpool-general/2020-March/006954.html
https://www.pgpool.net/pipermail/pgpool-hackers/2020-March/003540.html

Fix watchdog ping probes fail with long hostnames due to small buffer.

per 516.

Fix last status changed timestamp is not set.

If there's no status file or -D is specified when starting up
Pgpool-II, the last status changed timestamp was not set and
pcp_node_info command for example did not show the proper timestamp,
rather showed 1970/1/1, which is the Unix timestamp epoch.

Note that correct timestamp is set once clients connect to Pgpool-II
because at that time the status is changed from "waiting" to "up". So
the phenomena is only observed before any client connects to the
server.

Update copyright year.

Update pgpool.spec file.

Prepare 4.0.8.

Doc: Update doc version.

Doc: add release-notes.

Doc: update japanese documentation.

Disallowing the quorum aware failover option for the native replication mode.

In native replication mode, Pgpool-II is responsible for replicating the data
on all backend nodes, and if a node becomes quarantined then Pgpool-II stops
sending the writes to that node and when that quarantined node becomes available
again there is no way to figure out which portion of data was not replicated
during the quarantine period. This is dangerous since it can cause
data inconsistency.

So as per the discussion, we reached the conclusion to disallow failover require
consensus and quorum existence with the native replication mode so that backend
node should never get into quarantine when Pgpool-II is configured in the
replication mode.

Fix rewriting query errors in native replication mode.

per bug551.

Doc: clarify the session disconnection conditions while failover.

Doc: Fix documentation error regarding delegate_IP.

Fix child process segfault after reload if "health_check_database" is empty.

per bug571.

Fix merge error in the previous commit.

Fix oversight to adopt PostgreSQL 12.

From PostgreSQL 12 WAL dir is renamed to "pg_wal". pgpool_setup should
have dealt with this.

Fix error messsage typo

Doc: fix doc typo.

Feature: Check if socket file exists at startup and remove them if PID file doesn't exist.

If the previuos socket files exist, pgpool startup fails due to bind() failire.
This commit is to remove socket files at startup if PID file doesn't exist.

Also, I found some messages are effectively ignorede because log system is not yet initialized at start point.
I changed them to standard fprintf(stderr...).

Doc: change the follow_master_command %M %H paramater's order.

Fix occasional 008.dbredirect failure.

It seems "sleep 1" after reload is not enough. Let's sleep 10.

Fix occasional regression test failure of 008.dbredirect.

In the test pgbench -i is performed. It is possible that this bring
streaming replication delay, which in turn disturbs app/db
redirecting test. Fix is, disabling delay_threshold.

Fix 001.load_balance failure caused by previous commit.

Attempt to fix 001.load_balance test failure.

It is likely that sleep time after reload was not enough. Change them
from 1 second to 10 seconds.

More fix for occasional regression test 003.failover failure.

Comparison between show pool_node result and expected file failed
because of replication delay (the expected file set 0 to replication
delay column.) Fix is, disabling replication delay.

Fix occasional regression test 003.failover failure.

The test compares the result of show pool_nodes against pre-computed
expected text file. After primary node goes down and old standby
promotes to primary, it is possible that streaming replication worker
process stores the replication state (async, streaming) in shared
memory before the failover but fails to update the state after the
failover. Fix is, replace "async", "streaming" with space characters
in the result file to match the expected file.

Fix occasional regression test failure of 008.dbredirect.

In the test several databases are created and subsequent tests expect
that those databases have been already replicated. But it is possible
that the replication has not been done at that point and makes the
test fails. Fix is, add check the existence of database and if it's
not replicated, sleep for a while and retry it (up to 5 times).

Fix replication delay worker segfault when application_name is an empty string.

The process calls do_query() to obtain the query result against
pg_stat_replication_view.  If user sets application_name to an empty
string, the result data row packet length will be 0. However
do_query() did not consider the length == 0 case, which resulted in
giving NULL pointer to strcmp() which is called from the worker
process. That means the bug is not specific to this case (a new
feature added in Pgpool-II 4.1) but it potentially affects many other
places where do_query() gets called, although it had not been reported
in the field. So this fix should be applied to all supported branches.

Per bug 565.

Fix a display of parameter when using PGPOOL SHOW.

If show backend_flag parameter by PGPOOL SHOW command, 'ALWAYS_MASTER' config
wasn't displayed by it.

Fix pgpool_setup failure.

Fix missing syslog setting.

Prepare 4.0.7-2.

Fix the missing syslog in configure file.

per bug557.

Doc: udpate release-note.

Prepare 4.0.7.

Doc: update doc version.

Fix incorrect query rewrite in replication mode.

Doc: Add release-note.

Add RHEL 8 support.

Fix incorrect query rewrite in replication mode.
For example:
- CREATE TABLE t1 AS SELECT now();
- SELECT now() INTO t1;
- WITH ins AS ( INSERT INTO t1 SELECT now()) SELECT;

Fix health check time out.

Heal check time out could happen in several places:

1) connect system call
2) select system call
3) read system call

1) was ok but in 2) and 3) it was possible that it could go into
infinite loop in Pgpool-II 3.7 or later. This was due to a mistake
when health check process was modified to be separate process in 3.7,
and back patched to 3.7 and above.

Discussion:
https://www.pgpool.net/pipermail/pgpool-hackers/2019-October/003458.html
https://www.pgpool.net/pipermail/pgpool-hackers/2019-October/003459.html

Doc: add failover_command description

Add more exaplain about a case that failover_command execute when it
does not have a new master node. In this case, special characters in
failover_command are specified fixed values.

Fix memory leaks pointed out by coverity.

Doc: add note to trusted_servers.

"Please note that you should not assign PostgreSQL servers to this
parameter." This should have been noted since there is at least one
user who actually did it.

Fix for miscellaneous watchdog issues.

The commit takes care of following reports in watchdog
-- pgpool-general: 6672 Query (watchdog split brain)
-- 0000547: We need to do arping again after recovering from split-brain.

Basically in a bid to solve these issue, the commit makes blow mentioned
behavioral changes in watchdog

1-- If life check reports a watchdog node is dead but the watchdog core is still
able to connect and communicate with it without any problem, the watchdog core
was getting into the dilemma of whether to consider it as a lost or an alive node.

Fix:
With this commit, the lost nodes reported by life-check (external or internal)
are treated as hard failures even when the node is reachable from the watchdog
core. and that node can only become alive if it is restarted or secondly if
life-check informs that the node has become alive again.
The second type of node failures that can mark the watchdog node as lost, occurs
when a watchdog node fails to respond to the messages sent to it or frequent
errors occur on its socket. These errors are detected by the watchdog core
itself and get recovered automatically whenever that node becomes responsive
again. Apart from this the commit also made some improvements in the area of
detecting such internal errors.

2-- Standby nodes were too aggressive in reacting to the coup attempt
(when another watchdog node tries to become a master while valid master already
exists in the cluster) or to the possibility of split-brain (when it receives
"I AM MASTER" message from the node that is not the master as per the standby
node record). In both these situations, the standby nodes used to re-join
the master node in the hope to find the true master.
But that didn't prove to be a very good strategy, since it may lead to
influence the selection of true master node when the true-master and
fake-master nodes get into a fight to retain the master node status.
As one of the things true and fake master compares is the number of connected
standby nodes. And if during the fight the standby leaves the current master
to re-join the cluster the standby node count on the true master becomes
lower than actual and that affects its chances of winning the elections.

Fix:
The commit makes the standby nodes more lean-back and to actively reject the
nodes that are trying to become a master in the presence of the true-master
and avoid re-joining the cluster until it is absolutely necessary.

3-- The third problem was in the case of network partitioning or partial
life-check failure (when node A thinks node B is lost but node B thinks
node A is not lost) In this case the kicked out standby node was too
aggressive in trying to connect to the master or become a master itself
so that potentially put the unnecessary burden on the network and the
cluster nodes.

Fix:
So the fix for this issue is to make the isolated node a bit calm and wait
between trying to connect to master or become a master. For that purpose,a new
WD_NETWORK_ISOLATION state is added to the state machine, which just adds a
delay between successive tries of becoming a master. The node can only go into
this state when it comes to knowing that it is marked as lost on the current
master and gets out of it when it gets an indication that life-check on the
remote node has informed that node is alive again or secondly it gets out of
it after 10 seconds anyway.

Finally, Because creating the partial or complete network failures scenario is
very difficult so the commit also adds a watchdog debug aid similar to the
health-check debug to simulate different scenarios.

To enable the watchdog-debug aid the Pgpool-II needs to be compiled with 
WATCHDOG_DEBUG=1" flag ($make WATCHDOG_DEBUG=1)

Once compiled with debug aid enabled, you can put the command in
pgpool_logdir->watchdog_debug_requests file to test different scenarios.

e.g.

$ echo "KILL_ALL_COMMUNICATION" > logdir/watchdog_debug_requests
$ echo "KILL_ALL_SENDERS" >> logdir/watchdog_debug_requests

The current list of commands that are supported by watchdog debug aid are

DO_NOT_REPLY_TO_BEACON <= Standby node stops replying master node beacon messages
            while this line is present in the watchdog_debug_requests file
DO_NOT_SEND_BEACON <= Master node stops sending beacon messages to standby nodes
            while this line is present in the watchdog_debug_requests file
KILL_ALL_COMMUNICATION <= Watchdog stops all communication with all nodes
            while this line is present in the watchdog_debug_requests file
KILL_ALL_RECEIVERS  <= Watchdog ignores messages of all node
            while this line is present in the watchdog_debug_requests file
KILL_ALL_SENDERS  <= Watchdog stops sending messages to all nodes
            while this line is present in the watchdog_debug_requests file

Update changelog.

Update pgpool.spec to support PostgreSQL 12.

Update src/redhat/pgpool_socket_dir.patch.

Fix assorted ancient v2 protocol bugs.

- In v2 code path, extract_message() pfrees memory which was returned
  from pool_read_string(). This is plain wrong and could cause sefault
  since the memory returned by it is being managed by pool_stream
  modules.

- In v2 code path pool_process_notice_message_from_one_backend() added
  "NOTICE:" to the log message. This is not necessary as the part is
  already included in the message.

- In v2 code path pool_extract_error_message() did not prepare unread
  data correctly. This caused subsequent
  pool_process_notice_message_from_one_backend() produces empty
  message, read_kind_from_backend() failure.

Fix extended query communication in do_query()

do_query() didn't send Describe message to PostgreSQL.
It didn't use strcasecmp() but strcasecmp() when check if query is SELECT.

Fix problem that syslog_facility don't change by reload

The cause is macro definition mistake. This fix unify macro definition, and delete old test code to use vsyslog().
Reported in bug 548.

Fix inappropriate ereport call in VALID_BACKEND.

VALID_BACKEND (more precisely pool_virtual_master_db_node_id) macro
emitted message if pgpool is performing failover/failback:

ereport(WARNING,
(errmsg("failover/failback is in progress"),
errdetail("executing failover or failback on backend"),
 errhint("In a moment you should be able to reconnect to the database")));

This could be called within signal handlers and
POOL_SETMASK(&BlockSig)/POOL_SETMASK(&UnBlockSig) was called to block
an interrupt because ereport is not reentrant. However it is possible
that callers have already called POOL_SETMASK, and this could result
unwanted signal unblock.

Fix is, removing ereport and POOL_SETAMASK all together. This results
in removing the message above but we have no choice.

I found the problem while investigating regression
055.backend_all_down failure but of course the bug could have bitten
users in other places.

Fix for Coverity warning '1395047 Resource leak'

Fix for Coverity warnings in pool_auth

Fix for Coverity warnings in watchdog and lifecheck

Fix signal unblock leak in failover.

When failover event occurs, register_node_operation_request() gets
called to en-queue failover/failback requests. If the request queue is
full, this function returns false with unlocking semaphore. But it
forgot to unblock signal mask. This leads to block all signals
including SITERM, which makes pgpool fail to shutdown.

Discussion: https://www.pgpool.net/pipermail/pgpool-hackers/2019-October/003449.html

Fix for bug-545: Quorum lost and not recovered

Master watchdog node was not adding the lost standby node to its list of valid
standby nodes after it is rediscovered by the lifecheck.The fix is to ask the
node to rejoin the master node when it gets rediscovered by the lifecheck. 
As part of this commit, I have also added the watchdog data version and Pgpool-II
version in the watchdog info packet to make the extensions in the watchdog
messages easier in the future.

Thanks to Guille(reporter of this bug), for providing lots of help in testing the fix

Fix memory leak in replication mode.

Per coverity.

Fix memory leak while attempting to connect to backend.

If no backend is up and running, memory for copy of startup packet
will be lost. This was brought by commit cdb49d3b7. Per coverity.

Fix coverity warnings.

Fix coverity warnings.

Overhaul health check debug facility.

check_backend_down_request() in health_check.c is intended to simulate
the situation where communication failure between health check and
PostgreSQL backend node by creating a file containing lines:

1 down

where the first numeric is the node id starting from 0, tab, and
"down". When health check process finds the file, let health check
fails on node 1.

After health check brings the node into down status,
check_backend_down_request() change "down" to "already_down" to
prevent repeating node failure.

However, questions is, this is necessary at all. I think
check_backend_down_request() should keep on reporting the down status
and it should be called inside establish_persistent_connection() to
prevent repeating node failure because it could be better simulated
the failing situation in this way. For example, currently the health
check retry is not simulated but the new way can do it.

Moreover, in current watchdog implementation, to bring a node into
quarantine state requires *two" times of node communication error
detection. Since check_backend_down_request() only allows to raise
node down even *once" (after the down state is changed to already_down
state), it's impossible to test the watchdog quarantine using
check_backend_down_request(). I changed check_backend_down_request()
so that it continues to raise "down" event as long as the down request
file exists.

This commit enhances check_backend_down_request() as described above.

1) caller of check_backend_down_request() is
   establish_persistent_connection(), rather than
   do_health_check_child().

2) check_backend_down_request() does not change "down" to
   "already_down" anymore. This means that the second argument of
   check_backend_down_request() is not useful anymore. Probably I
   should remove the argument later on.

Fix uninitialized variable.

Per Coverity.

Fix compiler warning.

Fix compiler warnings.

Revert "Fix occasional query hang while processing DEALLOCATE."

This reverts commit 83c1988d3c8bdd0ecbdf6a3d28371febee556483.

Fix occasional query hang while processing DEALLOCATE.

When DEALLOCATE tries to remove a named statement, it inherits
where_to_send map of the named statement in
where_to_send_deallocate(). However it forgot to copy the load balance
node id in the query context of the named statement. This made sending
query to backend not happen: if the target node id is different from
query_context->load_balance_node_id nor primary node id,
pool_virtual_master_db_node_id (it is called as MASTER_NODE_ID)
returns primary node id, and pool_send_and_wait(MASTER_NODE_ID)
ignores the request because VALID_BACKEND returns false in this case
(MASTER_NODE_ID = primary node id is not in the where_to_send map). As
a result, following check_error() waits for response from backend in
vain.

Fix is, let where_to_send_deallocate() copy load balance node id from
the query context of the previous named statement.

Per bug 546.

Fix segfault in certain case.

The scenario is something like:

1) a named statement is created.
2) DEALLOCATE removes it.
3) an erroneous query is executed.

In #2, "sent message" for the named statement is removed but
"uncompleted_message" is left. Then after #3, in ReadyForQuery()
uncompleted_message is added and removed. However, storage for the
uncompleted_message has been already freed in #2, and it causes a
segfault.

Fix is, in SimpleQuery() set NULL to uncompleted_message if it's not
PREPARE command so that ReadyForQuery() does not try to remove the
already removed message.

Per bug 546.

Here is a minimum test case.

'P' "_plan0x7f2d465db530" "SELECT 1" 0
'S'
'Y'
'Q' "DEALLOCATE _plan0x7f2d465db530"
'Y'
'Q' "CREATE INDEX users_auth_id_index ON non_existing_table ( auth_id )"
'Y'
'X'

Fix identical code used for different branches per Coverity.

Fix memory leak per Coverity.

Fix typo in fork_lifecheck_child().

Fix typo in fork_watchdog_child().

Doc: clarify that certificate authentication works between only client and Pgpool-II.

Per complaint from: https://www.pgpool.net/pipermail/pgpool-general-jp/2019-September/001611.html

Fix memory leak.

Per Coverity.

Fix memory leak.

Per Coverity.

Fix uninitialized variable.

Probably harmless but bug is bug...
Per Coverity.

Doc: update example documetaion.

Doc: mention that VIP will not be brougt up if quorum does not exist.

Fix pgpool_setup to reflect the -p (baseport) to ORIGBASEPORT variable.

Otherwise, shutdown generated script by pgpool_setup does not use
proper port number for netstat command.

Fix pgpool_setup to deal with PostgreSQL 9.1.

"---data-checksums" was unconditionally added to initdb's arg but
PostgreSQL 9.1's initdb does not have the option. To solve the issue,
internal variable $PGVERSION now represents "major version" * 100:
e.g. 120 for PostgreSQL 12.x (including 12beta), 91 for PostgreSQL
9.1.x, so that pgpool_setup can check if the option can be added to
initdb options.