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

Doc: Bump version to 4.5.5

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 2b0ba0f30631b6e8604910542b218abb8107b1be.

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

Doc: Bump version to 4.5.4

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 6c7f9ff640432b99fa11726c0db66ea3c7e15c9d.

"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

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

Doc: Bump version to 4.5.3

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.

Doc: Add the criteria for selecting processes to be killed to max_spare_children.

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.

Doc: enhance failover document.

Clarify the condition on failover when failover_on_backend_shutdown is
enabled.

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 dynamic process management.

Calculation of pooled_connection, which is used by the process
eviction algorithm, was not correct. The number always resulted in
max_pool. Also more comments are added.

Discussion:  [pgpool-hackers: 4490] Issue with dynamic process management
https://www.pgpool.net/pipermail/pgpool-hackers/2024-July/004491.html
Backpatch-through: master, 4.5, 4.4

Fixed segmentation fault at parsing config file.

This commit fixed a segmentation fault that occurs when parsing pgpool.conf
if the setting value was not enclosed in single quotes.

The patch is created by Carlos Chapi, reviewed and modified by Tatsuo Ishii.

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.

Fix segfault in a child process.

It is reported that pgpool child segfaulted [1].

[snip]

In the down thread it is reported that despite VALID_BACKEND(i)
returns true, backend->slots[i] is NULL, which should have been filled
by new_connection().

It seems there's a race condition. In new_connection(), there's a code
fragment:
/*
 * Make sure that the global backend status in the shared memory
 * agrees the local status checked by VALID_BACKEND. It is possible
 * that the local status is up, while the global status has been
 * changed to down by failover.
 */
A--> if (BACKEND_INFO(i).backend_status != CON_UP &&
BACKEND_INFO(i).backend_status != CON_CONNECT_WAIT)
{
ereport(DEBUG1,
(errmsg("creating new connection to backend"),
 errdetail("skipping backend slot %d because global backend_status = %d",
   i, BACKEND_INFO(i).backend_status)));

/* sync local status with global status */
B--> *(my_backend_status[i]) = BACKEND_INFO(i).backend_status;
continue;
}

It is possible that at A backend_status in the shared memory is down
but by the time it reaches B the status has been changed to up. And
new_connection() skipped to create a backend connection. This seems to
explain why the connection slot is NULL while VALID_BACKEND returns
true. To prevent the race condtion, backend_status in shared memory is
copied to a local variable and evaluate it.  Also the VALID_BACKEND
just before:

pool_set_db_node_id(CONNECTION(backend, i), i);

is changed to:
if (VALID_BACKEND(i) && CONNECTION_SLOT(backend, i))

so that it prevents crash just in case.

[1] [pgpool-general: 9104] Another segmentation fault

Fix: 823: Watchdog dies and kills pgpool2 when network gets shortly interrupted.

With network monitoring enabled, a Pgpool node would shut down immediately if it
lost all network interfaces or assigned IP addresses, providing extra protection
by quickly removing a non-communicative node from the cluster.

The issue was that Pgpool responded to network blackout events even when network
monitoring was disabled. This fix ensures that the network monitoring socket is
not opened when network monitoring is not enabled, preventing unnecessary shutdowns.

Fix "pgpool reset" command not working if watchdog is enabled.

[pgpool-hackers: 4465] abnormal behavior about PGPOOL RESET. and proposal a patch file.
reported that "pgpool reset" command fails if watchdog is enabled.

test=# PGPOOL RESET client_idle_limit;
SET
ERROR: Pgpool node id file �y/pgpool_node_id does not exist
DETAIL: If watchdog is enable, pgpool_node_id file is required
message type 0x5a arrived from server while idle
message type 0x43 arrived from server while idle
message type 0x5a arrived from server while idle

SetPgpoolNodeId() tried to obtain the path to the node id file by
using global variable config_file_dir and failed because it points to
an automatic variable in ParseConfigFile().

To fix this, change the config_file_dir from a pointer to an array and
save the path string into config_file_dir in ParseConfigFile().

Also regression test is added to 004.watchdog.

Bug reported and problem analysis by keiseo.

Back patch to V4.2 in which the node id file was introduced.

Mega typo fix for docs and program source codes.

Author: Umar Hayat

