Add new fields to pcp_proc_info, show pool_processes, show pool_pools command.

The purpose of this commit is to get more information about the process stats
and how pgpool is working with "client_idle_limit" and "child_max_connections".

Start time:
I add “remaining” that is the remaining time beforl the process is restarted by
client_idle_limit.

Client connection count:
The connection count from clients to this pgpool process. Useful to know how
many times clients can connect to this pgpool process before
child_max_connections reaches.

Backend connection time:
I just rename create_time for clarity.

Client connection time:
The time when the client last connected. If the client uses its own connection
pooling, this helps to know when the connection was actually made from pgpool's
point of view.

Client idle duration:
The elapsed time (in seconds) since the client became in idle state.

Client disconnection time:
This is the last time the client disconnects. The use case is the same as above.

Status:
This is the process status. This shows 4 status: “Wait for connections”, “Idle”,
“Idle in transaction”, “Execute command”.

Doc: fixed "PGPOOL SHOW" documentaion that was missing in the previous commit 151e8f54961b1a0394cfc86c2f4ddf715b41ceea.

Fix incorrect PGPOOL SHOW option.

Since 4.2 other_pgpool is removed, "PGPOOL SHOW other_pgpool" command should be changed to "PGPOOL SHOW watchdog".

Fix bug of "PGPOOL SHOW heartbeat" and "PGPOOL SHOW ALL" command.

The last member in heartbeat_* array was not displayed in the command result.

Fix to allow log_rotation_age to be set to 0.

According to the docs, it is possible to set 0 to log_rotation_age so
that the log rotation feature is disabled. But the allowed minimum
value for it was mistakenly set to 10, which made it impossible to set
log_rotation_age to 0.

Support include directive in pgppol.conf file

The pgpool.conf can be nested by 'include' directive.A depth of include have a
restriction for avoiding loop back of include files. 'include' is not regular
parameter, so SHOW command don't display it.

Fix pgpool_setup to do nothing when no new main node is available.

When no new main node is available due to there's only 1 node
remaining, pgpool_setup tried to promote a node with node id -1.  This
is impossible. Fix is just skipping whole failover process if new main
node id is -1.

Fix the incorrect display of load balancing node in raw mode.

In raw mode, Pgpool-II sends all queies to main node.
This is harmless, but it may confuse users.

Fix pgpool logger process eats 100% cpu.

The select(2) loop in the logger process did not initialize
timeout.tv_usec, which could cause error in select(2) because of too
big tv_usec. In this select(2) immediately returned and iterate the
for loop.

Problem reported and patch provided by Fang Jun.
Discussion: https://www.pgpool.net/pipermail/pgpool-hackers/2021-August/003993.html

Fix compiler warning.

Update Makefile.in and configure.

Fix "ar: `u' modifier ignored since `D' is the default (see `U')" warnings.

The warning can be eliminated by changing arguments of ar command from
"cru" to "cr".  There were two places of the warnings: src/libs/pcp
and src/watchdog.  For the former, we need to fix libtool, which is
generated by configure. So fix configure.ac.  For the latter, just fix
src/watchdog/Makefile.am.

Update configure and src/config/pool_config.c due to the previous commit.

Fix compiler warnings generated by newer version of gcc.

gcc on Ubuntu 20 (9.3.0) generates tons of compiler warnings something like:

In file included from /usr/include/string.h:495,
>                  from pg_md5.c:31:
> In function 。strncpy「,
>     inlined from 。update_pool_passwd_from_file「 at pg_md5.c:276:3,
>     inlined from 。main「 at pg_md5.c:136:3:
> /usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: warning: 。__builtin___strncpy_chk「 output may be truncated copying between 0 and 128 bytes from a string of length 257 [-Wstringop-truncation]
>   106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
>       |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>

I have found a message in PostgreSQL hackers mailing list regarding similar issue:
https://www.postgresql.org/message-id/flat/21789.1529170195%40sss.pgh.pa.us#525c384d13505fa6f1f25c50b00d7a08

To fix these warnings:

1) fix misuse of strncpy() and friends

2) add -Wno-stringop-truncation to CLFAG

This commit implelents #1 and #2.

