Doc: add Japanese documentation of process management.

[New-Feature] Dynamic spare process management

This feature allows selecting between static and dynamic process management modes.
Static process management is the same as the existing behavior of Pgpool-II, where it
spawns all child processes at startup. The new Dynamic mode keeps track of idle
processes and forks or kills processes to keep this number within
the specified boundaries.

Four new settings, process_management_mode,  process_management_strategy,
min_spare_children, and max_spare_children are added to configure the process
management behavior, while  process_management_strategy allows selecting
between three possible scaling-down strategies.

The first version of the patch was shared by "zhoujianshen at highgo.com" and reworked by me
Discussion: https://www.pgpool.net/pipermail/pgpool-hackers/2022-September/004189.html
Reviewed by: Bo Peng and Tatsuo Ishii

Update Makefile and configure files to remove doc.zh-cn which is deleted in previous commit fc2beb28d29667064d0c6156b9db320e1ec415fc

Remove out-of-date doc.zh-cn directory.
doc.zh-cn is not actually translated, it's just a copy of doc.

Improve follow_primary.sh.sample script:
- run checkpoint command on primary to update control file before running pg_rewind
- check if a directory exists before removing it

Test: update src/test/pgpool_setup.in

Update src/redhat/pgpool_socket_dir.patch

Update comments in pgpool.conf.

Update comments for listen_addresses and pcp_listen_addresses.
This shoud have been done in commits:
https://git.postgresql.org/gitweb/?p=pgpool2.git;a=commit;h=fd0efceae011c8d2c2f7c2b26dc0a738f055972e
https://git.postgresql.org/gitweb/?p=pgpool2.git;a=commit;h=9f727c1e267f1363012a3af599b7d7515e4ec355

Update src/pgpool.spec:
- Change /lib/tmpfiles.d/ file from /var/run to /run
- Install /etc/sudoers.d/pgpool
- Add new scripts aws_eip_if_cmd.sh.sample and aws_rtb_if_cmd.sh.sample

Add trusted_server_command parameter

This patch be able to specify a command that is used by trusted_servers
for checking up stream connection. Previously, ping command was only used,
and it was hard coded.

Default is 'ping -q -c3 %h' which means same as before.

Doc: update Pgpool-II 4.4 release note.

Doc: Update documentation of AWS configuration example and add sample scripts used for AWS.

Deal with idle_session_timeout.

If idle_session_timeout (added in PostgreSQL 14) is enabled and the
timeout fires, followings happen:

- If failover_on_backend_error is on (the default), Pgpool-II will
  trigger failover.

- If only one of PostgreSQL servers enables idle_session_timeout,
  Pgpool-II could hang.

To deal with idle_session_timeout detect_idle_session_timeout_error()
is added to detect the error code for idle_session_timeout. If the
error is detected, Pgpool-II returns the error code to frondend as a
fatal error and disconnects the session.  This is a similar fix
implemented for idle_in_transaction_session_timeout.

https://git.postgresql.org/gitweb/?p=pgpool2.git;a=commit;h=3f5986eee360f12e6a0bb77aa46f95abf5f6bc10

Discussion: https://www.pgpool.net/pipermail/pgpool-hackers/2022-October/004209.html
Back-path-through: 4.0

Doc: enhance description about memqcache_method.

Add explanation which method should be used.

Backpatch-through: 3.7.

Doc: first cut of Pgpool-II 4.4 release note.

Fix comment in is_select_query().

This function returns false for SELECT INTO, rather than plain SELECT.

Fix: Setting memory cache size greater than 2GB causes a segfault.

The problem was in the block_address() function that returns the memory address
for a given cache block, It was using 32bit integers to calculate the offset of
the block within the shared memory space that is only good until the 2GB limit.

Fix to to use NIL to judge a List is empty or not.

Previously it mistakenly judge by the value of the pointer itself is
NULL, which is not allowed by our coding standard.

Fix query cache.

The commit dc559c07ee5affc7035efa6e0f00185e211079a0 introduced shared
lock by using flock(2).  However it opened lock file in parent process
then the file descriptor was shared by child process. This is
wrong. The lock file needs to be opened by each child process.

Remove unused semaphore number.

