Doc: Update doc version.

Prepare 4.2.23.

Doc: add release notes.

Doc: Update sample script links in "8.2. Pgpool-II + Watchdog Setup Example"

This is a follow-up to commit 6f2d48e.
Updated the sample script links in section "8.2. Pgpool-II + Watchdog Setup Example" to point to the GitHub repository file URLs.

Doc: fix documentation for parameters that are not
 reflected by reload.

"authentication_timeout" and "memqcache_oiddir" is not reflected by reload.
The documentation is changed to "This parameter can only be set at server start.".
Japanese doc too.

Backpatch-through: v4.2

Fix watchdog to print inappropriate NOTICE message.

read_ipc_socket_and_process() printed a notice message every time when
it wrote commands to IPC socket even if it was successful. Fix this to
print the notice message only when the write failed.

The reason why this bug was not recognized is, the message appears
only when log_min_messages is set to notice or higher.

Discussion: https://github.com/pgpool/pgpool2/issues/121
Backpatch-through: v4.2

Doc: unify watchdog leader terms (followup).

This is a followup commit to 222a88a751c75acfc809e06559621699255921f7.

This commit updates advaced.sgml.

Backpatch-trhough: v4.2

Doc: unify watchdog leader terms.

Previously terms "leader", "active" and "coordinator" were used to
mean the leader watchdog node.  This brought enough confusion. So this
commit unifies them to "leader"."

Backpatch-trhough: v4.2

Fix resource leak while reading startup packet.

Per Coverity.

Backpatch-through: v4.2

Fix memory leak.

Fix resource leak in pool_push_pending_data pointed out by Coverity.

Backpatch-through: v4.2

Doc: Fix example script link at V4_2.

Modified the sample script in the section "8.2. Pgpool-II + Watchdog Setup Example"

Fix broken scram-sha-256 authentication on big-endian machies.

When scram-sha-256 authentication is performed, a hash function
pg_sha_256_final is used. It was imported from PostgreSQL and it uses
preprocessor define WORDS_BIGENDIAN to judge host machine's
endianness. Although WORDS_BIGENDIAN should be defined while
configure, this part was missed when pg_sha_256_final (and others) was
imported from PostgreSQL. As a result, scram-sha-256 worked only in
little endian machines. This commit fixes the issue by adding
AC_C_BIGENDIAN macro to configure.ac.

Author: Tatsuo Ishii
Reported-by: Christoph Berg
Reviewed-by: pranavkaruvally
Discussion: https://github.com/pgpool/pgpool2/issues/106
Backpatch-through: v4.2

Fix source code typos.

Doc: fix load balance explanation missed logical replication mode.

Backpatch-through: v4.2

Doc: fix load balance explanation missed Slony mode.

Since Slony mode will gone in master branch, fix is not applied to
master branch.

Backpatch-through: v4.6 to v4.2

Test: stabilize 029.cert_passphrase regression test.

When ssl_passphrase_command is not valid, the error message is
typically "bad decrypt" but it seems sometimes "wrong tag".

This is a backport of master e30bb2ead.

Backpatch-through: v4.6 - v4.2.

Fix heartbeat_device treatment.

While processing pgpool.conf, heartbeat_device was mistakenly treated
and the first device was ignored. For example:

heartbeat_device0 = 'eth0'

the configuration process disregarded 'eth0' and acted as if no device
was set. Another example:

heartbeat_device0 = 'eth0;eth1'

"eth0" was simply ignored.

Reviewed-by: Bo Peng <pengbo@sraoss.co.jp>
Backpatch-through: v4.2

Doc: add section of kernel resources.

Pgpool-II uses System V shared memory and semaphores. It's better to
describe the requirements in the docs.

Backpatch-through: v4.2

Doc: add description for --with-ldap option of configure.

It was missed when LDAP support was introduced in v4.2
Backpatch-through: v4.2

Doc: clarify supported platforms for Pgpool-II.

Backpatch-through: v4.2

Doc: enhance child_life_time document.

Backpatch-through: v4.2

Update Makefile.in

Suppress unnecessary information upon authentication failure.