Discussion: https://www.pgpool.net/pipermail/pgpool-hackers/2021-August/003990.html

Fix SI mode to acquire a snapshot with an internal transaction.

In SI mode a data modifying statement needs to start internal
transaction.  However it forgot to acquire a snapshot. This commit
fixes that in both simple query protocol and extended query protocol.

Update Makefile and SPEC file to include "pgpool_recovery--1.3--1.4.sql" and "pgpool_recovery--1.4.sql".

Doc: fix typo in Japanese release note.

Doc: Mention that double quotes are required in "PGPOOL SHOW" command if the parameter contains uppercase letters.

Fix backend_flag* parameter shown twice while executing "pgpool show all".

There are two entries of "backend_flag" for "ALLOW_TO_FAILOVER" and
"ALWAYS_PRIMARY" in the config variable struct. This is mostly ok but
"pgpool show all" command displayed both backend_flag entries, which
looks redundant. The reason for this is, report_all_variables() shows
grouped variables first then other variables except already shown as
grouped variables.  Unfortunately build_variable groups() is not smart
enough to build grouped variable data: it only registers the first
backend_flag entry and leaves the second entry. Since the second entry
is not a grouped variable, backend_flag is shown firstly as a grouped
variable and then is show as a non grouped variable in
report_all_variables(). To fix this, mark that the second variable is
also a grouped variable (the flag is set by
build_config_variables()). See bug 728 for the report of the problem.

Also add/fix comments.

Doc: add new parameter to recovery_1st_stage_command and recovery_2ndt_stage_command.

Add missing changes in the previous commit.

Add new parameter to recovery_1st_stage_command and recovery_2nd_stage_command.

The new parameter represents the primary (main) server host name which
is defined in backend_hostname parameter. The commands used to obtain
the host name by using hostname command. This is usually fine but in
some systems the host name returned by hostname command is not same as
backend_hostname. This brings problem to detach_false_primary feature.

Note that documentations are not completed in this commit because of
my development environment (Ubuntu 20) issue (openjade crashes). I
will push document changes later using another PC.

Discussion:
https://www.pgpool.net/pipermail/pgpool-hackers/2021-July/003943.html
https://www.pgpool.net/pipermail/pgpool-hackers/2021-July/003974.html

Add release notes.

Doc: Update configuration example "Pgpool-II on Kubernetes".

Doc: add more explanation about backend_application_name.

Allow to log error messages in extended query mode in certain cases.

In the extended query mode, it is possible that error messages are not
logged even after a sync message is received. With this commit
whenever ERROR response is arrived from backend in the extended query
mode, the error message is logged.

Implementing the follow_primary command-locking over the watchdog channel.

Supplementary fix for [pgpool-hackers: 3892] Problem with detach_false_primary..

commit:455f00dd5f5b7b94bd91aa0b6b40aab21dceabb9 fixed a race condition between
detach_false_primary and follow_primary commands. Part of the fix was to make
sure that the detach_false_primary should only be executed on the
leader watchdog node.

The mentioned commit ensures the execution of detach_false_primary on the
watchdog leader by getting the watchdog status from within the main process.
The design is good enough for most cases, but has the potential to fail if
the cluster goes into the election process just after the main process
has read the status.

To fix that, this commit implements the synchronization of follow_primary_command
execution using the distributed locks over the watchdog channel.

The idea is, just before executing the follow_primary during the failover process
we instruct all standby watchdog nodes to acquire a lock on their respective
nodes to block the false primary detection during the period when the
follow_primary is being executed on the leader watchdog node.

Moreover to keep the watchdog process blocked on waiting for the lock the commit
introduced the pending remote lock mechanism, so that remote locks can get
acquired in the background after the completion of the inflight replication checks.

Finally, REQ_DETAIL_CONFIRMED flag is removed from degenerate_backend_set()
request that gets issued to detach the false primary, That means all quorum
and consensus rules must be satisfied for the detach to happen.

Doc: Fix documentation typos.

Doc: Fix documentation typos.

Use milliseconds logging for Pgpool-II and PostgreSQL.

This will make analyzing timing sensitive issues easier. Before we
could not analyze sub-second timing issues.

Add support for log time stamp with milliseconds.

