[pgpool-hackers: 1639] pgpool-II 3.5.3, 3.4.7, 3.3.11, 3.2.16, 3.1.19 and pgpoolAdmin 3.5.3 released
Bo Peng
pengbo at sraoss.co.jp
Fri Jun 17 21:03:10 JST 2016
Hi,
Pgpool Global Development Group is pleased to announce the availability
of pgpool-II 3.5.3, 3.4.7, 3.3.11, 3.2.16, 3.1.19, and pgpoolAdmin 3.5.3.
These are the latest stable minor versions of each major versions of pgpool-II.
You can download them from:
http://pgpool.net/mediawiki/index.php/Downloads
3.5.3 (ekieboshi) 2016/06/17
* Version 3.5.3
This is a bugfix release against pgpool-II 3.5.2.
__________________________________________________________________
* New features
- Allow to access to pgpool while doing health checking (Tatsuo Ishii)
Currently any attempt to connect to pgpool fails if pgpool is doing
health check against failed node even if fail_over_on_backend_error is
off because pgpool child first tries to connect to all backend
including the failed one and exits if it fails to connect to a backend
(of course it fails). This is a temporary situation and will be
resolved before pgpool executes failover. However if the health check
is retrying, the temporary situation keeps longer depending on the
setting of health_check_max_retries and health_check_retry_delay. This
is not good. Attached patch tries to mitigate the problem:
- When an attempt to connect to backend fails, give up connecting to
the failed node and skip to other node, rather than exiting the
process if operating in streaming replication mode and the node is
not primary node.
- Mark the local status of the failed node to "down".
- This will let the primary node be selected as a load balance node
and every queries will be sent to the primary node. If there's other
healthy standby nodes, one of them will be chosen as the load
balance node.
- After the session is over, the child process will suicide to not
retain the local status.
Per [pgpool-hackers: 1531].
* Bug fixes
- Fix is_set_transaction_serializable() when
SET default_transaction_isolation TO 'serializable'. (Bo Peng)
SET default_transaction_isolation TO 'serializable' is sent to
not only primary but also to standby server in streaming replication mode,
and this causes an error. Fix is, in streaming replication mode,
SET default_transaction_isolation TO 'serializable' is sent only to the
primary server.
See bug 191 for related info.
- Fix Chinese documetation bug about raw mode (Yugo Nagata, Bo Peng)
Connection pool is avalilable in raw mode.
- Fix confusing comments in pgpool.conf (Tatsuo Ishii)
- Fix extended protocol handling in raw mode (Tatsuo Ishii)
Bug152 reveals that extended protocol handling in raw mode (actually
other than in stream mode) was wrong in Describe() and Close().
Unlike stream mode, they should wait for backend response.
See bug 152 for related info.
- Permit pgpool to support multiple SSL cipher protocols (Muhammad Usama)
Currently TLSv1_method() is used to initialize the SSL context, that puts an
unnecessary limitation to allow only TLSv1 protocol for SSL communication.
While postgreSQL supports other ciphers protocols as well. The commit changes
the above and initializes the SSLSession using the SSLv23_method()
(same is also used by PostgreSQL). Because it can negotiate the use of the
highest mutually supported protocol version and remove the limitation of one
specific protocol version.
- If statement timeout is enabled on backend and do_query() sends a (Tatsuo Ishii)
query to primary node, and all of following user queries are sent to
standby, it is possible that the next command, for example END, could
cause a statement timeout error on the primary, and a kind mismatch
error on pgpool-II is raised.
This fix tries to mitigate the problem by sending sync message instead
of flush message in do_query(), expecting that the sync message reset
the statement timeout timer if we are in an explicit transaction. We
cannot use this technique for implicit transaction case, because the
sync message removes the unnamed portal if there's any.
Plus, pg_stat_statement will no longer show the query issued by
do_query() as "running".
See bug 194 for related info.
- Deal with the case when the primary is not node 0 in streaming replication mode.
(Tatsuo Ishii)
http://www.pgpool.net/mantisbt/view.php?id=194#c837 reported that if
primary is not node 0, then statement timeout could occur even after
bug194-3.3.diff was applied. After some investigation, it appeared
that MASTER macro could return other than primary or load balance
node, which was not supposed to happen, thus do_query() sends queries
to wrong node (this is not clear from the report but I confirmed it in
my investigation).
pool_virtual_master_db_node_id(), which is called in MASTER macro
returns query_context->virtual_master_node_id if query context
exists. This could return wrong node if the variable has not been set
yet. To fix this, the function is modified: if the variable is not
either load balance node or primary node, the primary node id is
returned.
- Fix a posible hang during health checking (Yugo Nagata)
Helath checking was hang when any data wasn't sent
from backend after connect(2) succeeded. To fix this,
pool_check_fd() returns 1 when select(2) exits with
EINTR due to SIGALRM while health checkking is performed.
Reported and patch provided by harukat and some modification
by Yugo.
See bug 204 for related info.
- change the Makefile under this directory src/sql/,that is proposed by (Bo Peng)
[pgpool-hackers: 1611]
- fix for 0000197: pgpool hangs connections to database.. (Muhammad Usama)
The client connection was getting stuck when backend node and remote pgpool-II
node becomes unavailable at the same time. The reason was a missing command
timeout handling in the function that sends the IPC commands to watchdog.
- Fix bug with load balance node id info on shmem (Tatsuo Ishii)
There are few places where the load balance node was mistakenly put on
wrong place. It should be placed on:
ConnectionInfo *con_info[child id, connection pool_id, backend id].load_balancing_node].
In fact it was placed on:
*con_info[child id, connection pool_id, 0].load_balancing_node].
As long as the backend id in question is 0, it is ok. However while
testing pgpool-II 3.6's enhancement regarding failover, if primary
node is 1 (which is the load balance node) and standby is 0, a client
connecting to node 1 is disconnected when failover happens on node
0. This is unexpected and the bug was revealed.
It seems the bug was there since long time ago but it had not found
until today by the reason above.
- Fixing coverity scan reported issues. (Muhammad Usama)
===============================================================================
3.4.7 (tataraboshi) 2016/06/17
* Version 3.4.7
This is a bugfix release against pgpool-II 3.4.6.
__________________________________________________________________
* New features
- Allow to access to pgpool while doing health checking (Tatsuo Ishii)
Currently any attempt to connect to pgpool fails if pgpool is doing
health check against failed node even if fail_over_on_backend_error is
off because pgpool child first tries to connect to all backend
including the failed one and exits if it fails to connect to a backend
(of course it fails). This is a temporary situation and will be
resolved before pgpool executes failover. However if the health check
is retrying, the temporary situation keeps longer depending on the
setting of health_check_max_retries and health_check_retry_delay. This
is not good. Attached patch tries to mitigate the problem:
- When an attempt to connect to backend fails, give up connecting to
the failed node and skip to other node, rather than exiting the
process if operating in streaming replication mode and the node is
not primary node.
- Mark the local status of the failed node to "down".
- This will let the primary node be selected as a load balance node
and every queries will be sent to the primary node. If there's other
healthy standby nodes, one of them will be chosen as the load
balance node.
- After the session is over, the child process will suicide to not
retain the local status.
Per [pgpool-hackers: 1531].
* Bug fixes
- Fix is_set_transaction_serializable() when
SET default_transaction_isolation TO 'serializable'. (Bo Peng)
SET default_transaction_isolation TO 'serializable' is sent to
not only primary but also to standby server in streaming replication mode,
and this causes an error. Fix is, in streaming replication mode,
SET default_transaction_isolation TO 'serializable' is sent only to the
primary server.
See bug 191 for related info.
- Fix Chinese documetation bug about raw mode (Yugo Nagata, Bo Peng)
Connection pool is avalilable in raw mode.
- Fix confusing comments in pgpool.conf (Tatsuo Ishii)
- Permit pgpool to support multiple SSL cipher protocols (Muhammad Usama)
Currently TLSv1_method() is used to initialize the SSL context, that puts an
unnecessary limitation to allow only TLSv1 protocol for SSL communication.
While postgreSQL supports other ciphers protocols as well. The commit changes
the above and initializes the SSLSession using the SSLv23_method()
(same is also used by PostgreSQL). Because it can negotiate the use of the
highest mutually supported protocol version and remove the limitation of one
specific protocol version.
- If statement timeout is enabled on backend and do_query() sends a (Tatsuo Ishii)
query to primary node, and all of following user queries are sent to
standby, it is possible that the next command, for example END, could
cause a statement timeout error on the primary, and a kind mismatch
error on pgpool-II is raised.
This fix tries to mitigate the problem by sending sync message instead
of flush message in do_query(), expecting that the sync message reset
the statement timeout timer if we are in an explicit transaction. We
cannot use this technique for implicit transaction case, because the
sync message removes the unnamed portal if there's any.
Plus, pg_stat_statement will no longer show the query issued by
do_query() as "running".
See bug 194 for related info.
- Fix a posible hang during health checking (Yugo Nagata)
Helath checking was hang when any data wasn't sent
from backend after connect(2) succeeded. To fix this,
pool_check_fd() returns 1 when select(2) exits with
EINTR due to SIGALRM while health checkking is performed.
Reported and patch provided by harukat and some modification
by Yugo.
See bug 204 for related info.
- change the Makefile under this directory src/sql/,that is proposed by (Bo Peng)
[pgpool-hackers: 1611]
- Fix bug with load balance node id info on shmem (Tatsuo Ishii)
There are few places where the load balance node was mistakenly put on
wrong place. It should be placed on:
ConnectionInfo *con_info[child id, connection pool_id, backend id].load_balancing_node].
In fact it was placed on:
*con_info[child id, connection pool_id, 0].load_balancing_node].
As long as the backend id in question is 0, it is ok. However while
testing pgpool-II 3.6's enhancement regarding failover, if primary
node is 1 (which is the load balance node) and standby is 0, a client
connecting to node 1 is disconnected when failover happens on node
0. This is unexpected and the bug was revealed.
It seems the bug was there since long time ago but it had not found
until today by the reason above.
- Deal with the case when the primary is not node 0 in streaming replication mode. (Tatsuo Ishii)
http://www.pgpool.net/mantisbt/view.php?id=194#c837 reported that if
primary is not node 0, then statement timeout could occur even after
bug194-3.3.diff was applied. After some investigation, it appeared
that MASTER macro could return other than primary or load balance
node, which was not supposed to happen, thus do_query() sends queries
to wrong node (this is not clear from the report but I confirmed it in
my investigation).
pool_virtual_master_db_node_id(), which is called in MASTER macro
returns query_context->virtual_master_node_id if query context
exists. This could return wrong node if the variable has not been set
yet. To fix this, the function is modified: if the variable is not
either load balance node or primary node, the primary node id is
returned.
===============================================================================
3.3.11 (tokakiboshi) 2016/06/17
* Version 3.3.11
This is a bugfix release against pgpool-II 3.3.10.
__________________________________________________________________
* New features
- Allow to access to pgpool while doing health checking (Tatsuo Ishii)
Currently any attempt to connect to pgpool fails if pgpool is doing
health check against failed node even if fail_over_on_backend_error is
off because pgpool child first tries to connect to all backend
including the failed one and exits if it fails to connect to a backend
(of course it fails). This is a temporary situation and will be
resolved before pgpool executes failover. However if the health check
is retrying, the temporary situation keeps longer depending on the
setting of health_check_max_retries and health_check_retry_delay. This
is not good. Attached patch tries to mitigate the problem:
- When an attempt to connect to backend fails, give up connecting to
the failed node and skip to other node, rather than exiting the
process if operating in streaming replication mode and the node is
not primary node.
- Mark the local status of the failed node to "down".
- This will let the primary node be selected as a load balance node
and every queries will be sent to the primary node. If there's other
healthy standby nodes, one of them will be chosen as the load
balance node.
- After the session is over, the child process will suicide to not
retain the local status.
Per [pgpool-hackers: 1531].
* Bug fixes
- Fix is_set_transaction_serializable() when
SET default_transaction_isolation TO 'serializable'. (Bo Peng)
SET default_transaction_isolation TO 'serializable' is sent to
not only primary but also to standby server in streaming replication mode,
and this causes an error. Fix is, in streaming replication mode,
SET default_transaction_isolation TO 'serializable' is sent only to the
primary server.
See bug 191 for related info.
- Fix Chinese documetation bug about raw mode (Yugo Nagata, Bo Peng)
Connection pool is avalilable in raw mode.
- Fix confusing comments in pgpool.conf (Tatsuo Ishii)
- Permit pgpool to support multiple SSL cipher protocols (Muhammad Usama)
Currently TLSv1_method() is used to initialize the SSL context, that puts an
unnecessary limitation to allow only TLSv1 protocol for SSL communication.
While postgreSQL supports other ciphers protocols as well. The commit changes
the above and initializes the SSLSession using the SSLv23_method()
(same is also used by PostgreSQL). Because it can negotiate the use of the
highest mutually supported protocol version and remove the limitation of one
specific protocol version.
- If statement timeout is enabled on backend and do_query() sends a (Tatsuo Ishii)
query to primary node, and all of following user queries are sent to
standby, it is possible that the next command, for example END, could
cause a statement timeout error on the primary, and a kind mismatch
error on pgpool-II is raised.
This fix tries to mitigate the problem by sending sync message instead
of flush message in do_query(), expecting that the sync message reset
the statement timeout timer if we are in an explicit transaction. We
cannot use this technique for implicit transaction case, because the
sync message removes the unnamed portal if there's any.
Plus, pg_stat_statement will no longer show the query issued by
do_query() as "running".
See bug 194 for related info.
- Deal with the case when the primary is not node 0 in streaming replication mode. (Tatsuo Ishii)
http://www.pgpool.net/mantisbt/view.php?id=194#c837 reported that if
primary is not node 0, then statement timeout could occur even after
bug194-3.3.diff was applied. After some investigation, it appeared
that MASTER macro could return other than primary or load balance
node, which was not supposed to happen, thus do_query() sends queries
to wrong node (this is not clear from the report but I confirmed it in
my investigation).
pool_virtual_master_db_node_id(), which is called in MASTER macro
returns query_context->virtual_master_node_id if query context
exists. This could return wrong node if the variable has not been set
yet. To fix this, the function is modified: if the variable is not
either load balance node or primary node, the primary node id is
returned.
- change the Makefile under the directory src/sql/, that is proposed (Bo Peng)
by [pgpool-hackers: 1611]
- Fix a posible hang during health checking (Yugo Nagata)
Helath checking was hang when any data wasn't sent
from backend after connect(2) succeeded. To fix this,
pool_check_fd() returns 1 when select(2) exits with
EINTR due to SIGALRM while health checkking is performed.
Reported and patch provided by harukat and some modification
by Yugo. Per bug #204.
backported from 3.4 or later;
https://git.postgresql.org/gitweb/?p=pgpool2.git;a=commitdiff;h=ed9f2900f1b611f5cfd52e8f758c3616861e60c0
- Fix bug with load balance node id info on shmem (Tatsuo Ishii)
There are few places where the load balance node was mistakenly put on
wrong place. It should be placed on: ConnectionInfo *con_info[child
id, connection pool_id, backend id].load_balancing_node]. In fact it
was placed on: *con_info[child id, connection pool_id,
0].load_balancing_node].
As long as the backend id in question is 0, it is ok. However while
testing pgpool-II 3.6's enhancement regarding failover, if primary
node is 1 (which is the load balance node) and standby is 0, a client
connecting to node 1 is disconnected when failover happens on node
0. This is unexpected and the bug was revealed.
It seems the bug was there since long time ago but it had not found
until today by the reason above.
===============================================================================
3.2.16 (namameboshi) 2016/06/17
* Version 3.2.16
This is a bugfix release against pgpool-II 3.2.15.
__________________________________________________________________
* New features
- Allow to access to pgpool while doing health checking (Tatsuo Ishii)
Currently any attempt to connect to pgpool fails if pgpool is doing
health check against failed node even if fail_over_on_backend_error is
off because pgpool child first tries to connect to all backend
including the failed one and exits if it fails to connect to a backend
(of course it fails). This is a temporary situation and will be
resolved before pgpool executes failover. However if the health check
is retrying, the temporary situation keeps longer depending on the
setting of health_check_max_retries and health_check_retry_delay. This
is not good. Attached patch tries to mitigate the problem:
- When an attempt to connect to backend fails, give up connecting to
the failed node and skip to other node, rather than exiting the
process if operating in streaming replication mode and the node is
not primary node.
- Mark the local status of the failed node to "down".
- This will let the primary node be selected as a load balance node
and every queries will be sent to the primary node. If there's other
healthy standby nodes, one of them will be chosen as the load
balance node.
- After the session is over, the child process will suicide to not
retain the local status.
* Bug fixes
- Fix is_set_transaction_serializable() when
SET default_transaction_isolation TO 'serializable'. (Bo Peng)
SET default_transaction_isolation TO 'serializable' is sent to
not only primary but also to standby server in streaming replication mode,
and this causes an error. Fix is, in streaming replication mode,
SET default_transaction_isolation TO 'serializable' is sent only to the
primary server.
See bug 191 for related info.
- Fix Chinese documetation bug about raw mode (Yugo Nagata, Bo Peng)
Connection pool is avalilable in raw mode.
- Fix confusing comments in pgpool.conf (Tatsuo Ishii)
- Permit pgpool to support multiple SSL cipher protocols (Muhammad Usama)
Currently TLSv1_method() is used to initialize the SSL context, that puts an
unnecessary limitation to allow only TLSv1 protocol for SSL communication.
While postgreSQL supports other ciphers protocols as well. The commit changes
the above and initializes the SSLSession using the SSLv23_method()
(same is also used by PostgreSQL). Because it can negotiate the use of the
highest mutually supported protocol version and remove the limitation of one
specific protocol version.
- If statement timeout is enabled on backend and do_query() sends a (Tatsuo Ishii)
query to primary node, and all of following user queries are sent to
standby, it is possible that the next command, for example END, could
cause a statement timeout error on the primary, and a kind mismatch
error on pgpool-II is raised.
This fix tries to mitigate the problem by sending sync message instead
of flush message in do_query(), expecting that the sync message reset
the statement timeout timer if we are in an explicit transaction. We
cannot use this technique for implicit transaction case, because the
sync message removes the unnamed portal if there's any.
Plus, pg_stat_statement will no longer show the query issued by
do_query() as "running".
See bug 194 for related info.
- Deal with the case when the primary is not node 0 in streaming replication mode. (Tatsuo Ishii)
http://www.pgpool.net/mantisbt/view.php?id=194#c837 reported that if
primary is not node 0, then statement timeout could occur even after
bug194-3.3.diff was applied. After some investigation, it appeared
that MASTER macro could return other than primary or load balance
node, which was not supposed to happen, thus do_query() sends queries
to wrong node (this is not clear from the report but I confirmed it in
my investigation).
pool_virtual_master_db_node_id(), which is called in MASTER macro
returns query_context->virtual_master_node_id if query context
exists. This could return wrong node if the variable has not been set
yet. To fix this, the function is modified: if the variable is not
either load balance node or primary node, the primary node id is
returned.
- change the Makefile under the directory src/sql/, that is proposed (Bo Peng)
by [pgpool-hackers: 1611]
- Fix a posible hang during health checking (Yugo Nagata)
Helath checking was hang when any data wasn't sent
from backend after connect(2) succeeded. To fix this,
pool_check_fd() returns 1 when select(2) exits with
EINTR due to SIGALRM while health checkking is performed.
Reported and patch provided by harukat and some modification
by Yugo. Per bug #204.
backported from 3.4 or later;
https://git.postgresql.org/gitweb/?p=pgpool2.git;a=commitdiff;h=ed9f2900f1b611f5cfd52e8f758c3616861e60c0
- Fix bug with load balance node id info on shmem (Tatsuo Ishii)
There are few places where the load balance node was mistakenly put on
wrong place. It should be placed on: ConnectionInfo *con_info[child
id, connection pool_id, backend id].load_balancing_node]. In fact it
was placed on: *con_info[child id, connection pool_id,
0].load_balancing_node].
As long as the backend id in question is 0, it is ok. However while
testing pgpool-II 3.6's enhancement regarding failover, if primary
node is 1 (which is the load balance node) and standby is 0, a client
connecting to node 1 is disconnected when failover happens on node
0. This is unexpected and the bug was revealed.
It seems the bug was there since long time ago but it had not found
until today by the reason above.
===============================================================================
3.1.19 (hatsuiboshi) 2016/06/17
* Version 3.1.19
This is a bugfix release against pgpool-II 3.1.18.
__________________________________________________________________
* Bug fixes
- Fix is_set_transaction_serializable() when
SET default_transaction_isolation TO 'serializable'. (Bo Peng)
SET default_transaction_isolation TO 'serializable' is sent to
not only primary but also to standby server in streaming replication mode,
and this causes an error. Fix is, in streaming replication mode,
SET default_transaction_isolation TO 'serializable' is sent only to the
primary server.
See bug 191 for related info.
- Fix Chinese documetation bug about raw mode (Yugo Nagata, Bo Peng)
Connection pool is avalilable in raw mode.
- Fix confusing comments in pgpool.conf (Tatsuo Ishii)
- Permit pgpool to support multiple SSL cipher protocols (Muhammad Usama)
Currently TLSv1_method() is used to initialize the SSL context, that puts an
unnecessary limitation to allow only TLSv1 protocol for SSL communication.
While postgreSQL supports other ciphers protocols as well. The commit changes
the above and initializes the SSLSession using the SSLv23_method()
(same is also used by PostgreSQL). Because it can negotiate the use of the
highest mutually supported protocol version and remove the limitation of one
specific protocol version.
- If statement timeout is enabled on backend and do_query() sends a (Tatsuo Ishii)
query to primary node, and all of following user queries are sent to
standby, it is possible that the next command, for example END, could
cause a statement timeout error on the primary, and a kind mismatch
error on pgpool-II is raised.
This fix tries to mitigate the problem by sending sync message instead
of flush message in do_query(), expecting that the sync message reset
the statement timeout timer if we are in an explicit transaction. We
cannot use this technique for implicit transaction case, because the
sync message removes the unnamed portal if there's any.
Plus, pg_stat_statement will no longer show the query issued by
do_query() as "running".
See bug 194 for related info.
- Deal with the case when the primary is not node 0 in streaming replication mode. (Tatsuo Ishii)
http://www.pgpool.net/mantisbt/view.php?id=194#c837 reported that if
primary is not node 0, then statement timeout could occur even after
bug194-3.3.diff was applied. After some investigation, it appeared
that MASTER macro could return other than primary or load balance
node, which was not supposed to happen, thus do_query() sends queries
to wrong node (this is not clear from the report but I confirmed it in
my investigation).
pool_virtual_master_db_node_id(), which is called in MASTER macro
returns query_context->virtual_master_node_id if query context
exists. This could return wrong node if the variable has not been set
yet. To fix this, the function is modified: if the variable is not
either load balance node or primary node, the primary node id is
returned.
- change the Makefile under the directory src/sql/, that is proposed (Bo Peng)
by [pgpool-hackers: 1611]
- Fix a posible hang during health checking (Yugo Nagata)
Helath checking was hang when any data wasn't sent
from backend after connect(2) succeeded. To fix this,
pool_check_fd() returns 1 when select(2) exits with
EINTR due to SIGALRM while health checkking is performed.
Reported and patch provided by harukat and some modification
by Yugo. Per bug #204.
backported from 3.4 or later;
https://git.postgresql.org/gitweb/?p=pgpool2.git;a=commitdiff;h=ed9f2900f1b611f5cfd52e8f758c3616861e60c0
- Fix bug with load balance node id info on shmem (Tatsuo Ishii)
There are few places where the load balance node was mistakenly put on
wrong place. It should be placed on: ConnectionInfo *con_info[child
id, connection pool_id, backend id].load_balancing_node]. In fact it
was placed on: *con_info[child id, connection pool_id,
0].load_balancing_node].
As long as the backend id in question is 0, it is ok. However while
testing pgpool-II 3.6's enhancement regarding failover, if primary
node is 1 (which is the load balance node) and standby is 0, a client
connecting to node 1 is disconnected when failover happens on node
0. This is unexpected and the bug was revealed.
It seems the bug was there since long time ago but it had not found
until today by the reason above.
===============================================================================
--
Bo Peng <pengbo at sraoss.co.jp>
SRA OSS, Inc. Japan
More information about the pgpool-hackers
mailing list