Fix 024.cert_auth regression failure on CentOS6.

Recent addition of CRL support causes regression failure of
024.cert_auth only on CentOS6, because of the default key length
difference in different OpenSSL versions. Fix is, explicitly specify
key length.

Author: Umar Hayat
Discussion: https://www.pgpool.net/pipermail/pgpool-hackers/2020-March/003560.html

Add support for an user/password input file to pg_enc.

Allow to use an input file containing multiple username/password pairs.

Patch created by Umar Hayat, along with Japanese document by Tatsuo Ishii.
Discussion: https://www.pgpool.net/pipermail/pgpool-hackers/2020-March/003543.html

Fix long standing bug in backend flag configuration processing module.

Recent commit revealed bugs in backend flag (backend_flag0 etc.)
configuration processing module. This leads to massive build farm
failure.

1) The default value for backend flag is ALWAYS_MASTER. This should be
"" (empty string).

2) The final value of the backend flag is the last default for the
flag. This is plain wrong (see BackendFlagsAssignFunc()). The result
value should be OR'ed value of each default value since backend_flag
is a bit data.

Probably we should back port the fix to the other stable branches but
I would like to confirm that the fix does not add bugs or side
effects before doing that.

Discussion:
https://www.pgpool.net/pipermail/pgpool-hackers/2020-March/003553.html

Add support for SSL CRL (Certificate Revocation List).

Patch created by Umar Hayat, along with Japanese document by Tatsuo
Ishii.
Discussion: https://www.pgpool.net/pipermail/pgpool-hackers/2020-February/003505.html

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

Update src/Makefile.in.

Unify master_slave_mode, master_slave_sub_mode and replication_mode into backend_clustering_mode.

Previous "running mode" concept was confusing and hard to
understand. For example, each running mode is actually mutually
exclusive but it was possible to use some of modes altogether. Of
course the result was chaos.

Now the "running mode" is renamed to "clustering mode" and the
configuration variable is unified into single
"backend_clustering_mode". It is an enum type and possible values are:
streaming_replication', 'native_replication', 'logical_replication',
'slony' or 'raw'.

Documents are changed accordingly.

Note that old config variables are still remaining in
pool_config_variables.c. So it is possible to read old config
variables and replace them into new config variable
backend_clustering_mode to mitigate the migration pain from the old
configs to new configs, but I am not sure that is worth the problem.

Update pool_config.c.

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

per 516.

Doc: enhance installation documents.

Add "Planning" section so that uses can grasp a big picture of
installation.

Doc: explicitly mention that Pgpool-II needs 3 nodes to avoid split brain.

Doc: enghance description of failover.

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.

Add pgpool_adm's pcp_health_check_stats function.

Update Makefile.in files.

Add pcp_healt_check_stats command.

Update copyright year.

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.

Update pgpool.spec file.

Doc: Fix documentation error regarding delegate_IP.

Update pgpool-recovery function definitions.

Doc: enhance description of enable-shared-relcache parameter.

Discussion: [pgpool-general: 6833] Re: Using standby pgpool instances
https://www.pgpool.net/pipermail/pgpool-general/2020-January/006891.html

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

per bug571.

Suppress unnecessary error message when there's no standby server.

Even of there's no standby server anymore, worker process keeps on
checking result row from pg_stat_replication(). If
pg_stat_replication() returns no row, the worker process complained it
every sr_check_period and the log was flooded by them. To prevent this
get_query_result() is changed to return -2 if there's no row in the
result. Also the error message in get_query_result() is downgraded
from LOG to DEBUG1. If -2 is returned and number of active standby is
less than 1 the caller does not complain any more.

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 some phrases

Doc: fix doc typo.

Remove debug lines.

Doc: fix typo in show pool_health_check_stats manual.

Doc: fix online-recovery doc errors.

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

Change the sample follow_sh scipt %M %H paramater's order.

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

Doc: add pool_health_check_stats.sgml.

Also tweak healthcheck.sgml and pool_health_check_stats.sgml (English).

Doc: add show pool_health_check_stats reference manual.

Forgot in the previous commit.

Add health check statistics collection/display feature.

The health check process now collects statistics data such as number
of total health check performed, number of health check retry count
and health check duration and so on in the shared memory area. This
commit also adds new "show pool_health_check_stats" SQL
command. Corresponding PCP command and pgpool_adm function will be
added in subsequent commit.

Fix occasional 008.dbredirect failure.

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

Unbreak notification response message treatment in 4.1.

From 4.1 for an optimization sake SimpleForwardToFrontend() does not
flush most type of messages.  However there's an oversight regarding
"notification message" handling. This should have been flushed so that
frontend is immediately notified.