Fix 033.prefer_lower_standbu_delay

Sometimes this test failed due to the waiting time after pcp_reload_conf
was short. I modified the script to confirm the change by PGPOOL SHOW
before running the test.

Fix client side hang when describe message is followed by NoData response.

For certain describe request for a query including "LISTEN", NoData
message can be returned. Since Pgpool-II buffered NoData, clients
could hang waiting for the NoData message in vain. To fix this, do not
buffer NoData message.

Problem reported and patch provided by Daniel van de Giessen.
Discussion: https://www.pgpool.net/pipermail/pgpool-hackers/2021-July/003951.html

Fix query cache to not cache SQLValueFunctions (CURRENT_TIME, CURRENT_USER etc.).

Checking SQLValueFunctions was missed whether to be cached or not and
they were regarded as non function objects. As a result they were
cached.

Also add more test cases.

Doc: fix typo in in memory query cache document.

Revert "Fix 033.prefer_lower_standbu_delay"

This reverts commit 61fb18a08d143c41d87ffa81dc1767c371f11917.
Previous commit was to deal with reload config sometimes not working. However that was not a good idea because it hides the real cause of the test failure.

Fix 033.prefer_lower_standbu_delay

Doc: fix typo.

Fix typo in pgpool.conf samples.

Add buffer length check.

get_info_from_conninfo() did not check the size of the provided
buffers.  Add length parameters so that it can check the buffer size.

Fix compile warning

Fix sending invalid message in SI mode.

When a query is aborted by specific reason like serialization error,
Pgpool-II sends error query to abort transactions running on non main
nodes. The message length of the query was incorrect and it caused
"invalid string in message" error on backend.

Remove /*NO LOAD BALANCE*/ comment

This comment was used for query load balancing controlling.
Currently, we can use allow_sql_comment and primary_routing_query_pattern_list
and things like that, so this speical comment is unnecessary.

Fix rsync parameter in pgpool_setup.

It did not exclude "log" directory, which is the default logging
directory in recent PostgreSQL versions. This made hard to examine
PostgreSQL log, since it is copied from primary server.

Remove unused static function.

The function free_processInfo() is no longer needed due to the
refactoring c7690453.

Fix follow primary command creation in pgpool_setup.

If the target node of the follow primary script is primary and the
server version is before PostgreSQL 12, then the follow primary
command fails because there's no recovery.conf (12 or later is fine,
because "standby.signal" and "myrecovery.conf" are created).

To fix this, if server version is before 12, rename recovery.done to
recovery.conf.

Also this should fix 034.promote_node failure with PostgreSQL 11 or
before.

Fix the width of some struct member of LifeCheckNode.

They were defined using constant numbers. Use more appropriate #define
symbols to make them consistent with other declarations.

The issue was detected by a Coverity run.

Also fix copyright year.

Fix follow primary script creation.

When PostgreSQL version is lower than 12, the script should have edit
recovery.conf, rather than myrecovery.conf.

Doc: fix parameter name typo in ldap option

Fix the commit b69e695758dcb2fea0dacfeaf1e40299352ccdaf and c75e1456b1259fc172c127d26b32285424399907

changing the permission of the regression test script and
adding prefer_lower_standby_delay to pool_process_reporting.c

Fix the commit b69e695758dcb2fea0dacfeaf1e40299352ccdaf

New feature "prefer_lower_delay_standby"

Currently on streaming replication mode, when the node selected as the load
balancing node has streaming delay over delay_threshold, pgpool sends the
query to the primary regardless of other standbys.

When this parameter is set to on, if the delayed load balancing node is the
standby, pgpool selects the new load balancing node from the lowest delay standbys.

If all standbys are delayed or the primary is chosen as the load balancing node,
pgpool sends the query to the primary.

Fix 075.detach_primary_left_down_node.

The test script executed pcp_detach_node but it always failed because
it tried to connect to UNIX domain socket.

Fix 031.connection_life_time.

The test script executed pcp_recovery_node but it always failed
because it tried to connect to UNIX domain socket.

Fix 018.detach_primary error in the log.

The regression test itself passes but execution of pcp_watchdog_info
to get information failed because it tried to connect to UNIX domain
socket.