Commit dc559c07ee5affc7035efa6e0f00185e211079a0 replaced use of
semaphore with flock. Thus the semaphore number is no longer
necessary.

Fix rare segfaults in pcp_proc_info, SHOW pool_pools and SHOW pool_processes.

The segfaults were in get_pools() and get_processes(). They first
extracted pid of particular process info slot on shared memory then
searched the slot again by using pid as the key. Because these steps
were not protected by any locking, it was possible that the search
using the pid failed and returned NULL if the process id is
overwritten by pgpool parent which is responsible for forking new
child process after the process exiting. As a result any subsequent
reference to the NULL pointer generated segfaults.

Solution is, first get the pointer to the process info slot then
extract the process id member from the pointer. This way, still
concurrent updating to the shared memory info by the parent process is
possible (which may lead to strange results in the output) but at
least we can avoid segfaults.

Fix coding style.

Declaration of variables must be before any execute statements.

Remove unused variable.

Fix coding style.

Declaration of variables must be before any execute statements.

Feature: Import PostgreSQL 15 BETA4 new parser.

Major changes of PostgreSQL 15 parser include:

- Add new SQL MERGE command

  MERGE INTO ... USING ...

- Add new option HEADER MATCH to COPY FROM

  COPY ... FROM stdin WITH (HEADER MATCH);

- Allow foreign key ON DELETE SET actions

  CREATE TABLE t1 (
      ...
      FOREIGN KEY (c1, c2) REFERENCES t2 ON DELETE SET NULL (c2)
  );

- Allow SET ACCESS METHOD in ALTER TABLE

  ALTER TABLE ... SET ACCESS METHOD ...;

Replace exclusive locking with shared locking in query cache.

Previously the query cache module used semaphore to protect critical
region in the query cache module. However this had serious down side
because the locking using semaphore is exclusive lock. This
introduces unnecessary wait for cache reading clients and performance
degradation when there are many concurrent clients.

To overcome the issue replace locking implementation with flock(2)
which allows share locking. Now the cache reading clients do not need
to fight each other to obtain a lock thus this increases
concurrency.

For this purpose pgpool main process creates a dummy file as
"logdir/memq_lock_file" and opens it. The file descriptor is inherited
by all child process so that they can issue flock(2) on the file.

Discussion: https://www.pgpool.net/pipermail/pgpool-general/2022-September/008442.html
Discussion: https://www.pgpool.net/pipermail/pgpool-hackers/2022-September/004196.html

Deal with SSL error SSL_ERROR_ZERO_RETURN.

Previously this caused failover, which was actually unnecessary because
it means the server is just going to close the connection.

Discussion: https://www.pgpool.net/pipermail/pgpool-general/2022-September/008425.html
Discussion: https://www.pgpool.net/pipermail/pgpool-hackers/2022-September/004194.html

Fix memory leak.

This was added in the previous commit a94451901c9be0627c5e9db04e05ef2d6835dcd7

Fix to not allow Unix-domain socket paths with invalid lengths.

Use $HOME/tmp or $HOME for the second Unix domain path.

The socket API does not allow to use too long Unix domain socket paths.

Apply changes introduced in the previous commit 50cc6f18d742c76fcc3d0ba60d2b5058267effb8 to src/parser/gram_template.y and src/parser/Makefile.in.

Doc: mention that health check process may use SSL.

Also mention that streaming replication check may use SSL too.
This should have been added since 2010.

Discussion: https://www.pgpool.net/pipermail/pgpool-hackers/2022-August/004188.html

Apply changes introduced in the previous commit to src/parser/gram_template.y and src/parser/Makefile.in.

Retire pool_string module.

Currently there are two string manipulation modules: pool_string and
StringInfo. StringInfo is more feature rich and PostgreSQL compatible
because it was imported from PostgreSQL. So replace all usages of
pool_string by StringInfo. This also solves a problem reported by
Peng: i.e. struct name "String" collision: pool_string uses "String"
and PostgreSQL 15's parser also uses "String".

Doc: fix typo.

Doc: add release notes.

Fix possible memory overrun in allocation of fds.

Fix memory leak pointed out by Coverity

Doc: enhance description in the memory requirement section.