Previously a message "password size does not match" was displayed when
client authentication failed.  This could help an attacker to guess
password. Replace it just "password does not match".

Backpatch-through: v4.2

Doc: Update release notes to include details of the vulnerability fix.

Prepare 4.2.22

Doc: update release note.

Fix incorrect client authentication in some cases.

If enable_pool_hba = on, it's auth method is "password", no password
is registered in pool_passwd, and auth method in pg_hba.conf is
"scram-sha-256" or "md5", for the first time when a client connects to
pgpool, authentication is performed as expected. But if a client
connects to the cached connection, any password from the client is
accepted.

authenticate_frontend() asks password to the client and stores it in
frontend->password.  When pgpool authenticate backend,
authenticate_frontend_SCRAM() or authenticate_frontend_md5() is called
depending on pg_hba.conf setting. authenticate_frontend_*() calls
get_auth_password() to get backend cached password but it mistakenly
returned frontend->password if pool_passwd does not have an entry for
the user. Then authenticate_frontend_*() tries to challenge based on
frontend->password. As a result, they compared frontend->password
itself, which always succeed. To fix this, when get_auth_password() is
called with reauth parameter being non 0, return backend->password.

Also if enable_pool_hba = off, in some cases a client is not asked
password for the first time, or when a client connects to cached
connection, even if it should be.

If pool_hba.conf is disabled, get_backend_connection() does not call
Client_authentication(), thus frontend->password is not set. Then
pool_do_reauth() calls do_clear_text_password(). It should have called
authenticate_frontend_clear_text() to get a password from the client,
but a mistake in a if statement prevented it. The mistake was fixed in
this commit.

Pgpool-II versions affected: v4.0 or later.

Also this commit does followings:

- Remove single PostgreSQL code path to simplify the authentication
  code. As a result, following cases are no more Ok.

- Remove crypt authentication support for frontend and backend. The
  feature had not been documented and never tested. Moreover crypt
  authentication was removed long time ago in PostgreSQL (8.4, 2009).

- Add new regression test "040.client_auth". The test performs
  exhaustive client authentication tests using a test specification
  file formatted in CSV.
  The csv files have 7 fields:
  username: the username used for the test case

  pool_hba.conf: takes "scram", "md5", "password", "pam", "ldap" or
  "off". If "scram", "md5" , "password", "pam" or "ldap", the user
  will have an entry in pool_hba.conf accordingly. If "off",
  enable_pool_hba.conf will be off.

  allow_clear_text_frontend_auth: takes "on" or "off".

  pool_passwd: takes "AES", "md5" or "off". If "AES" or "md5" the
  user's password will be stored in pool_passwd using ASE256 or md5
  encryption method accordingly. If "off" is specified, no entry will
  be created.

  pg_hba.conf: almost same as pool_hba.conf except this is for
  pg_hba.conf.

  expected: takes "ok" or "fail". If ok, the authentication is
  expected to be succeeded. If failed, the test is regarded as
  failed. "fail" is opposite. The authentication is expected to be
  failed. If succeeds, the test regarded as failed.

  comment: arbitrary comment

  By changing these fields, we can easily modify or add test
  cases. The merit of this method is possible higher test
  coverage. For human, it is easier to find uncovered test cases in a
  table than in a program code.

Backpatch-through: v4.2

The patch was created by Tatsuo Ishii.

Doc: add release notes.

Fix long standing bind bug with query cache.

When a named statement is prepared, it is possible to bind then
execute without a parse message. Problem is, table oids which are
necessary to invalidate query cache at execute or COMMIT was collected
only in parse messages process (Parse()). Thus if bind is executed
without parse after previous execute, no table oids were collected,
and pgpool failed to invalidate query cache.

Fix is collecting table oids at bind time too.

Add regression test to 006.memqcache.

Problem reported by and test program provided by Achilleas Mantzios
<a.mantzios@cloud.gatewaynet.com>.

Discussion: [pgpool-general: 9427] Clarification on query results cache visibility
https://www.pgpool.net/pipermail/pgpool-general/2025-April/009430.html

Backpatch-through: v4.2

Fix query cache invalidation bug.