Fix pgpool_setup to generate portable follow_primary.sh.

The script did not provide necessary information to execute pcp
commands: pcp port, PCPPASSFILE and path to pcp commands.

Also fix the failover.sh generation. Currently there's no user to use
the information but to avoid possible confusion in the future, the
information is also added.

These should fix the regression test failure of 034.promote_node.

Fix 034.promote_node test failure.

It appeared that under buildfarm environment, pcp_socketdir is set to
/var/run/postgresql, but pcp client's socket directory are not changed
from /tmp (it is defined at the compile time). Probably we should
workaround this someday, but I just gives "-h localhost" parameter to
pcp_promote_node to avoid this problem.

Update Copyright year.

Fix regression test 034.promote_node failure.

According to the build farm log, the cause of failure is, pcp server
was not yet ready.  So wait for up 10 seconds by calling pcp_node_info
before executing pcp_promote_node.

Refactor "SHOW pool_pool_pools" and pcp_proc_info.

These commands had many duplicated codes and did not use
infrastructures to make the code shorter. Now they are fixed and it is
much easier to add new data.

Fix pgpool_setup in creating base backup script.

Allow to specify node id to be promoted in pcp_promote_node.

For this purpose new parameter "-s" or "--switchover" is added.  If
the parameter is specified, current primary node is detached and the
target node id is passed to the failover script's argument "main
node". Since most of failover script promotes the "main node", this
results in promoting the node specified in pcp_promote_node.

The idea was initially proposed by Nathan Ward.  Patch was created by
me and reviewed by: Nathan Ward, Umar Hayat and Lachezar Dobrev.

Discussion:
https://www.pgpool.net/pipermail/pgpool-general/2021-April/007532.html
https://www.pgpool.net/pipermail/pgpool-hackers/2021-June/003921.html

Do not use replication slot.

regress.sh enabled replication slot for pgpool_setup run.  The reason
is not clear but this makes some of tests occasionally failed.

New feature: Allow pcp_node_ino to list all backend nodes information.

Update gram_minimal.c which is generated by gram_minimal.y

Fix orphan process is left when pgpool is going down.

When pgpool is going down while follow primary command is ongoing,
some process started by follow primary child process could be left.
The follow primary child calls trigger_failover_command() to run the
follow primary script by using system(3). Unfortunately the process
started by system(3) was not tracked by anyone and it was possible
that the process(es) are left. To reproduce the problem you can edit
the test script (test,sh) for the regression test
075.detach_primary_left_down to change the timeout counter to small
number, say 1. i.e.,
change:
cnt=60
to
cnt=1

To fix the problem, the follow primary child process calls setsid(2)
to set new session id. When Pgpool-II main goes down, the exit handler
kills all the process including the process started by system(3), by
specifying kill(-(follow primary child process pid)).

Also in the initialization of the follow primary process, unmask
signals and assign default behavior to each signal (this should have
been done much earlier).

Fix pcp_detach_node leaves down node.

Detaching primary node using pcp_detach_node leaves a standby node
after follow primary command was executed.

This can be reproduced reliably by following steps:

$ pgpool_setup -n 4
$ ./startall
$ pcp_detatch_node -p 11001 0

This is caused by that pcp_recovery_node is denied by pcp child process:

2021-06-05 07:22:17: follow_child pid 6593: LOG:  execute command: /home/t-ishii/work/Pgpool-II/current/x/etc/follow_primary.sh 3 /tmp 11005 /home/t-ishii/work/Pgpool-II/current/x/data3 1 0 /tmp 0 11002 /home/t-ishii/work/Pgpool-II/current/x/data0
2021-06-05 07:22:17: pcp_main pid 6848: LOG:  forked new pcp worker, pid=7027 socket=6
2021-06-05 07:22:17: pcp_child pid 7027: ERROR:  failed to process PCP request at the moment
2021-06-05 07:22:17: pcp_child pid 7027: DETAIL:  failback is in progress

it complains that a failback request is still going. The reason why the
failback is not completed is, find_primary_node_repeatedly() is trying
to acquire the follow primary lock. However the follow primary command
has already acquired the lock and it is waiting for the completion of
the failback request. Thus this is a kind of dead lock situation.