Fix psql_scan crash.

It was reported that psql_scan crashes while determining whether a
string in a long query is psql variable (i.e. starting with ":") or
not.

https://github.com/pgpool/pgpool2/issues/54

This is because callback struct were not provided while calling
psql_scan_create().  Later psql_scan() tries to invoke a callback and
crashes because the pointer to the callback struct is NULL. To fix
this, provide PsqlScanCallbacks struct with a NULL pointer inside to
the callback function. With this, psql_scan() avoids to invoke a
callback.

Backpatch to master, V4.5, V4.4, V4.3, V4.2 and V4.1 where psql_scan
was introduced.

Delete unnecessary if branch.

https://github.com/pgpool/pgpool2/issues/52

Doc: update Copyright.

Update pgpool.spec changelog.

Prepare 4.5.2

Doc: Bump version to 4.5.2

Doc: add release notes.

Doc: fix documentation typos.

Fixed compiler error with -Werror=implicit-function-declaration

- Add missing header files in autoconf check and
- Add LDAP_DEPRECATED to include prototypes for deprecated ldap functions

Patch is created by Vladimir Petko.

Fix pgpool.spec.

The permission of /etc/sudoers.d/pgpool should be mode 0440.

Fix segfault in pgpool main process.

This is a follow up commit for 0564864e "Fix assorted causes of
segmentation fault.". It lacked the fix while verify_backend_node calls
get_server_version, i.e. checking availability of slots.

Patch provided by: Emond Papegaaij
Backpatch-through: v4.4
Discussion:
[pgpool-general: 9072] Re: Segmentation after switchover
https://www.pgpool.net/pipermail/pgpool-general/2024-April/009133.html

Fix assorted causes of segmentation fault.

It is reported that pgpool and its child process segfault in certain
cases when failover involved.

In pgpool main get_query_result (called from find_primary_node) crashed.

do_query(slots[backend_id]->con, query, res, PROTO_MAJOR_V3);

It seems slots[0] is NULL here. slots[0] is created by
make_persistent_db_connection_noerror() but it failed with log
message: "find_primary_node: make_persistent_db_connection_noerror
failed on node 0". Note that at the time when
make_persistent_db_connection_noerror() is called, VALID_BACKEND
reported that node 0 is up. This means that failover is ongoing and
the node status used by VALID_BACKEND did not catch up. As a result
get_query_user is called with slots[0] = NULL, which caused the
segfault. Fix is, check slots entry before calling
get_query_result.

Also health check has an issue with connection "slot" memory. It is
managed by HealthCheckMemoryContext. slot is the pointer to the
memory. When elog(ERROR) is raised, pgpool long jumps and resets the
memory context. Thus, slot remains as a pointer to freed memory. To
fix this, always set NULL to slot right after the
HealthCheckMemoryContext call.

Similar issue is found with streaming replication check too and is
also fixed in this commit.

Problem reported and analyzed: Emond Papegaaij
Backpatch-through: v4.4
Discussion:
[pgpool-general: 9070] Re: Segmentation after switchover
https://www.pgpool.net/pipermail/pgpool-general/2024-April/009131.html

Test: fix 037.failover_session.

The test script forgot to execute shutdownall before exiting.

Fix uninitialized memory error.

It was reported that valgrind found several errors including an
uninitialized memory error in read_startup_packet. It allocates memory
for user name in a startup packet in case cancel or SSL request using
palloc, and later on the memory is used by pstrdup. Since memory
allocated by palloc is undefined, this should have been palloc0.

Bug reported by: Emond Papegaaij
Backpatch-through: v4.1
Discussion:
[pgpool-general: 9065] Re: Segmentation after switchover
https://www.pgpool.net/pipermail/pgpool-general/2024-April/009126.html

Doc: enhance "Upstream server connection" documentation.

Fix errors/hung up when load_balance_mode is off.

Commit: 3f3c1656 Fix statement_level_load_balance with BEGIN etc.

brought errors/hung up when load_balance_mode is off, primary node id
is not 0 and queries are BEGIN etc.