When an execute message is received, pgpool checks its max number of
rows paramter. If it's not zero, pgpool sets "partial_fetch" flag to
instruct pool_handle_query_cache() to not create query cache.  Problem
is, commit 2a99aa5d1 missed that even INSERT/UPDATE/DELETE sets the
execute message parameter to non 0 (mostly 1) and pgpool set the flag
for even none SELECTs. This resulted in failing to invalidate query
cache because if the flag is true, subsequent code in
pool_handle_query_cache() skips cache invalidation.  It was an
oversight in this commit (my fault):
https://git.postgresql.org/gitweb/?p=pgpool2.git;a=commit;h=2a99aa5d1910f1fd4855c8eb6751a26cbaa5e48d

To fix this change Execute() to check if the query is read only SELECT
before setting the flag.

Also add test to 006.memqcache.

Problem reported by and a test program provided by Achilleas Mantzios <a.mantzios@cloud.gatewaynet.com>.

Discussion: [pgpool-general: 9427] Clarification on query results cache visibility
https://www.pgpool.net/pipermail/pgpool-general/2025-April/009430.html

Backpatch-through: v4.2

Fix portability to OpenBSD.

- va_list is defined stdarg.h[0]
- pthread_t is defined in pthread.h / sys/types.h[1]
  On OpenBSD sys/types.h doesn't suffice, so include pthread.h.
- LibreSSL has removed HMAC_CTX_init(), and has support for HMAC_CTX_new
  since 2018. I've talked to Theo Buehler of LibreSSL and he said that he'd
  prefer to simply remove the LIBRESSL_VERSION_NUMBER, but if desired by
  upstream the LIBRESSL_VERSION_NUMBER should be 0x2070100fL.
- WIFEXITED is defined in sys/wait.h[2]

Author: Martijn van Duren (pgpool@list.imperialat.at)
Discussion: https://www.pgpool.net/pipermail/pgpool-hackers/2025-May/004583.html
Backpatch-through: v4.2

Add major version information to the configuration file.

Fix json_writer did not properly encode special characters.

Pgpool would crash when the watchdog was enabled if wd_authkey contained special characters (e.g., a backslash).

The patch was originally created by Martijn van Duren and revised by Bo Peng.

Update pgpool.spec to prevent RPM build errors.

Doc: enhance the description on connection_life_time

connection_life_time is a config value to determine the life time of
cached connections to PostgreSQL backend. Current document lacks a
description that the expiration calculation is actually done at the
time when the client disconnects to the process which holds the cached
connections.

Discussion: [pgpool-hackers: 4577] Doc: enhance the description on connection_life_time
https://www.pgpool.net/pipermail/pgpool-hackers/2025-April/004578.html
Backpatch-through: v4.2

Doc: enhance the explanation on sr_check_user.

It must be a superuser or in the pg_monitor group.

Backpatch-through: v4.2.

Fix sr check and health check to reopen pool_passwd upon reload.

The streaming replication check and health check process forgot to
reopen pool_passwd upon reload.  If sr_check_passwd or
health_check_passwd is empty string, the password is obtained from
pool_passwd. Thus those process read outdated content of pool_passwd
upon reload.

Backpatch-through: v4.2

Prepare 4.2.21

Doc: update copyright

Update sample scripts.

Prepare 4.2.21

Doc: add release notes.

Remove pg_basebackup from the sample follow primary script.

If pg_rewind fails, the safest way for users is to recover manually.

Fix per_node_error_log() error message that is printed with two colons.

Patch is created by Umar Hayat.

Doc: enhance client authentication chapter.

Add intro about pool_passwd. Previously there was only description on
pool_hba.conf in the overview page. A general guide to pool_passwd
will help users to understand this chapter.

Test: stabilize 032.dml_adaptive_loadbalance

Occasionally the test failed due to:
ERROR:  relation "t2" does not exist
LINE 1: SELECT i, 'QUERY ID T1-1' FROM t2;

It seems the cause is that newly created table t2 takes sometime to
get replicated to standby. So insert "sleep 1" after the table
creation.

Backpatch-through: v4.2

Fix pool_signal.