How to solve this?

The purpose of the follow primary lock is to prevent concurrent run of
follow primary command and detach false primary by the streaming
replication check. We cannot throw it away. However it is not always
necessary to acquire the lock by find_primary_node_repeatedly(). If
it does not try to acquire the lock, failover/failback will not be
blocked and will finish soon, thus Req_info->switching flags will be
promptly turned to false.

When a primary node is detached, failover command is called and new
primary is selected. At this point find_primary_node_repeatedly() is
surely needed to run to find the new primary. However, once follow
primary command starts, the primary will not be changed. So my idea
is, find_primary_node_repeatedly() checks whether follow primary
command is running or not. If it is running, just returns the current
primary. Otherwise acquires the lock.

For this purpose, new shared memory variable
Req_info->follow_primary_ongoing was introduced. The flag is set/unset
by follow primary process.

New regression test 075.detach_primary_left_down_node is added.

Discussion: https://www.pgpool.net/pipermail/pgpool-hackers/2021-June/003916.html

Fix backend_application_name cannot be changed by reloading.

The manual explicitly stats that it is possible to change
backend_application_name on the fly by reloading the configuration
file but the code set unnecessary restriction on that.

Doc: fix wd_life_point description

The description of the default value was lacked in the Japanese doc.

Add comments to watchdog.c

Add comment to Req_info->conn_counter.

Fix occasional failure of 028.watchdog_enable_consensus_with_half_votes test.

It seems the failure was caused in this scenario:

Testing total nodes: 4. enable_consensus_with_half_of_the_votes: on
shutdown node pgpool2
2021-05-30 07:41:54: main pid 28819: LOG:  stop request sent to pgpool. waiting for termination....done.
shutdown node pgpool1
2021-05-30 07:41:56: main pid 28825: LOG:  stop request sent to pgpool. waiting for termination....done.
Quorum does not exist. Test failed

So the test failed at 07:41:56. In the mean time pgpool.log showed:
2021-05-30 07:41:54: watchdog pid 28569: LOG:  We have lost the cluster leader node "localhost:50008 Linux e1aa95e1fe13"
:
:
2021-05-30 07:41:59: watchdog pid 28569: LOG:  watchdog node state changed from [STANDING FOR LEADER] to [LEADER]
2021-05-30 07:41:59: watchdog pid 28569: LOG:  I am announcing my self as leader/coordinator watchdog node

The quorum was established at 07:41:59. That means the test for quorum
existence was too early.

To fix this, insert "sleep 5" after shutting down pgpool.

Enhance watchdog_setup script.

shutdownall script generated by watchdog_setup shutdowns in the node
number order i.e.: 0, 1, 2...  This causes PostgreSQL backend shutdown
when pgpool0 node went down and node 1, 2... trigger failover event,
which is not necessary in the whole shutdown sequence.  Shutting down
in the reverse order (...2, 1, 0) should prevent this and shorten the
whole shutdown sequence.

Also this should prevent occasional 018.detach_primary and
028.watchdog_enable_consensus_with_half_votes test timeout (they use
watchdog_setup).

Fix occasional regression test 018.detach_primary error.

According to the buildfarm log, the test failed at after this:
with this:
$PGPOOL_INSTALL_DIR/bin/pcp_watchdog_info -v -w -p $PCP_PORT
error message was:
ERROR: connection to socket "/tmp/.s.PGSQL.50001" failed with error "No such file or directory"
This suggests that pcp_watchdog_info fails because pcp server has not started yet.

To fix this add wait_for_pgpool_startup before pcp_watchdog_info.

Fix maximum length of hostnames including domain name.

The maximum length of hostnames was 128, which is not incorrect.
Moreover there were multiple places where the maximum length of hostname is defined.
So create unified definition of it in libpcp_ext.h.

Discussion: https://www.pgpool.net/pipermail/pgpool-hackers/2021-May/003904.html

Fix watchdog communication race condition.

