| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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
|
|
Also clarify a debug message. Previous it stated that the reason for
the function returns WD_NG was that pgpool has not send hearbeat
yet. Actually the reason could be that pgpool has not received
hearbeat yet too.
|
|
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
|
|
|
|
Commit fd190f7ea imported pgindent but the method explained in
README.pgpool was wrong. typedefs.list can be generated by using
PostgreSQL's find_typedef. So import find_typedef and remove
unnecessary files. Proper way to run pgindent is explained in
README.pgpool.
|
|
Prior to version 4.6, the online recovery database was hardcoded to "template1".
This commit introduces a new configuration parameter, "recovery_database",
which allows users to specify the database used for online recovery.
The default value is "postgres".
|
|
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
|
|
When pcp_proc_info was invoked without "-v" option, pcp_proc_info did
not print the "statement" field. This was due to oversight in the
frontend side of the command: forgot to add one more format siring
"%s".
This bug was in only master branch: when some new fields were added to
pcp_proc_info.
Reported-by: Bo Peng <pengbo@sraoss.co.jp>
Author: Tatsuo Ishii <ishii@postgresql.org>
|
|
Fix documentations for 6 parameters.
Japanese docs too.
"log_standby_delay"
"log_backend_messages"
"wd_lifecheck_method"
"memqcache_method"
"disable_load_balance_on_write"
"backend_clustering_mode"
|
|
"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.
|
|
Import PostgreSQL's pgindent.
This commit not only imports PostgreSQL's pgindent, but generates the
important file: typedefs.list. For this purpose followings are added:
- README.pgpool: How to generate typedefs.list.
- doxygen.list: Pgpool-II's typedefs extracted by doxygen. Plus
manually added typedefs that were not detected by doxygen.
- enums.list: Pgpool-II's enums manually extracted from source code.
- exclude_files: files that should not be touched pgindent.
- run_pgindent: handy script to run pgindent. Should be run at src
directory.
- typedefs.list.PostgreSQL: PostgreSQL's typedefs. To prepare for that
doxygen misses some typedefs.
- make_typedefs.list: handy script to generate typedefs.list.
|
|
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
|
|
Commit 04e09df17 was not enough fix. The test calls pcp_proc_info()
pgpool_adm function along with user name and password (in the test
password is the same string as user name). Problem is, the user name
is obtained from a user name that runs the test, and we use psql -a to
submit the SQL, which prints the user name. Of course the user name
can vary depending on the environment, and it makes the test fail. To
fix the issue, run psql without -a option.
|
|
The result of the test showed local host IP. Although the IP can be
either IPv4 or IPv6, the test script hadn't considered it. To fix
this, now test.sh converts IPv4 and IPv6 IP to "localhost".
|
|
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.
|
|
|
|
Previously when wd_lifecheck_method = 'query', life checking prints
SQL without application name if "%a" is specified in
log_line_prefix. This commit add application_name "lifecheck_ping" to
make the log looks better. Since this changes user visible behavior,
I do not apply this to stable branches.
Discussion: [pgpool-hackers: 4603] life check log is not nice
https://www.pgpool.net/pipermail/pgpool-hackers/2025-June/004604.html
|
|
wd_create_hb_recv_socket() and wd_create_hb_send_socket() called
setsockopt(2) with wrong argument.
struct ifreq i;
strlcpy(i.ifr_name, hb_if->if_name, sizeof(i.ifr_name));
if (setsockopt(sock, SOL_SOCKET, SO_BINDTODEVICE, &i, sizeof(i)) == -1)
:
This is not quite correct since the 4th argument should be
just a null terminated string (device name), not struct ifreq.
Discussion: [pgpool-hackers: 4602] heartbeat and SO_BINDTODEVICE
https://www.pgpool.net/pipermail/pgpool-hackers/2025-May/004603.html
Backpatch-through: v4.6
|
|
Pointed out by Coverity.
Backpatch-through: v4.6
|
|
- Log regarding total shared memory allocation size was redundant.
- Other logs were too verbose and downgraded to DEBUG1.
|
|
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
|
|
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
|
|
When ssl_passphrase_command is not valid, the error message is
typically "bad decrypt" but it seems sometimes "wrong tag".
|
|
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
|
|
65dbbe7a0 added IPv6 support for heartbeat in 4.6. However it
mistakenly bound to only loopback addresses in heartbeat receive
process. Thus heartbeat messages from other watchdog heartbeat sender
were never received. To fix this add AI_PASSIVE flag to hints argument
to getaddrinfo(), which results in binding all network
interfaces. Note that before 4.6, heartbeat receive process uses
INADDR_ANY for bind(), which resulted in binding all network
interfaces too. So there's no big difference between 4.6 and pre-4.6.
Reviewed-by: Bo Peng <pengbo@sraoss.co.jp>
Backpatch-through: v4.6
|
|
This is a follow up commit to:
cea80281d Retry bind on watchdog receive socket.
Use getnameinfo() so that log messages contain hostname, rather just
"TCP".
|
|
Occasionally 028.watchdog_enable_consensus_with_half_votes times out
due to failure on binding watchdog receive socket. This commit tries
to mitigate the issue by retrying bind. Currently the retry is
performed up to 5 times and each retry is with 1 second sleep.
|
|
Backpatch-through: v4.3
|
|
These macros are not only useful to enhance performance (if correctly
used) but make porting codes from PostgreSQL to pgpool easier since
the macros occasionally used in the code.
Discussion: [pgpool-hackers: 4599] Porting likely/unlikely
https://www.pgpool.net/pipermail/pgpool-hackers/2025-May/004600.html
|
|
This reverts commit 66fcd561d74c8f00326bad94300053bd7ea13566.
It was accidentally committed.
|
|
When IPv6 network is not available, it was possible that watchdog
process won't start. Previously wd_create_recv_socket() issued
elog(ERROR) if creation or handling IPv6 socket failed. Unfortunately
at the time when wd_create_recv_socket() is called, the exception
stack is not established, and elog happily converts ERROR to FATAL,
which causes exiting watchdog process, thus exiting pgpool process.
To fix this, the elog(ERROR) calls are changed to elog(LOG).
Reported-by: Bo Peng (pengbo@sraoss.co.jp)
Discussion: https://github.com/pgpool/pgpool2/issues/99
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).
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
|
|
In the commit I forgot to test without SSL case, which requires to
include <errno.h>.
Author: Bo Peng <pengbo@sraoss.co.jp>
|
|
Our PostmasterRandmon() was imported from PostgreSQL long time ago (in
2016). In the same year PostgreSQL replaced PostmasterRandmon() with
pg_strong_random()(src/port/pg_strong_random.c). This commit follows
it.
pg_strong_random() looks better than PostmasterRandmon(), since it's
more secure and portable. Moreover no initialization is necessary.
Reviewed-by: Martijn van Duren <pgpool@list.imperialat.at>
Discussion: [pgpool-hackers: 4588] Shuffle random functions and use better random numbers
https://www.pgpool.net/pipermail/pgpool-hackers/2025-May/004589.html
|
|
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
|
|
We have already allowed pcp server to connect to IPv6 addresses, but
pcp clients were not allowed to connect to them until today. This
commit allows pcp clients to connect to IPv6 addresses.
Discussion: [pgpool-general: 9481] Does pgpool 4.6.0 support pure ipv6 configuration?
https://www.pgpool.net/pipermail/pgpool-general/2025-May/009484.html
Backpatch-through: v4.6
|
|
|
|
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.
|
|
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
|
|
If reading password from .pcppass file fails, it should fall back to prompting the user for input,
similar to how PostgreSQL handles .pgpass.
This commit also changes the following messages to be displayed without requiring the -d option:
WARNING: password file \"%s\" is not a plain file
WARNING: password file \"%s\" has group or world access; permissions should be u=rw (0600) or less
Discussion: [pgpool-hackers: 4589] If reading password from .pcppass file fails, try to read it from prompt.
https://www.pgpool.net/pipermail/pgpool-hackers/2025-May/004590.html
|
|
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
|
|
- 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
|
|
|
|
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.
|
|
From Pgpool-II 4.6.0, heartbeat process can handle IPv6 receiver
sockets. However, the process does not work normally if IPv6 is
disabled in the system. Like Pgpool-II main process and PostgreSQL, I
think it should work normally if IPv4 is available.
Discussion: https://www.pgpool.net/pipermail/pgpool-hackers/2025-April/004579.html
Backpatch-through: 4.6
|