Add explanation about memory usage while pgpool child process is running.

Doc: fix typo.

Rename regression test 035.

Support for unix_socket_directories and related parameters

Support for unix_socket_directories, unix_socket_group and
unix_socket_permissions.

Doc: mention that certain SELECTs are not cached.

SELECTs including TIMESTAMP WITH TIMEZONE or TIME WITH TIMEZONE
SELECTs including CAST to TIMESTAMP WITH TIMEZONE or TIME WITH TIMEZONE
SELECTs including SQLValueFunction (CURRENT_TIME, CURRENT_USER etc.)

Test: print Pgpool-II version in the regression test.

Fix pgpool_recovery extension script.

It lack 6-argument form of pgpool_recovery (used by v4.2). As a
result, if 4.3 extension is already installed, pgpool_setup fails
because it wants 6-argument form of pgpool_recovery.

Test: Fix regression test script to look for pgpool.conf in the proper install directory.

regress.sh did set PGPOOLDIR environment variable despite that
pgpool_setup look for pgpool.conf sample files at $PGPOOLDIR/etc. As a
result, pgpool_setup looked for pgpool.conf.sample at default install
directory (usually /usr/local/etc) even if "-m noinstall" is not
set. If inappropriate pgpool.conf sample files are in
/usr/local/etc., regression test fails.

Fix to not cache SELECT having functions with return types are timestamptz or timetz.

Functions with return type is timestamptz or timetz is affected by time zone setting.
Consider following scenario:

1) SELECT having such functions gets called and cache created.

2) time zone is changed.

3) same SELECT is called and the cache is used. The cache value is
correct any more because of the time zone change.

Discussion: https://www.pgpool.net/pipermail/pgpool-general/2022-July/008367.html

Fix query cache to not cache timestamptz and timetz cast.