Watchdog sends information from the watchdog process to the Pgpool-II
main process using SIGUSR1. To pass detailed messages it uses shared
memory area. First it sets a message to the shared memory area then
sends SIGUSR1 to the main process. The main process received the
signal and the signal handler sets a global variable so that
sigusr1_interrupt_processor() processes it. However it is possible
that while sigusr1_interrupt_processor() is running new signal
arrives. In this case the new signal is caught but the global variable
is set to 0 after sigusr1_interrupt_processor() returns. This means
that the new message is not processed until new signal arrives, which
could cause significant delay before the message was processed.

To fix the problem, sigusr1_interrupt_processor() is repeatedly called
until there's no pending message.

Discussion: https://www.pgpool.net/pipermail/pgpool-hackers/2021-May/003901.html

Fix for bug:684: Watchdog node status not updating after rebooting.

A node should broadcast its status to the whole cluster after
joining the cluster as standby.

Fix "file name is too long (max 99)" error while creating a tarball.

Add release notes.

Improve sample scripts.

Improve sample scripts.

Replcace dots or hyphens in replication slot name to underscore.

Fix error message while checking watchdog configuration.

Since Pgpool-II 4.2 there's no "other watchdog node" concept.
All watchdog nodes are registered on all watchdog nodes.

Doc: fix typo.

Fix 018.detach_primary test.

The script tried to extract primary node id from the results of show
pool_nodes.  From 4.3 it includes the actual backend status. As a
result the script could accidentally picks up a node id which is
actually a standby (but has primary status as PostgreSQL) from
Pgpool-II's point of view.

This resulted in a shell syntax error here because $primary_node could
have node "0 2" for example.

if [ $primary_node != 0 ];then

Update copyright year.

Fix regression test 018.detach_primary test.

The test script did not explicitly specify the path to
pcp_watchdog_info.

Fix memory leak in pcp_node_info.

Detected by Covery.

Fix race condition between detach_false_primary and follow_primary command.

It was reported that if detach_false_primary and follow_primary
command are running concurrently, many problem occured:

https://www.pgpool.net/pipermail/pgpool-general/2021-April/007583.html

Typical problem is, no primary node is found at the end.

I confirmed that this can be easily reproduced:

https://www.pgpool.net/pipermail/pgpool-hackers/2021-May/003893.html

In this commit new functions pool_acquire_follow_primary_lock(bool
block) and pool_release_follow_primary_lock(void) are introduced. They
are responsible for acquiring or releasing the lock. There are 3
places where those functions are used:

1) find_primary_node

This function is called upon startup and failover in the main pgpool
process to find new primary node.

2) failover

This function is called in the follow_primary_command subprocess
forked off by pgpool main process to execute follow_primary_command
script. The lock should be help until all follow_primary_command are
completed.

3) streaming replication check

Before starting verify_backend_node, which is the work horse of
detach_false_primary, the lock must be acquired. If it fails, just
skip the streaming replication check cycle.

The commit also deal with the case when watchdog is enabled.

https://www.pgpool.net/pipermail/pgpool-hackers/2021-May/003894.html

Multiple pgpool nodes perform detach_false_primary concurrently and
this is the cause of the problem.  To fix this detach_false_primary is
performed only on the leader node. Also if the quorum is absent,
detach_false_primary is not performed.

Doc: update copyright year.

Doc: fix description about heartbeat_device.

It did not mention the parameter can only be used if Pgpool-II started
as root.

Doc: enhance description on enable_consensus_with_half_votes.

Although this parameter is written in "Controlling the Failover
behavior" section, this does affect to not only the backend failover
but quorum of Pgpool-II itself. So add a note to make it clear.

Doc: remove incorrect description about failover_when_quorum_exists.

"Please note that if the number of watchdog nodes is even, we regard
that quorum exists when the number of live nodes is greater than or
equal to half of total watchdog nodes." This is not correct anymore
since Pgpool-II 4.1 in which enable_consensus_with_half_votes has been
introduced.

Doc: fix typo.

Doc: fix typo.

Fix broken database/app redirect preference in statement level load balancing mode.

Reported in bug707.

Update .gitignore file.

Update configure file.

Fix watchdog_setup to not fail when -n is not specified.

watchdog_setup failed if -n (number of PostgreSQL clusters) is not
specified. Now if -n is not specified, assume "-n = 2", which is same
as in pgpool_setup.

Doc: fix typo.

Doc: fix typo.