| Age | Commit message (Collapse) | Author |
|---|
|
Per Coverity.
Backpatch-through: v4.2
|
|
By an oversight, the commit could bring a double pfree situation.
|
|
Fix indentation by running pgindent.
|
|
Per Coverity.
|
|
Fix resource leak in pool_push_pending_data pointed out by Coverity.
Backpatch-through: v4.2
|
|
|
|
Starting from PostgreSQL 18, frontend/backend protocol has been
changed to 3.2. In the changes the BackendKeyData and query cancel
message are modified to allow variable length cancel key.
This commit implements the changes and now we can connect to
PostgreSQL frontend and backend using 3.2 protocol.
Example session is:
PGMAXPROTOCOLVERSION="3.2" psql -p 11000 test
Author: Tatsuo Ishii <ishii@postgresql.org>
Discussion: https://www.postgresql.org/message-id/20250714.155710.1706961744888449986.ishii%40postgresql.org
|
|
Implementing the message is necessary when frontend requests the
protocol version 3.2 (i.e. PostgreSQL 18+ or compatible clients),
while backend still only supports 3.0 (i.e. backend is PostgreSQL 17
or before).
This commit handles the message so that the message is forwarded from
backend to frontend when there's no connection cache exists.
If connection cache exists, pgpool sends the message, which has been
saved at the time when the connection cache was created, to frontend.
Note that the frontend/backend protocol 3.2 changes the BackendKeyData
message format, but it's not implemented in this commit yet. This
means that still pgpool cannot handle 3.2 protocol.
Discussion: https://www.postgresql.org/message-id/20250708.112133.1324153277751075866.ishii%40postgresql.org
|
|
This commit adds new pgpool_adm extension function:
pcp_proc_info. Also add new fields: client_host, client_port and SQL
statement to pcp_proc_info and "show pool_pools". With these additions
now it is possible to track the relationship among clients of pgpool,
pgpool itself and PostgreSQL.
Moreover the commit allows to know what commands (statements) are last
executed by using pcp_proc_info. Previously it was not possible unless
looking into the pgpool log.
lipcp.so version is bumped from 2.0 to 2.1.
|
|
In certain environment (especially k8s), DNS look up is unstable and
connecting to backend process fails. This occurs in call to
getaddrinfo() in connect_inet_domain_socket_by_port(). To enhance the
situation, retry up to 5 times (at each retry, sleep 1 second) if
getaddrinfo() fails with EAI_AGAIN. Note that if
connect_inet_domain_socket_by_port() is called with "retry" argument
is false, the retry will not happen. Health check calls
connect_inet_domain_socket_by_port() with the retry flag to false so
that retrying is controlled health check's own parameters.
Since up to now there's no similar issue reported, back patch to only
4.6 to make backpatching minimal.
Discussion: https://github.com/pgpool/pgpool2/issues/104
Backpatch-through: v4.6
|
|
Previously we used random() for choosing load balancing node. However
PostgreSQL has better random number generator: pg_prng.c. This commit
imports the file and use pg_prng_double() to generate random number in
range [0.0, 1.0). The seed is generated using pg_strong_random().
Other notes regarding the port:
- Some of functions in the file were not ported because they require
additional library: pg_bitutils.c. In the future we may revisit and
import pg_bitutils.c.
- All conditional compiling regarding "sun" or "_sun" are removed. It
seems the platform is not used for running pgpool anymore.
- Since srandom() is not necessary any more, related code are removed
from pgpool_main.c, child.c and pcp_worker.c.
Author: Martijn van Duren <pgpool@list.imperialat.at>, Tatsuo Ishii <ishii@postgresql.org>
Discussion: [pgpool-hackers: 4588] Shuffle random functions and use better random numbers
https://www.pgpool.net/pipermail/pgpool-hackers/2025-May/004589.html
|
|
This reverts commit 66fcd561d74c8f00326bad94300053bd7ea13566.
It was accidentally committed.
|
|
Previously we used random() for choosing load balancing node. However
PostgreSQL has better random number generator: pg_prng.c. This commit
imports the file and use pg_prng_double() to generate random number in
range [0.0, 1.0).
Other notes regarding the port:
- pg_prng needs to be initialized using pg_prng_strong_seed() per
process. Currently the only caller is child.c (per session
process). If other process needs to use pg_prng, it needs the same
initialization as child.c.
- Some of functions in the file were not ported because they require
additional library: pg_bitutils.c. In the future we may revisit and
import pg_bitutils.c.
- likely/unlikely are ignored. In the future we may revisit import
them.
- All conditional compiling regarding "sun" or "_sun" are removed. It
seems the platform is not used for running pgpool anymore.
- Since srandom() is not necessary any more, related code are removed
from pgpool_main.c, child.c and pcp_worker.c.
Discussion: [pgpool-hackers: 4588] Shuffle random functions and use better random numbers
https://www.pgpool.net/pipermail/pgpool-hackers/2025-May/004589.html
|
|
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
|
|
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
|
|
Patch is created by Umar Hayat.
|
|
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
|
|
When enabled, log protocol messages from each backend. Possible
options are "none", "terse" and "verbose". "none" disables the feature
and is the default. "verbose" prints the log each time pgpool receives
a message from backend. "terse" is similar to verbose except it does
not print logs for repeated message to save log lines. If different
kind of message received, pgpool prints a log message including the
number of the message. One downside of "terse" is, the repeated
message will not be printed if the pgpool child process is killed
before different kind of message arrives.
For testing, 039.log_backend_messages is added.
Discussion: [pgpool-hackers: 4535] New feature: log_backend_messages
https://www.pgpool.net/pipermail/pgpool-hackers/2024-November/004536.html
|
|
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
|
|
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
|
|
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
|
|
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
|
|
This reverts commit 25ad9e6d50343e2cbd4dc337803d231c92141021.
Per discussion: [pgpool-general: 9265] Re: Segmentation fault during shutdown
https://www.pgpool.net/pipermail/pgpool-general/2024-November/001942.html
|
|
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
|
|
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
|
|
The new PGPOOl SET command allows to delete query cache by specifying
the previous query used to create the query cache entry. example usage
is:
PGPOOL SET CACHE DELETE 'SELECT * FROM t1;'
This command is particularly useful for queries that are not
invalidated by the auto cache invalidation feature because the query
does not have any reference to tables.
|
|
Previously it was not possible to invalidate query cache without
restarting pgpool. This commit adds new PCP command
"pcp_invalidate_query_cache" to invalidate query cache without
restarting pgpool. Note this command only places a query cache
invalidate request on shared the shared memory. The actual
invalidation is performed by pgpool child process.
The reasons for the PCP process cannot remove cache directly are:
1) the connection handle to memcached server is not managed by PCP
process.
2) removing shared memory query cache needs an interlock using
pool_shmem_ock() which may not work well on PCP process. Also a
function used here (pool_clear_memory_cache()) uses PG_TRY, which is
only usable in pgpool child process.
If pgpool child process finds such a request, the process invalidates
all query cache on the shared memory. If the query cache storage is
memcached, then pgpool issues memcached_flush() so that all query
cache on memcached are flushed immediately.
Note that the timing for pgpool child process to check the
invalidation request is after processing current query or response
from backend. This means that if all pgpool child process sit idle,
the request will not be processed until any of them receives a
messages from either frontend or backend.
Another note is, about query cache statistics shown by "show
pool_cache" command. Since the cache invalidation does not clear the
statistics, some of them (num_cache_hits and num_selects) continue to
increase even after the cache invalidation. Initializing the
statistics at the same could be possible but I am not sure if all
users want to do it.
Discussion:https://www.pgpool.net/pipermail/pgpool-hackers/2024-October/004525.html
|
|
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 "insecure data handling".
Per Coverity (CID 1559731)
|
|
insert_lock() forgot to send row lock command (lock_kind == 3 case) to
other than main node.
|
|
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
|
|
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
|
|
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.
|
|
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.
|
|
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 surrounded by "#ifdef NOT_USED".
|
|
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.
|
|
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
|
|
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
|
|
When pending messages are created, Pgpool-II did like:
(1) pmsg = pool_pending_message_create(); /* create a pending message */
(2) pool_pending_message_dest_set(pmsg, query_context) /* set PostgreSQL node ids to be sent */
(3) pool_pending_message_query_set(pmsg, query_context); /* add query context */
(4) pool_pending_message_add(pmsg); /* add the pending message to the list */
(5) pool_pending_message_free_pending_message(pmsg); /* free memory allocated by pool_pending_message_create();
The reason why pool_pending_message_free_pending_message(pmsg) is
called here is, pool_pending_message_add() creates a copy of the
pending message then add it to the list. This commit modifies
pool_pending_message_add() so that it does not create a copy of the
object and adds it to the pending messages list. This way, we can
eliminate (5) as well and it should reduce memory footprint and CPU
cycle.
|
|
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
|
|
Author: Umar Hayat
|
|
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.
|
|
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
|
|
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.
|
|
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
|
|
This reverts commit c5b25883d21a180ec54a2fea9de67d5da1367464.
This commit accidentally included other updates.
|
|
It was possible that enabling detach_false_primary caused that all
backend node went down.
Suppose watchdog is enabled and there are 3 watchdog nodes pgpool0,
pgpool1 and pgpool2. If pgpool0 and pgpool1 find primary PostgreSQL
goes down due to network trouble between pgpool and PostgreSQL, they
promote a standby node. pgpool2 could find that there are two primary
nodes because the backend status at pgpool2 has not been synced with
pgpool0 and pgpool1, and pgpool2 perform detach_false_primary against
the standby, which is being promoted.
To prevent the situation, now detach_false_primary is performed by only
watchdog leader node. With this, pgpool will not see half baked backend
status and the issue described above will not happen.
Discussion: https://www.pgpool.net/pipermail/pgpool-hackers/2024-February/004432.html
([pgpool-hackers: 4431] detach_false_primary could make all nodes go down)
|
|
The following ERROR messages are downgraded to DEBUG messages.
(1) ERROR:unable to flush data to frontend
(2) ERROR: unable to read data from frontend
DETAIL: EOF encountered with frontend
(3) ERROR: unable to read data
DETAIL: child connection forced to terminate due to client_idle_limit:30 is reached
(1) and (2)
These messages are cuased when the client did not send a terminate message
before disconnecting to pgpool.
For example, when the client process was forcefully terminated, the error occurs.
Although they are harmless, it can sometimes confuse users.
(3)
If we set "client_idle_limit" to a non-zero value, the connection
will be disconnected if it remains idle since the last query.
The disconnection is caused by Pgpool-II settings,
but Pgpool-II handles the log message as an "ERROR".
Because the ERROR messages above are normal messages, I decide to downgrade them.
Discussion: https://www.pgpool.net/pipermail/pgpool-hackers/2023-June/004351.html
|
|
Debug message was accidentally left.
|