Per bug 573.

Docs: fix minor typos in enable_consensus_with_half_votes section.

Docs: fix minor typos in enable_consensus_with_half_votes section.

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.

Teach pgproto notification response message.

Now pgproto prints a upon receiving the message like this:

 <= BE Notification response. pid: 28935 channel: aaa payload: "foo"

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.

Add missing syslog setting.

Fix the missing syslog in configure file.

per bug557.

Doc: update release-note.

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 028.watchdog_enable_consensus_with_half_votes test occasional timeout.

The test script set CHECK_TIME_WAIT=true so that next pgpool start is
not affected by remaining open TCP port of previous pgpool. However
with commit d339cf86055b0cedaff2ab043ca474579660541f and
f92b7828c41bfeee17c25a91516412da0ce4c9a0, I suspect it is possible
that the problem was caused by pgpool actually was not terminated by
SIGTERM, so let's try to disable the CHECK_TIME_WAIT (if it's true,
the script takes extract time to finish) to not the test timeout
happen.

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: update release date.

Doc: update 4.1 release-note.

Fix coverity warning.

Fix Coverity warning.

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. And update failover.sh.sample too.

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

Doc: Update document "8.3. Pgpool-II + Watchdog Setup Example".

Update pgpool.spec to support PostgreSQL 12.

Start pgpool using "postgres" user by default.

Currently the Pgpool-II startup user is "root" user.
Because of the security reason, startup Pgpool-II
using non-root user is recommended.

For this reason, I modified "pgpool.service" file to start
Pgpool using  "postres" user, and allow "postrges" user to
run "if_up/down_cmd" and "arping_cmd" with sudo without a password.

The default setting of "if_up/down_cmd" and "arping_cmd" is changed:

    if_up_cmd = '/usr/bin/sudo /sbin/ip addr add $_IP_$/24 dev eth0 label eth0:0'
    if_down_cmd = '/usr/bin/sudo /sbin/ip addr del $_IP_$/24 dev eth0'
    arping_cmd = '/usr/bin/sudo /usr/sbin/arping -U $_IP_$ -w 1 -I eth0'

If if_up/down_cmd or arping_cmd starts with "/",
the setting specified in "if_cmd_path" or "arping_path" will be ignored.

This patch also changes all of the config files permission to 600.

Update pgpool_socket_dir.patch.

Fix sample scripts typo.

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.

Make enable_shared_relcache to on by default.

enable_shared_relcache enhances performance in most cases without
downsides.  So let's enable the feature by default.

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

Fixing a compiler warning and a tiny coding mistake

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.

Update version to Pgpool-II 4.2 devel.

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.

Adding new wd_cli utility

wd_cli makes it easier to integrate the external health check systems with the
Pgpool-II. It provides a very convenient and easy to use interface to interact with
watchdog and perform health check related node operations.

For example:
If some external health-check system monitoring the health of the watchdog
cluster detects the remote node failure. It can use wd_cli utility to inform
Pgpool-II about that node failure

    $wd_cli  --inform DEAD -N 'Remote watchdog name'  -p 9001 -m 'node 1 failed'

Similarly when the node becomes reachable again

    $wd_cli  --inform ALIVE -N 'Remote watchdog name'  -p 9001 -m 'node 1 found'

This utility can also be used to get the live information of all nodes.

    $wd_cli -f simple_conf/watchdog/pgpool_wd1.conf --info -v --all

    Total Watchdog nodes configured for lifecheck:    2
    *****************
    Node ID:           0
    Node Status code   4
    Node Status:       MASTER
    Node Name:         localhost:9991 Linux localhost.localdomain
    Node Host:         localhost
    Node WD Port:      9001
    Node Pgpool Port:  9991

    Node ID:           1
    Node Status code   7
    Node Status:       STANDBY
    Node Name:         localhost:9992 Linux localhost.localdomain
    Node Host:         localhost
    Node WD Port:      9002
    Node Pgpool Port:  9992

wd_cli provides many options for node search criteria.
See wd_cli --help for complete list of options.

The commit also re-arrange the code related to socket communication and
watchdog IPC commands and separates the internal and external watchdog
commands to make the code structure more modular.

The regression tests and documentation updates are not part of this commit
and will be taken care of separately.

Fix uninitialized variable.

Per Coverity.

Fix compiler warning.

Fix compiler warnings.

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'

Attempt to fix 028.watchdog_enable_consensus_with_half_votes.

Still get password does not match error. Let's change hostname arg of
watchdog_info to localhost.