Previously pool_signal did not set SA_RESTART flag.  Thus any system
calls interrupted by a signal does not restart. Some of our code are
prepared so that they restart if a system call is interrupted by a
signal. But not sure all places are prepared too. So add the
flag. Note, PostgreSQL always uses the flag.

Fix yet another query cache bug in streaming replication mode.

If query cache is enabled and query is operated in extended query mode
and pgpool is running in streaming replication mode, an execute
message could return incorrect results.

This could happen when an execute message comes with a non 0 row
number parameter. In this case it fetches up to the specified number of
rows and returns "PortalSuspended" message. Pgpool-II does not create
query cache for this.  But if another execute message with 0 row
number parameter comes in, it fetches rest of rows (if any) and
creates query cache with the number of rows which the execute messages
fetched.

Obviously this causes unwanted results later on: another execute
messages returns result from query cache which has only number of rows
captured by the previous execute message with limited number of rows.

Another trouble is when multiple execute messages are sent
consecutively.  In this case Pgpool-II returned exactly the same
results from query cache for each execute message. This is wrong since
the second or subsequent executes should return 0 rows.

To fix this, new boolean fields "atEnd" and "partial_fetch" are
introduced in the query context. They are initialized to false when a
query context is created (also initialized when bind message is
received). If an execute message with 0 row number is executed, atEnd
is set to true upon receiving CommandComplete message. If an execute
message with non 0 row number is executed, partial_fetch is set to
true and never uses the cache result, nor creates query cache.

When atEnd is true, pgpool will return CommandComplete message with
"SELECT 0" as a result of the execute message.

Also tests for this case is added to the 006.memqcache regression
test.

Backpatch-through: v4.2
Discussion: [pgpool-hackers: 4547] Bug in query cache
https://www.pgpool.net/pipermail/pgpool-hackers/2024-December/004548.html

Doc: Fix the documentation typos.

Fixed an issue where pg_md5 and pg_enc would not update the password file if a file other than the default value was specified in the pool_passwd parameter.

This issue is reported by Sadhuprasad Patro.

Test: fix 006.memqcache regression test.

4dd7371c2 added test cases. SQL syntax used in the test was not
compatible with PostgreSQL 15 or earlier.

Backpatch-through: v4.2

Fix query cache bug in streaming replication mode.

When query cache is enabled and an execute message is sent from
frontend, pgpool injects query cache data into backend message buffer
if query cache data is available. inject_cached_message() is
responsible for the task. But it had an oversight if the message
stream from frontend includes more than one sets of bind or describe
message before a sync message. It tried to determine the frontend
message end by finding a bind complete or a row description message
from backend. But in the case, it is possible that these messages do
not indicate the message stream end because there are one more bind
complete or row description message. As a result the cached message is
inserted at inappropriate positron and pgpool mistakenly raised "kind
mismatch" error.

This commit changes the algorithm to detect the message stream end:
compare the number of messages from backend with the pending message
queue length. When a message is read from backend, the counter for the
number of message is counted up if the message is one of parse
complete, bind complete, close complete, command compete, portal
suspended or row description. For other message type the counter is
not counted up. If the counter reaches to the pending message queue
length, we are at the end of message stream and inject the cahced
messages.

Test cases for 006.memqcache are added.

Backpatch-through: v4.2.

Prepare 4.2.20

Doc: Bump version to 4.2.20

Doc: add release notes.

Abort SSL negotiation if backend sends an error message.

In the client side implementation of SSL negotiation
(pool_ssl_negotiate_clientserver()), it was possible for a
man-in-the-middle attacker to send a long error message to confuse
Pgpool-II or client while in the SSL negotiation phase. This commit
rejects the negotiation immediately (issue a FATAL error) and exits
the session to prevent such an attack.

This resembles PostgreSQL's CVE-2024-10977.
Backpatch-through: v4.1

Test: adapt 024.cert_auth test to OpenSSL 3.2.

In the test we check the error message when the target certificate is
revoked.  Unfortunately the error message from OpenSSL seems to be
changed from v3.0 to v3.2.

v3.0 or before: "sslv3 alert certificate revoked"
v3.2: "ssl/tls alert certificate revoked"