pool_setall_node_to_be_sent() checked if the node is primary. If not,
just returned with empty where_to_send map which makes
set_vrtual_main_node() not to set
query_context->virtual_main_node_id. As a result, MAIN_NODE macro
(it's actually pool_virtual_main_db_node_id()) returns
REAL_MAIN_NODE_ID, which is 0 if node 0 is alive (this should have
been primary node id).

Following simple test reveals the bug.

(1) create a two-node cluster using pgpool_setup

(2) shutdown node 0 and recover node 1 (pcp_recovery_node 0). This
makes node 0 to be standby, node 1 to be primary.

(3) add followings to pgpool.conf and restart whole cluster.

load_balance_mode = off
backend_weight1 = 0

(4) type "begin" from psql. It gets stuck.

Bug found and analyzed by Emond Papegaaij.
Discussion: https://www.pgpool.net/pipermail/pgpool-general/2024-March/009113.html
Backpatch-through: v4.1

Doc: language cleanup in Japanese document

Replace "マスター" with "プライマリ"

Doc: add the note about using pcp_promote_node when two postgres

Even if there are two postgres, there are cases that
follow_primary_command is required to be set.

Fix compile errors with certain CFLAGS.

https://github.com/pgpool/pgpool2/issues/42 reported that with CFLAGS
-flto=4 -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing
gcc emits errors. Some of them are mistakes when their sources were
brought in from PostgreSQL.  This commit fixes them. Note that I was
not able to suppress some errors at least with my gcc (9.4.0). This
may be because gcc bug (false positives) or just a bug with the old
gcc, I don't know at this point. Maybe someday revisit this.

Discussion:
[pgpool-hackers: 4442] Fixing GitHub issue 42
https://www.pgpool.net/pipermail/pgpool-hackers/2024-March/004443.html

../src/include/query_cache/pool_memqcache.h:251:20: warning: type of 'pool_fetch_from_memory_cache' does not match original declaration [-Wlto-type-mismatch]
  251 | extern POOL_STATUS pool_fetch_from_memory_cache(POOL_CONNECTION * frontend,
      |                    ^
query_cache/pool_memqcache.c:731:1: note: 'pool_fetch_from_memory_cache' was previously declared here
  731 | pool_fetch_from_memory_cache(POOL_CONNECTION * frontend,
      | ^
query_cache/pool_memqcache.c:731:1: note: code may be misoptimized unless '-fno-strict-aliasing' is used
../src/include/utils/palloc.h:64:22: warning: type of 'CurrentMemoryContext' does not match original declaration [-Wlto-type-mismatch]
   64 | extern MemoryContext CurrentMemoryContext;
      |                      ^
../../src/utils/mmgr/mcxt.c:40:15: note: 'CurrentMemoryContext' was previously declared here
../../src/utils/mmgr/mcxt.c:40:15: note: code may be misoptimized unless '-fno-strict-aliasing' is used
../src/include/utils/memutils.h:55:22: warning: type of 'TopMemoryContext' does not match original declaration [-Wlto-type-mismatch]
   55 | extern MemoryContext TopMemoryContext;
      |                      ^
../../src/utils/mmgr/mcxt.c:46:15: note: 'TopMemoryContext' was previously declared here
../../src/utils/mmgr/mcxt.c:46:15: note: code may be misoptimized unless '-fno-strict-aliasing' is used
../src/include/pool_config.h:646:22: warning: type of 'pool_config' does not match original declaration [-Wlto-type-mismatch]
  646 | extern POOL_CONFIG * pool_config;
      |                      ^
config/pool_config.l:46:14: note: 'pool_config' was previously declared here
   46 | POOL_CONFIG *pool_config = &g_pool_config; /* for legacy reason pointer to the above struct */
      |              ^
config/pool_config.l:46:14: note: code may be misoptimized unless '-fno-strict-aliasing' is used

Fixed comments in sample pgpool.conf.

- The comment for sr_check_period. The default value should be 10 seconds.
- Also fixed some typos in comments.

Patch is created by hiroin and modified by Bo Peng.

Remove a file under config directory.

Remove Makefile.in etc. generated by autoconf.
Create .gitignore under src/config and add generated files by bison and flex.

Allow reset queries to run even if extended queries do not end.

Commit 240c668d "Guard against inappropriate protocol data." caused
reset queries fail if extended query messages do not end. This commit
fix that by checking whether we are running reset queries in
SimpleQuery(). Also add the test case for this.

Fix a compiler warning

Fix warning introduced in the previous commit.

Fix memory leak pointed out by Coverity.

Guard against inappropriate protocol data.

If a simple query message arrives before a sequence of extended query
messages ends (that is, no sync message arrives or some ready for
query messages corresponding the sync message do not arrive yet),
pgpool could hang.  This is because the query context in the session
context for the simple query is overwritten by the query contexts of
the extended query messages.

This commit implements a guard in SimpleQuery() by checking whether
extended query protocol messages ended. If they do not end, raise a
FATAL error. A known example detected by this checking is JDBC
driver's "autosave=always" option. This means pgpool will not accept
the option after this commit until the issue (sending a simple
protocol message before ending extended query message protocol) is
fixed by the JDBC driver side.

Discussion:
[pgpool-hackers: 4427] Guard against ill mannered frontend
https://www.pgpool.net/pipermail/pgpool-hackers/2024-February/004428.html

Test: fix test failure introduced in the previous commit.

Test: fixed regression test 005.jdbc to avoid Java 21 deprecation warnings.

Replace Runtime.exec(String) with Runtime.exec(String[]) to avoid Java 21 deprecation warnings.
Patch is created by Vladimir Petko and modified by Bo Peng.

Doc: update copy right.

Prepare 4.5.1

Doc: update document version.

Doc: add release notes.

Remove restore_command from sample scripts.

Restore_command is not required because replication slot is enabled.
It causes occasional failover failure.

Fix the default values.

Fixed the default values of the following parameters:
- recovery_user
- failover_on_backend_shutdown
- insert_lock

Doc: fix Japanese watchdog document.

It mistakenly used "master" watchdog node instead of "leader".

Doc: fix English watchdog document.

It mistakenly used "main" PostgreSQL node instead of "primary".

Fix to use forward declation of a variable.

It is required by our coding standard (we follow PostgreSQL's coding
standard). Also fix small typo.

Fix statement_level_load_balance with BEGIN etc.

When statement_level_load_balance is enabled,
BEGIN/END/COMMIT/ABORT/SET/SAVEPOINT/RELEASE SAVEPOINT/DEALLOCATE
ALL/DISCARD were sent to primary node and all standby nodes even if
load_balance_mode is off. This is not only plain wrong but caused slow
down if one of the standby nodes are in remote network. Fix this in
that pgpool sends such queries to primary node only when
load_balance_mode is off.

Note that if load_balance_mode is on and statement_level_load_balance
is on, such queries are sent to all nodes as before. This is
necessary. For example, suppose there are 2 PostgreSQL nodes 0 and
1. An explicit transaction starts followed by two read only
SELECTs. The first SELECT is sent to node 0 because the node 0 is
chosen as the load balance node. The second SELECT is sent to node 1
because the node 1 is chosen as the load balance node. If pgpool has
not sent BEGIN to both node 0 and 1 when the transaction started, the
first or the second SELECT will be executed outside the transaction,
which is not an expected behavior. However this may bring slow down
mentioned above. I guess this has been less known to users and I
decided to add some notes to the statement_level_load_balance doc.

Reported: [pgpool-general: 8998] https://www.pgpool.net/pipermail/pgpool-general/2024-January/009059.html
Discussion: [pgpool-hackers: 4422] https://www.pgpool.net/pipermail/pgpool-hackers/2024-February/004423.html
Backpatch-through: v4.1

Test: now it will be displayed in the log if segfault occurs.

Test: enhance 037.failover_session/test.sh.

Previously it mistakenly executed pg_ctl stop after starting pgbench
in background.  The smart shutdown always allows pgbench to run
successfully with pgbench -C option not being set because backend
does not shutdown while client session continues. In order to shutdown
backend in the middle of pgbench run, tweak health check parameters so
that it detects the backend down as soon as possible. This will
trigger failover in the middle of pgbench run.

With these changes Pgpool-II 4.5 and beyond succeeds in all 4 tests,
while pre-4.5 will fail in all 4 tests (that was the originally
expected result).

Also allow to run all the 4 tests even if some tests fail so that we
can check which of which test failed.

Doc: fix delay_threshold_by_time document mistake.

Millisecond is correct.

Prepare 4.5.0