Even if query is constant + cast (like '2022-07-05
14:07:00'::timestamptz), the result can be changed by SET TIME ZONE
command etc. and the result should not be cached.
Also regression test data added.

Discussion: https://www.pgpool.net/pipermail/pgpool-general/2022-July/008353.html

Fix bug in query cache.

[pgpool-general: 8285] Timestamp cast not cached

reported that query like "Select '2022-02-18
07:00:00.006547’::timestamp" is not cached.

The function non_immutable_function_call_walker() which judges whether
the query contains non immutable functions mistakenly assumes that any
query including cast to timestamp etc. should not to be cached. These
codes were originally added to detect CURRENT_TIMESTAMP etc. as they
are transformed to type cast in raw parser. Unfortunately this is
overkill since "'2022-02-18 07:00:00.006547’::timestamp" is also
transformed to a type cast.

Fortunately Pgpool-II 3.7 and after imported PostgreSQL 10 or newer
parser, which transforms CURRENT_TIMESTAMP etc. to SQLValueFunction.

As a result, the type cast handling code in
non_immutable_function_call_walker() is not necessary anymore. So this
commit removed the code.

Note: an interested thing in the report is, "Select '2022-02-18
07:00:00.006547’::timestamp" is not cached while "Select '2022-02-18
07:00:00.006547’::date" is cached. Why? Well
non_immutable_function_call_walker() (wrongly) assumes that the type
cache is always created by SystemTypeName (a parser's function), which
always adds pg_catalog schema. This only happens when the type name is
a reserved keyword. TIMESTAMP is a reserved keyword (and TIME too). So
non_immutable_function_call_walker() catches TIMESTAMP cast as
expected, but DATE is not a reserved keyword and it is transformed to
type name without "pg_catalog" schema. So
non_immutable_function_call_walker() misses it, and it is cached.

Add ssh options to restore_command in sample scripts.

Patch is created by Jon SCHEWE and updated by Bo Peng.

Doc: fix description about using PCP password file when connect to Unix domain socket

The localhost entry in pcppass matches only for the default PCP socket
directory path, not all Unix socket connections. This behavior is the
same as pgpass.

Allow to run pgpool_setup on PostgreSQL 15.

basebackup.sh created by pgpool_setup uses pg_start_backup() and
pg_stop_backup().  PostgreSQL 15 renamed them. But there's more
problem. The renamed functions (pg_backup_start() and
pg_backup_stop()) must be called within a same connection. Adapting
these requires non-trivial changes. So I decided to rewrite the code
to not use pg_start_backup() and pg_stop_backup() so that it uses
pg_basebackup command instead.

Per https://www.pgpool.net/mantisbt/view.php?id=757

Enable debug1 while executing 074.bug700_memqcache_segfault.

This is necessary to pursuit occasional timeout in the test.  Also add
debug logging to pool_push_pending_data() for the same purpose.
ereport for debugging to

Allow pgpool_setup to test sample scripts and sample config files contained in RPMs.

Currently, pgpool_setup generates scripts (e.g. failover.sh, follow_primary.sh) to test pgpool.

This commit addes a new option "-c" in src/test/regression/regress.sh
and a new environment variables TEST_SAMPLES in pgpool_setup.
Option "-c" enables TEST_SAMPLES and allows pgpool_setup to test sample scripts and
sample config files contained in RPMs.

This commit also changes "backend_hostnameX = '/tmp'" to "backend_hostnameX = 'localhost'".

Rename configuration parameter delegate_IP to delegate_ip.

For compatibility with the old versions, the old paramter delegate_IP can still work.
If the old paramter delegate_IP is used, Pgpool-II will set the value to
delegate_ip and throw a warning message.

This commit also fixes segfault of fail_over_on_backend_error
and changes the behavior to set the value to failover_on_backend_error
if fail_over_on_backend_error is used.

Add pool_config.c to src/tools/pgmd5/.gitignore.

This should avoid the error:
error: The following untracked working tree files would be overwritten by checkout:
src/tools/pgmd5/pool_config.c

Add debug logs to print each initial shared memory allocation.

Doc: fix memory requirement section.

- enhance the formula to calculate shared memory requirement so that it computes more accurate result.

- fix shared memory requirement for shared rel cache. The old value 64MB was simply wrong.

- fix process memory requirement. Previously the formula was based on
  RSS. However PSS should be used because RSS includes shared memory
  such as the memory used for libraries. This resuls in lot smaller
  memory requirement than before.

Remove spaces in sample scripts.

Allow to rewrite archive_command in sample scripts.

Update PSQL connection information in sample scripts.

Revert "Enable debug1 while executing 074.bug700_memqcache_segfault."

This reverts commit ce669517c946f36e1663891408ce67b90e0bf605.

Now that the problem was fixed by the commit:

https://git.postgresql.org/gitweb/?p=pgpool2.git;a=commit;h=4725950d19ca81d78e3a3994f665fe9a095ddb4c

those debug aid is not necessary anymore.

Fix segfault in end_internal_transaction().

This was introduced by the commit:
https://git.postgresql.org/gitweb/?p=pgpool2.git;a=commit;h=050be475d738ab4f8268dce21e2e5361b7dbcbee

In raw mode, end_internal_transaction() should not be called.

Doc: fix wrong explanation on memqcache_maxcache, memqcache_expire.

Those parameters cannot be changed by reloading config file. Restarting
pgpool is required.

Discussion: https://www.pgpool.net/pipermail/pgpool-general/2022-June/008254.html

When CloseComplete is received, foward to frontend without buffering.

It seems occasional timeour error in 074.bug700_memqcache_segfault seems to be caused by the buildfarm log as of
[pgpool-buildfarm: 2158] Pgpool-II buildfarm results CentOS7
* master  PostgreSQL 12  CentOS7
testing 074.bug700_memqcache_segfault...timeout.

From the pgpool.log:
2022-05-28 17:14:52.612: pgproto pid 45886: DEBUG:  pool_discard_temp_query_cache: cache discarded: 0x1be53e8
2022-05-28 17:14:52.612: pgproto pid 45886: DEBUG:  memcache reset buffer
2022-05-28 17:14:52.612: pgproto pid 45886: DETAIL:  discard: 0x1be57a8
2022-05-28 17:14:52.612: pgproto pid 45886: DEBUG:  memcache discarding query cache array
2022-05-28 17:14:52.612: pgproto pid 45886: DETAIL:  num_caches: 0
2022-05-28 17:14:52.612: pgproto pid 45886: DEBUG:  memcache reset buffer
2022-05-28 17:14:52.612: pgproto pid 45886: DETAIL:  create: 0x1be57a8
2022-05-28 17:14:52.612: pgproto pid 45886: DEBUG:  memcache reset buffer
2022-05-28 17:14:52.612: pgproto pid 45886: DETAIL:  discard temp buffer of 0x1be7c08 (SELECT 1)
2022-05-28 17:14:52.612: pgproto pid 45886: DEBUG:  CloseComplete: remove sent message. kind:B, name:P1
2022-05-28 17:14:52.612: pgproto pid 45886: DEBUG:  processing command complete
2022-05-28 17:14:52.612: pgproto pid 45886: DETAIL:  set transaction state to T
2022-05-28 17:14:52.612: pgproto pid 45886: DEBUG:  memcache reset buffer
2022-05-28 17:14:52.612: pgproto pid 45886: DETAIL:  discard: 0x1be57a8
2022-05-28 17:14:52.612: pgproto pid 45886: DEBUG:  memcache discarding query cache array
2022-05-28 17:14:52.612: pgproto pid 45886: DETAIL:  num_caches: 0
2022-05-28 17:14:52.612: pgproto pid 45886: DEBUG:  memcache reset buffer
2022-05-28 17:14:52.612: pgproto pid 45886: DETAIL:  create: 0x1be57a8
2022-05-28 17:14:52.612: pgproto pid 45886: DEBUG:  memcache reset buffer
2022-05-28 17:14:52.612: pgproto pid 45886: DETAIL:  discard temp buffer of 0x1be7c08 (SELECT 1)
2022-05-28 17:14:52.612: pgproto pid 45886: DEBUG:  CloseComplete: remove sent message. kind:B, name:P2

It seems the CloseComplete message was received from backend but if looking into results.txt:

FE=> Query (query="SET statement_timeout TO 1000")
<= BE CommandComplete(SET)
<= BE ReadyForQuery(I)
FE=> Parse(stmt="S1", query="SELECT 1")
FE=> Bind(stmt="S1", portal="P1")
FE=> Execute(portal="P1")
FE=> Close(portal="P1")
FE=> Bind(stmt="S1", portal="P2")
FE=> Execute(portal="P2")
FE=> Close(portal="P2")
FE=> Sync
<= BE ParseComplete
<= BE BindComplete
<= BE DataRow
<= BE CommandComplete(SELECT 1)
<= BE CloseComplete
<= BE BindComplete
<= BE DataRow
<= BE CommandComplete(SELECT 1)

It seems the frontend did not receive the CloseComplete
message. SimpleForwardToFrontend() did buffering when it forwarded the
CloseComplete message. I guess this is the cause of the timeout. So
let's change SimpleForwardToFrontend() so that it forwards
CloseComplete message without buffering and see what buildfarm says.

Skipping useless ereport/elog calls.

Although ereport() and elog() themselves are quite cheap when the error message
level is too low to be printed, some places need to do substantial work before
they can call those macros at all. message_level_is_interesting() can be handy
to allow optimizing away such setup work when nothing is to be printed.

Function message_level_is_interesting(elevel) is borrowed from PostgreSQL
source that reports whether ereport/elog will do anything.

Fix internal transaction handling bug in snapshot isolation mode.

When SELECT is executed in snapshot isolation mode, it is surrounded
in an "internal transaction".  For example if there are 3 backends,
each backend starts an internal transaction with "BEGIN" command.
However, there was an oversight in end_internal_transaction(), which
is responsible for closing the transaction. It only closed the
transaction on "load balance node". This causes a problem with certain
query following SELECT, for example VACUUM. Suppose the SELECT is
executed on backend node 2, then transaction on node 0 and node 1 were
not closed. If VACUUM is executed on node 0, it fails because the
transaction is not closed on node 0 (remember, VACUUM cannot be
executed in an explicit transaction).

Also add a test case for this to the 030.snapshot_isolation test.

Updated the sample scripts to allow ssh login user and ssh key file to be set using variables.

Fix accepting INET fd bug.

This was introduced in commit: 9f727c1e267f1363012a3af599b7d7515e4ec355.

While pgpool_main initializes itself, first accepting UNIX/INET domain
sockets are set in "fds" array.  Then forks child process.  So far so
good. Later on pgpool_main initializes pcp sockets. But at this point
it accidentally initialized "fds" array again. As a result, if child
process is forked again, wrong fds were used by those child
process. Immediate result is, frontend could not connect to pgpool by
INET domain listen addresses (-h localhost).

Problem found by Bo peng.

Enable debug1 while executing 074.bug700_memqcache_segfault.

This is necessary to pursuit occasional timeout in the test.  Also add
debug logging to pool_push_pending_data() for the same purpose.
ereport for debugging to

Add volatile modifier to a variable used in the query cache module.

"sts" variable used in pool_fetch_memory_cache() did not have volatile
modifier although it is used in PG_TRY() block. If an exception arises
the value set to variable will be lost in the PG_CATCH block. The bad
effect of this will not be triggered unless error occurs and I think
the bad effect has rarely been observed in the wild (as for as I know,
I have never heard such a report). Anyway, bug is bug.

Doc: add release notes.

Doc: move the example of "Pgpool-II on Kubernetes" to https://github.com/pgpool/pgpool2_on_k8s/tree/master/docs.

Enhance in stopping pgpool main process.

If "pgpool stop" couldn't terminate the main process within certain
period (currently 5 seconds), send the signal again. The reason why
pgpool does not accept the stopping signal is not clear at the moment,
I expect this reduces errors of buildfarm timeout. See if this works.

Fix comment.

Fix not to abort session while in failed transaction.

When an explicit transaction fails, subsequent commands should be
ignored until commit or rollback command comes in. However pgpool
sometimes aborted the session if relcache lookup happened. example:

test=# begin;
BEGIN
test=*# insert into ttt values(1);
ERROR:  relation "ttt" does not exist
LINE 1: insert into ttt values(1);
                    ^
test=!# select * from t1;
FATAL:  Backend throw an error message
DETAIL:  Exiting current session because of an error from backend
HINT:  BACKEND Error: "current transaction is aborted, commands ignored until end of transaction block"
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Succeeded.

To prevent  this, check the transaction  state and if it's  already in
aborted state, do not try to  process the command, but just reply back
to frontend with an error message:

ERROR:  current transaction is aborted, commands ignored until end of transaction block

By the way, while implementing the fix, I found old bugs with replication mode.

- ReadyForQuery() mistakenly called end_internal_transaction() even if
  it's not in replication/si mode. Moreover,
  end_internal_transaction() is called even if the internal
  transaction has not started.

- end_internal_transaction() did not call pool_unset_failed_transaction();

These bugs were harmless until I tried to fix the issue (session
aborting).

New regression test 078 for this added.

Discussion: https://www.pgpool.net/pipermail/pgpool-general/2022-April/008155.html

Doc: update configuration example.

Change the PID length of pcp_proc_count command to 7 characters long.

Doc: update the example output of pcp_watchdog_info.

Doc: update the example output of pcp_watchdog_info.

Doc: mention that escaping is required if you are providing the password as an argument to pg_enc and the password contains a "$" character.

Fix for [pgpool-general: 7896] Possible race condition..

Watchdog does not allow the remote nodes reported lost by life-check to rejoin
the cluster until the life-check process confirms the existence of life in the
previously lost nodes. This is good enough except for the case when the
(lost by life-check) node tries to rejoin the cluster after it was restarted
(Pgpool-II service restarted).
What happens is the cluster keeps rejecting the restarted node because
the cluster's life-check doesn't agree while the restarted node's life-check
waits to be added to cluster before it can start sending the heart-beats.

The fix is to allow the previously lost remote node become the part of the
cluster after restart, no matter the lost-reason.

Issue report:
https://www.pgpool.net/pipermail/pgpool-general/2021-November/007954.html

Revert "Attempt to fix buildfarm timeout error."

This reverts commit 480c0ce0b76828428fd4823160012bb44d5eb53f.

It seems the fix is useless and causes problem with failover.

Attempt to fix buildfarm timeout error.

After inspecting the buildfarm log, I noticed it seems as if terminate
signal was ignored.  My theory is system(3), which is used in
trigger_failover() ignores SIGINT and SIGQUIT.  To deal with this,
check the return value of system(3) to determine whether signal was
sent while executing system(3). If so, call exit_handler after
failover.

Add more logging to exit_handler in pgpool main process.

Improve regression test to detect segmentation fault.

Test: stabilize 018.detach_primary.

The test occasionally failed with timeout. The cause seems the test
proceeds before watchdog are ready.  So wait till watchdog is ready
using pcp_watchdog_info.

Test: enhance 074.bug700_memqcache_segfault

Set statement_timeout at the beginning of the test to avoid the time
out error because it takes long time before failure.

Fix exit_handler in pgpool main process.

It was allowed to be interrupted by signals (SIGTERM, SIGINT and
SOGQUIT) while the exit_handler. As a resit, exit_handler is executed
while executing exit_handler. This could cause infinite wait in
terminate_childrens() which is called from exit_handler.  To prevent
this, protect variable "exiting" using semaphore to make sure that
only one instance of exit_handler runs at the same time.

Discussion: https://www.pgpool.net/pipermail/pgpool-hackers/2022-April/004149.html

Fix memory leak pointed out by Coverity.

Fix pgpool child process to obtain process information.

ProcesInfo was obtained by using pool_get_process_info(). But this API
is not suitable for child process because:

- does inefficient linear search over all ProcessInfo slots (there are
  num_init_children slots).

- due to race condition the search key pid might not be set or removed
  in the slot. I think it is possible that by the time when child
  process starts execution, the pid is not yet set in the slot in the
  shared memory. Also when child process is killed by parent process,
  it may set pid to 0 before the child process receive kill signal.

So use pool_get_my_process_info() instead of pool_get_process_info().
which just returns the slot by using global variable my_proc_id as a
key and let child process use it.  my_proc_id was set by the parent
process when the child process was spawn.

The call to pool_get_process_info() in child.c was added in v4.3. So
back patch to V4_3_STABLE.

Revert "Fix pgpool child process to obtain process information."

This reverts commit 06f69d19030deb1d72230ce489c5a4d800ad593c.

Fix pgpool child process to obtain process information.

ProcesInfo was obtained by using pool_get_process_info(). But this API
is not suitable for child process because:

- does inefficient linear search over all ProcessInfo slots (there are
  num_init_children slots).

- due to race condition the search key pid might not be set or removed
  in the slot. I think it is possible that by the time when child
  process starts execution, the pid is not yet set in the slot in the
  shared memory. Also when child process is killed by parent process,
  it may set pid to 0 before the child process receive kill signal.

So add new API pool_get_process_info_by_process_id() which just
returns the slot by using global variable my_proc_id as a key and let
child process use it.  my_proc_id was set by the parent process when
the child process was spawn.

The call to pool_get_process_info() in child.c was added in v4.3. So
back patch to V4_3_STABLE.

Fix shared memory allocation function.

pool_shared_memory_segment_get_chunk() which is responsible for shared
memory allocation, failed to consider request size alignment. If
requeste size is not in MAXALIGN (typically 8) bytes, it could overrun
the shared memory area. Probably harmless in the wild but better to
fix.

Fix possible null pointer dereference per Coverity.

Revert "Prevent hang in terminate_all_childrens()."

This reverts commit a5e2e0411dc3ef91aafc8f4c5e1d7369e7eb3b46.

Prevent hang in terminate_all_childrens().

waitpid() was used in the function without WNOHANG was being set.
This could cause hang in waitpic().
Also fix typo. Rename terminate_all_childrens to terminate_all_children.

Fix logging for disabled pool_passwd

Refrain from emitting 'password file descriptor is NULL' warning
and error messages when pool_passwd is disabled.

Add pending signal check in check_requests().

Still struggling why shutdown signal is not delivered. For this
purpose add sigpending() before release the signal mask.

Allow shutdown interrupt while processing SIGCHILD in pgpool main.

Currently most signals are blocked in pgpool main loop. In some
situations the SIGCHLD handler (reaper()) takes long time or blocked
in wait system call. I suspect that this could cause occasional
timeout in some regression tests. So allow interrupts while executing
reaper(). Also re-implement CHECK_REQUEST macro as a function. There's
no point to implement CHECK_REQUEST using macro.