So fix is checking only "alert certificate revoked" part.

Test: another attempt to fix 024.cert_auth failure on RockyLinux9.

Renew cert.sh using examples in PostgreSQL docs.

Fix the watchdog process not reloading configurations.

The reload_config() function in Pgpool-II should send a SIGHUP signal to the watchdog process.

Fix bug in do_query.

Upon receiving DataRow packet, it converts the number of fields from
network byte order to host byte order.  Unfortunately it used htons()
for this purpose instead of ntohs(). This is simply wrong. Similarly it
used htonl() instead of htohl() while converting the data length from
network byte order to host byte order. This is wrong too. But
fortunately both ntohs()/htons() and ntohl()/htonl() swap the byte and
they bring the same result (i.e. htonl(data_len) ==
ntohl(data_len). So actually the bug does not hurt anything.
However a bug is a bug. This commit fixes them.

Backpatch-through: v4.1

Fix authentication failure after updating pool_passwd and reload.

If pool_hba.conf is disabled, updating pool_passwd was not recognized
by pgpool child process even if pgpool reload was performed.  The
reload processing function check_config_reload() mistakenly assumed
that reopening pool_passwd was only necessary when enable_pool_hba is
on.

Backpatch-through: v4.1
Discussion: https://www.pgpool.net/pipermail/pgpool-general/2024-November/001944.html

Test: add test for COPY FROM STDIN hang.

This is a follow up commit for commit:
ab091663b09ef8c2d0a1841921597948c597444e

Add test case using pgproto to existing 076.copy_hang.
Backpatch-through: v4.1

Fix COPY hangs.

During COPY IN state (i.e. COPY FROM STDIN), frontend can send Flush
or Sync messages.  According to the F/B protocol specification, they
should be ignored but Pgpool-II treated as an invalid message and this
causes COPY hung.

Discussion: https://github.com/pgpool/pgpool2/issues/79
Backpatch-through: v4.1

Fix Pgpool-II child process crash during shutdown.

It is reported that pgpool child process crashes during shutdown.
[pgpool-general: 9261] Re: Segmentation fault during shutdown

The actual crash was in close_all_backend_connections().
close_all_backend_connections() was called because on_system_exit
registers child_will_go_down(). At the moment it seems pgpool child
had just started up and doing pool_init_cp(). The connection pool
object had not been completely initialized, that's cause of the crash.

To fix this, introduce a new static variable in child.c and set it
true when the connection pool object is initialized. In
child_will_go_down() it is checked and close_all_backend_connections()
is called only when the variable is set to true.

Problem reported and analyzed by: Emond Papegaaij
Backpatch-through: v4.2
Discussion: https://www.pgpool.net/pipermail/pgpool-general/2024-November/001938.html

Revert "Fix Pgpool-II child process crash during shutdown."

This reverts commit 5a4be7eb77366fdbc4dabddf4f17742c3c929f74.

Per discussion: [pgpool-general: 9265] Re: Segmentation fault during shutdown
https://www.pgpool.net/pipermail/pgpool-general/2024-November/001942.html

Fix Pgpool-II child process crash during shutdown.

It is reported that pgpool child process crashes during shutdown.
 [pgpool-general: 9261] Re: Segmentation fault during shutdown

The actual crash was in close_all_backend_connections().
close_all_backend_connections() was called because on_system_exit
registers child_will_ho_down(). At the moment it seems pgpool child
had just started up and doing pool_init_cp(). The connection pool
object had not been completely initialized, that's cause of the crash.

To fix this, just remove the call to close_all_backend_connections()
in child_will_ho_down(). Although this will prevent the terminate
message ('X') being sent to backend, it should be harmless since
backend can take care such a disconnection without a terminate
message.

Problem reported and analyzed by: Emond Papegaaij
Backpatch-through: v4.2
Discussion: https://www.pgpool.net/pipermail/pgpool-general/2024-November/001938.html

Fix sporadic health check failures due to authentication failure.

It is reported that health check process fails due to authentication
failures.
[pgpool-general: 9236] Sporadic health check failures due to authentication failure
https://www.pgpool.net/pipermail/pgpool-general/2024-October/001913.html

When health_check_password is empty string, health check process looks
for the password from pool_passwd file. Problem is, the file
descriptor for the file is inherited from parent pgpool process. This
means that pgpool main and health check process (possibly multiple
process) share the same descriptor, which causes various problem
including the issue reported here. To fix the problem, re-open the
file when health check process starts so that each health check
process owns its own file descriptor.

Note that pgpool child process (responsible for frontend sessions)
already re-opens the file descriptor and they are related to the
issue.

Problem reported and analyzed by Emond Papegaaij.
Backpatch-through: v4.1
Discussion: https://www.pgpool.net/pipermail/pgpool-general/2024-October/001913.html

Optimize query cache invalidation for ALTER ROLE.

Commit 6b7d585eb1c693e4ffb5b8e6ed9aa0f067fa1b89 invalidates query
cache if any ALTER ROLE/USER statement is used. Actually this is an
overkill. Because following queries do not affect the privilege of the
role.

- ALTER ROLE user WITH [ENCRYPTED] PASSWORD
- ALTER ROLE user WITH CONNECTION LIMIT

So do not invalidate query cache if those commands are used.

Backpatch-through: v4.1
Discussion: https://www.pgpool.net/pipermail/pgpool-hackers/2024-October/004532.html

Doc: Fix typos in the documentation and sample configuration file.

Fix pgpool crash when pgpool child process exits.

When a pgpool child process exits, close_all_backend_connections() is
called, which is responsible for closing all connections to backend in
the connection pool. It used mistakenly MAIN_CONNECTION macro, which
is fine for current active connections but is not good for pooled
connections because a main node could be different at the time when
the connection pool was created. Fix is using in_use_backend()
instead.

Reported-by: Emond Papegaaij
Backpatch-through: v4.2

Fix resource leaks in pool_memqcache.c.

These leaks were brought in by commit 6fdba5c33 " Use psprintf()
instead of snprintf()."  Since the commit was backpatched through 4.1,
this needs to be backpatched through 4.1 too.

Per Coverity (CID 1559726).
Backpatch-through: 4.1.

Fix pool_push_pending_data().

Fix "insecure data handling".
Per Coverity (CID 1559731)

Fix another bug in native replication/snapshot isolation mode.

insert_lock() forgot to send row lock command (lock_kind == 3 case) to
other than main node.

Fix bug in replication/snapshot isolation mode.

When INSERT command is received, pgpool automatically issues table
LOCK command to the target table but it forgot to send the command to
other than main nodes. This only happened in extended query mode.
This commit fixes the bug.

Discussion: GitHub issue #69.
https://github.com/pgpool/pgpool2/issues/69
Backpatch-through: v4.1

Fix resource leaks in pool_memqcache.c.

6fdba5c33

These leaks were brought in by commit 6fdba5c33 " Use psprintf()
instead of snprintf()."  Since the commit was backpatched through 4.1,
this needs to be backpatched through 4.1 too.

Per Coverity (CID 1559736).
Backpatch-through: 4.1.

Prepare 4.2.19

Doc: Bump version to 4.2.19

Doc: add release notes.

Fix multiple query cache vulnerabilities (CVE-2024-45624).

When the query cache feature is enabled, it was possible that a user
can read rows from tables that should not be visible for the user
through query cache.

- If query cache is created for a row security enabled table for user
  A, and then other user B accesses the table via SET ROLE or SET
  SESSION_AUTHORIZATION in the same session, it was possible for the
  user B to retrieve rows which should not be visible from the user B.

- If query cache is created for a table for user A, and then other
  user B accesses the table via SET ROLE or SET SESSION_AUTHORIZATION
  in the same session, it was possible for the user B to retrieve rows
  which should not be visible from the user B.

- If query cache is created for a table for a user, and then the
  access right of the table is revoked from the user by REVOKE
  command, still it was possible for the user to to retrieve the rows
  through the query cache.

Besides the vulnerabilities, there were multiple bugs with the query
cache feature.

- If query cache is created for a row security enabled table for a
  user, and then ALTER DATABASE BYPASSRLS or ALTER ROLE BYPASSRLS
  disable the row security of the table, subsequent SELECT still
  returns the same rows as before through the query cache.

- If query cache is created for a table for a user, and then ALTER
  TABLE SET SCHEMA changes the search path to not allow to access the
  table, subsequent SELECT still returns the rows as before through
  the query cache.

To fix above, following changes are made:

- Do not allow to create query cache/use query cache for row security
  enabled tables (even if the table is included in
  cache_safe_memqcache_table_list).

- Do not allow to create query cache/use query cache if SET ROLE/SET
  AUTHORIZATION is executed in the session (query cache invalidation
  is performed when a table is modified as usual).

- Remove entire query cache if REVOKE/ALTER DATABASE/ALTER TABLE/ALTER
  ROLE is executed. If the command is executed in an explicit
  transaction, do not create query cache/use query cache until the
  transaction gets committed (query cache invalidation is performed
  when a table is modified as usual). If the transaction is aborted,
  do not remove query cache.

Patch is created by Tatsuo Ishii.

Backpatch-through: v4.1

Revert "Doc: mention that reloading is not necessary when pool_passwd is updated."

This reverts commit 41e57cdb3181c61a5d2f8bf8f216d71dad283daf.

"reloading is not necessary when pool_passwd is updated." was not
correct. Since reading pool_passwd in pgpool uses a buffered read,
it's too fragile to assume that changes to pool_passwd by different
process is immediately available for pgpool process. To reflect the
changes, pgpool reload (which causes re-opening pool_passwd). is
necessary.

Discussion: [pgpool-general: 9185] reloading of pool_passwd file
https://www.pgpool.net/pipermail/pgpool-general/2024-August/001862.html

Doc: mention that reloading is not necessary when pool_passwd is updated.

Discussion: [pgpool-general: 9185] reloading of pool_passwd file
https://www.pgpool.net/pipermail/pgpool-general/2024-August/001862.html
Backpatch-through: v4.1

Back port notice_per_node_statement.

This is mainly for testing.

Backpatch-through: v4.1
Dicussion: [pgpool-hackers: 4504] Proposal to backport notice_per_node_statement
https://www.pgpool.net/pipermail/pgpool-hackers/2024-August/004505.html

Fix another bug in replication mode and snapshot isolation mode.

This is a follow up commit for 181d300de6337fe9a10b60ddbd782aa886b563e9.

If previous query produces parameter status message, subsequent
parse() needs to read and process it because it wants to read Ready
for query message which is supposed to follow the parameter status
message.  However when ParameterStatus() gets called, the query in
progress flag was set and it was possible that only one of parameter
status message from backend was processed if the query processed in
this parse() call is load balanced. It is likely that the parameter
status message comes from all live backend because they are generated
by SET command, and SET command are sent to all live backend in
replication mode and snapshot isolation mode. So unset the query in
progress flag before calling ParameterStatus().

Here is the test case written in pgproto data format.

'P' "" "SET application_name TO foo"
'B' "" "" 0 0 0
'E' "" 0
'P' "" "SELECT 1"
'B' "" "" 0 0 0
'E' "" 0
'P' "" "SET application_name TO bar"
'B' "" "" 0 0 0
'E' "" 0
'S'
'Y'
'X'

Backpatch-through: v4.1.

Fix bug in replication mode and snapshot isolation mode.

In replication mode and snapshot isolation mode when a command fishes,
pgpool waits for a ready for query message but forgot that some
commands (for example SET ROLE) produces a parameter status
message. As a result pgpool errors out that other message arrives
before the ready for query message.  Deal with the case when a
parameter status message arrives.

Here is the test case written in pgproto data format.

'P' "" "SET ROLE TO foo"
'B' "" "" 0 0 0
'E' "" 0
'P' "" "SELECT 1"
'B' "" "" 0 0 0
'E' "" 0
'S'
'Y'

Backpatch-through: v4.1.

Prepare 4.2.18

Doc: Bump version to 4.2.18

Doc: add release notes.

Remove unnecessary code surrounded by ifdef NOT_USED.

Remove unnecessary code surrounded by ifdef NOT_USED.

Comment: fix typo in comment.

Use psprintf() instead of snprintf().

Previously fixed size buffers were used for snprintf in the file. It's
not appropriate to use snprintf here because the result string could
exceed the buffer size and it could lead to incomplete command or path
used after.

Backpatch-through: 4.1.

Use "psql -V" instead of "initdb -V" in sample scripts.

Use "psql -V" instead of "initdb -V" in the sample scripts
bacause in some cases postgresqlxx-server may not be installed.

Fix hang after a flush message received.

Previously pgpool could hang after a flush message arrives. Consider
following scenario:

(1) backend sends a portal suspend message.
(2) pgool write it in the frontend write buffer. But not flush it.
(3) The frontend sends a flush message to pgpool.
(4) pgpool fowards the flush message to backend.
(5) Since there's no pending message in backend, nothing happen.
(6) The frontend waits for the portal suspend message from pgpool in vain.

To fix this, at (4) pgpool flushes data in the frontend write buffer
if some data remains (in this case the portal suspend message). Then
the frontend will send next request message to pgpool.

Discussion: https://github.com/pgpool/pgpool2/issues/59
Backpatch-through: master, 4.5, 4.4, 4.3, 4.2 and 4.1.

Remove dead code.

Remove dead code surrounded by "#ifdef NOT_USED".

Fix another segmentation fault.

It is reported that pgpool child segfaulted in pool_do_auth. The cause
was MAIN_CONNECTION() returns NULL. It seems my_main_node_id was set
to incorrect node id 0, which was actually in down status. thus there
was no connection in cp->slots[0]. In this particular case a client
connected to pgpool while failover occurred in another pgpool node,
and it was propagated by watchdog, which changed backend_status in
shared memory. new_connection() properly updates my_backend_status but
it forgot to update my_main_node_id, and MAIN_CONNECTION returned
incorrect backend id.

Problem reported by: Emond Papegaaij
Discussion: [pgpool-general: 9175] Segmentation fault
https://www.pgpool.net/pipermail/pgpool-general/2024-July/001852.html
Backpatch-through: V4.1.

Fix segfault to not use MAIN_NODE macro.

Some functions (close_idle_connection(), new_connection() and
pool_create_cp()) used MAIN* and VALID_BACKEND where they are not
appropriate. MAIN* and VALID_BACKEND are only useful against current
connections to backend, not for pooled connections since in pooled
connections which backend is the main node or up and running is
necessarily same as the current connections to backend.
The misuses of those macros sometimes leads to segfault.

This patch introduces new in_use_backend_id() which returns the fist
node id in use. This commit replaces some of MAIN* with the return
value from in_use_backend_id(). Also inappropriate calls to
VALID_BACKEND are replaced with CONNECTION_SLOT macro.

Problem reported by Emond Papegaaij
Discussion: https://www.pgpool.net/pipermail/pgpool-general/2024-June/009176.html
[pgpool-general: 9114] Re: Another segmentation fault
Backpatch-through: V4.1

Fix MAIN_NODE macro (actually pool_virtual_main_db_node_id()).

The macro used to REAL_MAIN_NODE_ID if there's no session context.
This is wrong since REAL_MAIN_NODE_ID can be changed any time when
failover/failback happens.  Suppose REAL_MAIN_NODE_ID ==
my_main_node_id == 1. Then due to failback, REAL_MAIN_NODE_ID is
changed to 0. Then MAIN_CONNECTION(cp) will return NULL and any
reference to it will cause segmentation fault. To prevent the issue we
should return my_main_node_id instead.

Discussion: https://www.pgpool.net/pipermail/pgpool-general/2024-June/009205.html
Backpatch-through: V4.1

Fix typo in comment.

Doc: add the missing default values for virtual IP related parameters.

Fix "show pool_processes" to not show row description twice.

processes_reporting() accidentaly called both send_row_description()
and send_row_description_and_data_rows().

Discussion: https://www.pgpool.net/pipermail/pgpool-hackers/2024-June/004472.html
    [pgpool-hackers: 4471] [PATCH] printing empty row first in query "show pool_process"
Author: Kwangwon Seo
Back patch to V4.2 where the problem started.