pgpool2.git / summary / log / commit / refs

commit    5019aedc817fbbe60ee2a5f93b48bf0c8dde4578
Author:   Nozomi Anzai <anzai@sraoss.co.jp>
Commit:   Muhammad Usama <m.usama@gmail.com>
Date:     Fri Dec 06 05:04:30 2013 +0000

    Add release notes of 3.0.14, 3.1.10 and 3.2.7


NEWS | 786 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 710 insertions(+), 76 deletions(-) diff --git a/NEWS b/NEWS index 4ff1cb75d..a670b293d 100644 --- a/NEWS +++ b/NEWS @@ -5,7 +5,6 @@ =============================================================================== - 3.3.2 (tokakiboshi) 2013/11/29 * Version 3.3.2 @@ -674,7 +673,7 @@ wrong query comes in, the transaction goes into an abort state but pgpool does not close the transaction. Thus next query causes error because the transaction is still in abort status. - + This problem was reported in [pgpool-general: 1877] by Sean Hogan. [pgpool-general: 1877] current transaction is aborted, commands ignored @@ -724,6 +723,305 @@ =============================================================================== 3.2 Series (2012/08/03 - ) +=============================================================================== + + 3.2.7 (tokakiboshi) 2013/12/06 + +* Version 3.2.7 + + This is a bugfix release against pgpool-II 3.2.6. + + __________________________________________________________________ + +* Bug fixes + + - Fix incorrect time stamp rewriting in replication mode for certain time + zones. (Tatsuo Ishii) + + Time stamp rewriting calls "SELECT now()" to get current time. + Unfortunately the buffer for the current time is too small for certain + time zones such as "02:30". Note that non-30-minutes-time-zone such as + "0900" does not reveal the problem. This explains why we haven't the bug + report until today. + + Bug reported in [pgpool-general: 2113] and fix provided by Sean Hogan. + http://www.sraoss.jp/pipermail/pgpool-general/2013-September/002142.html + + - Makefile: Replace pg_config by $(PG_CONFIG) in Makefiles so it can be + overridden at build time when compiling for different PG major versions. + (Tatsuo Ishii) + + Patch contributed by Christoph Berg ([pgpool-general: 2127]). + http://www.sraoss.jp/pipermail/pgpool-general/2013-September/002156.html + + - Remove -lcompat because it confuses FreeBSD per bug#15. (Tatsuo Ishii + http://www.pgpool.net/mantisbt/view.php?id=15 + + - Fix segfault when pgpool.conf does not set log_standby_delay. + (Tatsuo Ishii) + + This is caused by wrong initialization for log_standby_delay in + pool_config.l. + Per bug#74. http://www.pgpool.net/mantisbt/view.php?id=74 + + - doc: Modify descriptions about restrictions of parallel mode + Muliple rows INSERT using VALUES are not supported in parallel mode. + (Yugo Nagata) + + - Avoid calling find_primary_node_repeatedly() when standby node goes + down. (Tatsuo Ishii) + + This will reduce the time to failover. Per bug #75, patch modified by + Tatsuo Ishii. http://www.pgpool.net/mantisbt/view.php?id=75 + + - Fix data inconsistency problem with native replication mode + extended + protocol case. (Tatsuo Ishii) + + It is reported that concurrent INSERT using JDBC driver causes data + difference among database node. This only happens following conditions + are all met: + + 1) Native replication mode + 2) Extended protocol used + 3) The portal created by parse message is reused by bind message + 4) autocommit is on + 5) SERIAL (sequence) is used + + Pgpool-II's parse message function knows it has to lock the target + table when INSERT (plus #5) is issued by clients. Unfortunately bind + message function did not know it. Once parse/bind/execute finishes, + pgpool releases the lock obtained by parse because of #4. JDBC wants + to reuse the portal and starts the cycle from bind message, which does + not obtain lock. As as result, lock-free INSERT are floating around + which causes data inconsistency of course. The solution is, lock the + table in bind phase. + + For this bind needs to issue LOCK in extended protocol. This was a little + bit hard because the module (do_command()) to issue internal SQL command + (other than SELECT) does not support extended protocol. + To solve the problem do_query() is modified so that it accepts other than + SELECT because it already accepts extended protocol. + The modification is minimum and is only tested for the case called from + insert_lock(). I do not recommend to replace every occurrence of + do_command () with do_query() at this point. + + BTW the reason why the bug is not reported is, most users uses JDBC + with auto commit = off. In this case, the lock obtained by parse persists + until user explicitly issues commit or rollback. + + Per bug report by Steve Kuekes in [pgpool-general: 2142]. + http://www.sraoss.jp/pipermail/pgpool-general/2013-September/002171.html + + - Fix memory allocation size bug in the code path of query cache. + (Tatsuo Ishii) + + In execute() memory allocation size is too small incertain case. No bug + has been reported so far, but certainly this is a bug. + + - Fix occasional segfault in query cache + extended protocol. + (Tatsuo Ishii) + + When the query is not "cache safe", bind_msg->param_offset was not set + in Bind(). However, Execute() unconditionally uses bind_msg->param_offset + to convert bind parameters to string so that they can be added to the + cached query string and it causes segfault because bind_msg->param_offset + is a garbage. Also logic bug to calculate bind_msg->param_offset is + corrected. + + Per bug#76. http://www.pgpool.net/mantisbt/view.php?id=76 + + - Avoid to run out free query cache hash index entry. (Tatsuo Ishii) + + If hash index entries are run out, pgpool-II cannot reuse old cache + entry because pgpool-II always expects there's at least one empty hash + index entry. To mitigate the problem, if free hash index entries are run + out, look for victim cache block to reuse the hash index entry. + + Per bug #70. http://www.pgpool.net/mantisbt/view.php?id=70 + + - Fix inappropriate shared memory allocation size for clock hand. + (Tatsuo Ishii) + + The memory for clock hand was allocated as sizeof(pool_fsmm_clock_hand)) + which is 8 bytes long because the variable is declared as: + + static int *pool_fsmm_clock_hand; + + This is plain wrong. The memory size actually needed is only 4 bytes, + which is sizeof(*pool_fsmm_clock_hand)). In other word, the bug allocated + unnecessary 4 bytes, which did nothing bd for the execution of program. + But a bug is a bug. + + Per covery report "1111476 Wrong sizeof argument" + + - Fix "show pool_status" always shows memqcache_auto_cache_invalidation as + 0. (Tatsuo Ishii) + Per bug #80. http://www.pgpool.net/mantisbt/view.php?id=80 + + - Fix error message in read_password_packet(). (Tatsuo Ishii) + + - watchdog: Fix to pass big parameter by pointer instead of by value at + some function. (Yugo Nagata) + + - Fix memory leak when SSL is requested. (Tatsuo Ishii) + + When SSL is requested, pgpool child retries to read start up packet. + However it does not free the memory for previous start up packet. + + Per Coverity report "1111443 Resource". + + - Fix memory leak when do_query() fails in timestamp rewriting. + (Tatsuo Ishii) + + For this purpose free_select_result() is changed to accept NULL argument. + Per Coverity report "1111454, 1111455 Resource leak". + + - watchdog: Fix to put null character at end of ping result string used in + watchdog. (Yugo Nagata) + + - Fix target node selection logic when "DEALLOCATE portal|statement". + (Tatsuo Ishii) + + When "DEALLOCATE portal|statement" is used and last prepared statement or + portal was not found, target node selection map is not set. Probably this + is not actually harmful because prepared statement or portal was not found + is an error case. The bug was there since day 0. + + Per Coverity report "1111491 Structurally dead code". + + - Fix range check bug of MAX_NUM_BACKENDS in corner case. (Tatsuo Ishii) + + MAX_NUM_BACKENDS is the allowed max number of DB nodes (128, at this + point). In reality, probably no one ever tried more than 128 DB nodes + and that's the reason why nobody noticed. + + Per Coverity report "1111429, 1111430 and 1111431 Out-of-bounds write". + + - Do not set/unset fronted connection info for dead backend. (Tatsuo Ishii) + + Per bug #82. http://www.pgpool.net/mantisbt/view.php?id=82 + + - Fix that the script forgets to allow public access to pgpool_catalog. + (Tatsuo Ishii) + + The bug prevents inserting data into user tables if pgpool_catalog is + created in native replication mode. The bug was there from day 1. I + wonder why nobody noticed until today. + Per [pgpool-general-jp: 1229]. + http://www.sraoss.jp/pipermail/pgpool-general-jp/2013-November/001228.html + + - Fix uninitialized variable in error case in pool_do_auth(). + (Tatsuo Ishii) + + If there's no valid backend, pgpool will return garbage pid to frontend in + auth phase. Actually because no backend is available, frontend will be + disconnected later on. So this is not harmless. + Per Coverity report "1127331 Uninitialized scalar variable". + + - Fix to add node id range check when issue an error message using node + id. (Tatsuo Ishii) + Per Coverity report #1111433 "Out-of-bounds read". + + - Fix buffer overrun bug and resource leak bug of parse_copy_data(). + (Tatsuo Ishii) + Per Coverity report 1111427 "Out-of-bounds write" and 1111453 "Resource + leak". + + - Fix possible segfault in CopyDataRaws(). (Tatsuo Ishii) + Coverity pointed out that if pool_get_id() returns an error, VALID_BACKEND + will access out of array. + Per Coverity report 1111413 "Memory - illegal accesses". + + - Fix query cache is enabled and protocol version = 2 case. (Tatsuo Ishii) + + When the protocol version = 2, we assume that session state is "idle". + This is not feasible but no way. I recommend to not use query cache + with protocol 2. + Per Coverity report 1111488 "Uninitialized scalar variable". + + - Fix strftime() usage in pool_pools(). (Tatsuo Ishii) + + The buffer is not large enough as expected by the second parameter. This + is not harmless because the format string will not produce longer result + string than the buffer. + Per Coverity report 1111426 "Out-of-bounds access". + + - Fix resource leak in make_persistent_db_connection. (Tatsio Ishii) + + For this pupose, new static function free_persisten_db_connection_memory + is added. + Per Coverity report #1111468. + + - Fix a bug that connection check to trusted servers fails when the RTT + is very short. (Yugo Nagata) + + - Fix several small bug fixes detected by Coverity. (Tatsuo Ishii) + +=============================================================================== + + 3.2.6 (namameboshi) 2013/09/06 + +* Version 3.2.6 + + This is a bugfix release against pgpool-II 3.2.5. + + __________________________________________________________________ + +* Bug fixes + + - Fix a segmentation fault on main process that could occures after backend + error detection (Tatsuo Ishii) + + This is reported in Bug track #62 by tuomas. + + #62 Slave network outage causes a segmentation fault on main process + http://www.pgpool.net/mantisbt/view.php?id=62 + + - Fix a bug with health check when used with child_life_time (Tatsuo Ishii) + + Failover could happen even if the backend was running fine. + This problem is reported in [pgpool-general: 1892] by larisa sabban. + + [pgpool-general: 1892] Pgpool is unable to connect backend PostgreSQL + http://www.sraoss.jp/pipermail/pgpool-general/2013-July/001920.html + + - Fix "Deploying pgpool-II" section in the document (Tatsuo Ishii) + + Update descriptions about watchdog use. + + - Fix a mistake in ssh command of doc/basebackup.sh (Tatsuo Ishii) + + - Fix a bug in parsing prepared statements with transaction handling in + replication mode (Tatsuo Ishii) + + Parse() automatically starts a transaction for non SELECT query to keep + consistency among nodes in replication mode. But this wasn't closed. If + wrong query comes in, the transaction goes into an abort state but pgpool + does not close the transaction. Thus next query causes error because the + transaction is still in abort status. + + This problem was reported in [pgpool-general: 1877] by Sean Hogan. + + [pgpool-general: 1877] current transaction is aborted, commands ignored + http://www.sraoss.jp/pipermail/pgpool-general/2013-July/001905.html + + - Fix child process termination with sig abort when memory query cache + is enabled (Tatsuo Ishii) + + This is due to double free bug that occurs when multiple bind/execute + messages come after a parse message. When a parse messages comes, query + context is created along with temp cache. The pointer to the temp cache + is added to the temp cache array when the query executed. Subsequent + bind messages uses the same temp cache pointer. This is the source of + double free bug when the cache array discarded. + + This is reported in Bug track #68 by harukat. + + #68: child process termination with sigabort when memory_cache_enabled = on + http://www.pgpool.net/mantisbt/view.php?id=68 + + - Fix typos of the japanese document (Yugo Nagata) + =============================================================================== 3.2.5 (namameboshi) 2013/07/10 @@ -1894,102 +2192,287 @@ - Fix wait_for_query_response() not to send param status to frontend if frontend is NULL. (Tatsuo Ishii) - This could happen while processing reset_query_list and occur crash. + This could happen while processing reset_query_list and occur crash. + + - Fix bug with treatment of BEGIN TRANSACTION in master/slave mode. + (Tatsuo Ishii) + + Original complain is [pgpool-general: 714]. + From 3.1, pgpool-II sends BEGIN.. to all DB nodes. Of course we cannot + send BEGIN TRANSACTION READ WRITE to standby nodes. + Problem is, we did not check BEGIN WORK ISOLATION LEVEL SERIALIZABLE; + and sent to standby nodes. Of course this is wrong, since it's not + allowed to run transactions in serializable mode on standby nodes. + So added check for BEGIN WORK ISOLATION LEVEL SERIALIZABLE case. + + [pgpool-general: 714] + Load Balancing / Streaming Replication / Isolation Level serializable + http://www.pgpool.net/pipermail/pgpool-general/2012-July/000719.html + + - Fix send_to_where() to send the query to only primary if the it is like + SET TRANSACTION ISOLATION LEVELSERIALIZABLE etc. (Tatsuo Ishii) + + Case in streaming replication mode. Previously, it was sent to not only + primary but also to standby and of course this causes an error. + Similar SQLs are: + SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL SERIALIZABLE or + SET transaction_isolation TO 'serializable' + SET default_transaction_isolation TO 'serializable' + + Original complain is [pgpool-general: 715]. + + [pgpool-general: 715] + Re: Load Balancing / Streaming Replication / Isolation Level serializable + http://www.pgpool.net/pipermail/pgpool-general/2012-July/000720.html + + - Prevent errors even if memcached is not available with on memory query + cache enabled and cache storage is memcached. (Tatsuo Ishii) + + This is mainly achieved by modifying pool_fetch_cache to pretend + "cache not found" if memcached_get returns error other than + MEMCACHED_NOTFOUND. Also we set pool_config->memory_cache_enabled to 0 to + prevent future errors by accessing memcached. + + - Run rerun libtoolize with --copy and --force option. (Tatsuo Ishii) + + This should prevent build problems in different environment. + Following commands were executed: + libtoolize --copy --force + aclocal + autoheader + automake -a + autoconf + + - Fix pool_ssl_read. (Tatsuo Ishii) + + When SSL_read returns unknown error, treat as if EOF detected and returns 0 + to caller (pool_read). This is same as libpq's behavior. Also this will + avoid unwanted failover in pool_read. pool_read triggers failover if + underlying I/O functions, read(2) or pool_ssl_read returns -1. + + - Fix pool_process_query. (Tatsuo Ishii) + + When other than primary sends packet, pgpool tries to terminate session + gracefully and hung because now ssl_read returns EOF, rather than error + and triggers failover. For example [pgpool-general: 766] reported this: + + 2012-07-17 00:11:03 NZST [15692]: [257-1] ERROR: canceling statement + due to conflict with recovery + 2012-07-17 00:11:03 NZST [15692]: [258-1] DETAIL: User query might + have needed to see row versions that must be removed. + 2012-07-17 00:11:03 NZST [15692]: [259-1] STATEMENT: <SNIP> + 2012-07-17 00:11:03 NZST [15696]: [366-1] FATAL: terminating + connection due to conflict with recovery + 2012-07-17 00:11:03 NZST [15696]: [367-1] DETAIL: User query might + have needed to see row versions that must be removed. + + In this case pool_process_query should return POOL_ERROR, rather than + POOL_END. + + [pgpool-general: 766] + Re: pgpool dropping backends too much + http://www.pgpool.net/pipermail/pgpool-general/2012-July/000774.html + + - If frontend terminates while reading large number of query results + from backend, pgpool continues to read from backend and write to + frontend until all query results consumued. (Tatsuo Ishii) + + This will take very long time if query results is huge. To finish pgpool + session as soon as possible, modify pool_flush_it to returns error if + fail to write to frontend when operated in other than replication mode. + In replication mode, we need to keep the previous behavior to save + consistency among backends). + + Also fix SimpleForwardToFrontend to return pool_write_and_flush error + status. Before it was ignored. + +=============================================================================== +3.1 Series (2011/09/08 - ) +=============================================================================== + + 3.1.10 (hatsuiboshi) 2013/12/06 + +* Version 3.1.9 + + This is a bugfix release against pgpool-II 3.1.9. + + __________________________________________________________________ + +* Bug fixes + + + + - Fix incorrect time stamp rewriting in replication mode for certain time + zones. (Tatsuo Ishii) + + Time stamp rewriting calls "SELECT now()" to get current time. + Unfortunately the buffer for the current time is too small for certain + time zones such as "02:30". Note that non-30-minutes-time-zone such as + "0900" does not reveal the problem. This explains why we haven't the bug + report until today. + + Bug reported in [pgpool-general: 2113] and fix provided by Sean Hogan. + http://www.sraoss.jp/pipermail/pgpool-general/2013-September/002142.html + + - Makefile: Replace pg_config by $(PG_CONFIG) in Makefiles so it can be + overridden at build time when compiling for different PG major versions. + (Tatsuo Ishii) + + Patch contributed by Christoph Berg ([pgpool-general: 2127]). + http://www.sraoss.jp/pipermail/pgpool-general/2013-September/002156.html + + - configure: Remove -lcompat because it confuses FreeBSD per bug#15. + (Tatsuo Ishii) + http://www.pgpool.net/mantisbt/view.php?id=15 + + - Fix segfault when pgpool.conf does not set log_standby_delay. + (Tatsuo Ishii) + + This is caused by wrong initialization for log_standby_delay in + pool_config.l. + Per bug#74. http://www.pgpool.net/mantisbt/view.php?id=74 + + - doc: Modify descriptions about restrictions of parallel mode + Muliple rows INSERT using VALUES are not supported in parallel mode. + (Yugo Nagata) + + - Avoid calling find_primary_node_repeatedly() when standby node goes + down. (Tatsuo Ishii) + + This will reduce the time to failover. Per bug #75, patch modified by + Tatsuo Ishii. http://www.pgpool.net/mantisbt/view.php?id=75 + + - Fix data inconsistency problem with native replication mode + extended + protocol case. (Tatsuo Ishii) + + It is reported that concurrent INSERT using JDBC driver causes data + difference among database node. This only happens following conditions + are all met: + + 1) Native replication mode + 2) Extended protocol used + 3) The portal created by parse message is reused by bind message + 4) autocommit is on + 5) SERIAL (sequence) is used + + Pgpool-II's parse message function knows it has to lock the target + table when INSERT (plus #5) is issued by clients. Unfortunately bind + message function did not know it. Once parse/bind/execute finishes, + pgpool releases the lock obtained by parse because of #4. JDBC wants + to reuse the portal and starts the cycle from bind message, which does + not obtain lock. As as result, lock-free INSERT are floating around + which causes data inconsistency of course. The solution is, lock the + table in bind phase. + + For this bind needs to issue LOCK in extended protocol. This was a little + bit hard because the module (do_command()) to issue internal SQL command + (other than SELECT) does not support extended protocol. + To solve the problem do_query() is modified so that it accepts other than + SELECT because it already accepts extended protocol. + The modification is minimum and is only tested for the case called from + insert_lock(). I do not recommend to replace every occurrence of + do_command () with do_query() at this point. + + BTW the reason why the bug is not reported is, most users uses JDBC + with auto commit = off. In this case, the lock obtained by parse persists + until user explicitly issues commit or rollback. + + Per bug report by Steve Kuekes in [pgpool-general: 2142]. + http://www.sraoss.jp/pipermail/pgpool-general/2013-September/002171.html + + - Fix error message in read_password_packet(). (Tatsuo Ishii) + + - Fix memory leak when do_query() fails in timestamp rewriting. + (Tatsuo Ishii) + + For this purpose free_select_result() is changed to accept NULL argument. + Per Coverity report "1111454, 1111455 Resource leak". + + - Fix target node selection logic when "DEALLOCATE portal|statement". + (Tatsuo Ishii) + + When "DEALLOCATE portal|statement" is used and last prepared statement or + portal was not found, target node selection map is not set. Probably this + is not actually harmful because prepared statement or portal was not found + is an error case. The bug was there since day 0. + + Per Coverity report "1111491 Structurally dead code". + + - Fix range check bug of MAX_NUM_BACKENDS in corner case. (Tatsuo Ishii) + + MAX_NUM_BACKENDS is the allowed max number of DB nodes (128, at this + point). In reality, probably no one ever tried more than 128 DB nodes + and that's the reason why nobody noticed. + + Per Coverity report "1111429, 1111430 and 1111431 Out-of-bounds write". - - Fix bug with treatment of BEGIN TRANSACTION in master/slave mode. + - Fix that the script forgets to allow public access to pgpool_catalog. (Tatsuo Ishii) - Original complain is [pgpool-general: 714]. - From 3.1, pgpool-II sends BEGIN.. to all DB nodes. Of course we cannot - send BEGIN TRANSACTION READ WRITE to standby nodes. - Problem is, we did not check BEGIN WORK ISOLATION LEVEL SERIALIZABLE; - and sent to standby nodes. Of course this is wrong, since it's not - allowed to run transactions in serializable mode on standby nodes. - So added check for BEGIN WORK ISOLATION LEVEL SERIALIZABLE case. + The bug prevents inserting data into user tables if pgpool_catalog is + created in native replication mode. The bug was there from day 1. I + wonder why nobody noticed until today. + Per [pgpool-general-jp: 1229]. + http://www.sraoss.jp/pipermail/pgpool-general-jp/2013-November/001228.html - [pgpool-general: 714] - Load Balancing / Streaming Replication / Isolation Level serializable - http://www.pgpool.net/pipermail/pgpool-general/2012-July/000719.html + - Fix uninitialized variable in error case in pool_do_auth(). + (Tatsuo Ishii) - - Fix send_to_where() to send the query to only primary if the it is like - SET TRANSACTION ISOLATION LEVELSERIALIZABLE etc. (Tatsuo Ishii) + If there's no valid backend, pgpool will return garbage pid to frontend in + auth phase. Actually because no backend is available, frontend will be + disconnected later on. So this is not harmless. + Per Coverity report "1127331 Uninitialized scalar variable". - Case in streaming replication mode. Previously, it was sent to not only - primary but also to standby and of course this causes an error. - Similar SQLs are: - SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL SERIALIZABLE or - SET transaction_isolation TO 'serializable' - SET default_transaction_isolation TO 'serializable' + - Fix to add node id range check when issue an error message using node + id. (Tatsuo Ishii) + Per Coverity report #1111433 "Out-of-bounds read". - Original complain is [pgpool-general: 715]. + - Fix buffer overrun bug and resource leak bug of parse_copy_data(). + (Tatsuo Ishii) + Per Coverity report 1111427 "Out-of-bounds write" and 1111453 "Resource + leak". - [pgpool-general: 715] - Re: Load Balancing / Streaming Replication / Isolation Level serializable - http://www.pgpool.net/pipermail/pgpool-general/2012-July/000720.html + - Fix possible segfault in CopyDataRaws(). (Tatsuo Ishii) + Coverity pointed out that if pool_get_id() returns an error, VALID_BACKEND + will access out of array. + Per Coverity report 1111413 "Memory - illegal accesses". - - Prevent errors even if memcached is not available with on memory query - cache enabled and cache storage is memcached. (Tatsuo Ishii) + - Fix resource leak in make_persistent_db_connection. (Tatsio Ishii) - This is mainly achieved by modifying pool_fetch_cache to pretend - "cache not found" if memcached_get returns error other than - MEMCACHED_NOTFOUND. Also we set pool_config->memory_cache_enabled to 0 to - prevent future errors by accessing memcached. + For this pupose, new static function free_persisten_db_connection_memory + is added. + Per Coverity report #1111468. - - Run rerun libtoolize with --copy and --force option. (Tatsuo Ishii) +=============================================================================== - This should prevent build problems in different environment. - Following commands were executed: - libtoolize --copy --force - aclocal - autoheader - automake -a - autoconf + 3.1.9 (hatsuiboshi) 2013/09/06 - - Fix pool_ssl_read. (Tatsuo Ishii) +* Version 3.1.9 - When SSL_read returns unknown error, treat as if EOF detected and returns 0 - to caller (pool_read). This is same as libpq's behavior. Also this will - avoid unwanted failover in pool_read. pool_read triggers failover if - underlying I/O functions, read(2) or pool_ssl_read returns -1. + This is a bugfix release against pgpool-II 3.1.8. - - Fix pool_process_query. (Tatsuo Ishii) + __________________________________________________________________ - When other than primary sends packet, pgpool tries to terminate session - gracefully and hung because now ssl_read returns EOF, rather than error - and triggers failover. For example [pgpool-general: 766] reported this: +* Bug fixes - 2012-07-17 00:11:03 NZST [15692]: [257-1] ERROR: canceling statement - due to conflict with recovery - 2012-07-17 00:11:03 NZST [15692]: [258-1] DETAIL: User query might - have needed to see row versions that must be removed. - 2012-07-17 00:11:03 NZST [15692]: [259-1] STATEMENT: <SNIP> - 2012-07-17 00:11:03 NZST [15696]: [366-1] FATAL: terminating - connection due to conflict with recovery - 2012-07-17 00:11:03 NZST [15696]: [367-1] DETAIL: User query might - have needed to see row versions that must be removed. + - Fix a mistake in ssh command of doc/basebackup.sh (Tatsuo Ishii) - In this case pool_process_query should return POOL_ERROR, rather than - POOL_END. + - Fix a bug in parsing prepared statements with transaction handling in + replication mode (Tatsuo Ishii) - [pgpool-general: 766] - Re: pgpool dropping backends too much - http://www.pgpool.net/pipermail/pgpool-general/2012-July/000774.html + Parse() automatically starts a transaction for non SELECT query to keep + consistency among nodes in replication mode. But this wasn't closed. If + wrong query comes in, the transaction goes into an abort state but pgpool + does not close the transaction. Thus next query causes error because the + transaction is still in abort status. - - If frontend terminates while reading large number of query results - from backend, pgpool continues to read from backend and write to - frontend until all query results consumued. (Tatsuo Ishii) + This problem was reported in [pgpool-general: 1877] by Sean Hogan. - This will take very long time if query results is huge. To finish pgpool - session as soon as possible, modify pool_flush_it to returns error if - fail to write to frontend when operated in other than replication mode. - In replication mode, we need to keep the previous behavior to save - consistency among backends). + [pgpool-general: 1877] current transaction is aborted, commands ignored + http://www.sraoss.jp/pipermail/pgpool-general/2013-July/001905.html - Also fix SimpleForwardToFrontend to return pool_write_and_flush error - status. Before it was ignored. + - Fix typos of the japanese document (Yugo Nagata) -=============================================================================== -3.1 Series (2011/09/08 - ) =============================================================================== 3.1.8 (hatsuiboshi) 2013/07/10 @@ -2850,6 +3333,157 @@ =============================================================================== 3.0 Series (2010/09/10 - ) +=============================================================================== + + 3.0.14 (umiyameboshi) 2013/12/06 + +* Version 3.0.13 + + This is a bugfix release against pgpool-II 3.0.13. + + __________________________________________________________________ + +* Bug fixes + + - Fix incorrect time stamp rewriting in replication mode for certain time + zones. (Tatsuo Ishii) + + Time stamp rewriting calls "SELECT now()" to get current time. + Unfortunately the buffer for the current time is too small for certain + time zones such as "02:30". Note that non-30-minutes-time-zone such as + "0900" does not reveal the problem. This explains why we haven't the bug + report until today. + + Bug reported in [pgpool-general: 2113] and fix provided by Sean Hogan. + http://www.sraoss.jp/pipermail/pgpool-general/2013-September/002142.html + + - Makefile: Replace pg_config by $(PG_CONFIG) in Makefiles so it can be + overridden at build time when compiling for different PG major versions. + (Tatsuo Ishii) + + Patch contributed by Christoph Berg ([pgpool-general: 2127]). + http://www.sraoss.jp/pipermail/pgpool-general/2013-September/002156.html + + - configure: Remove -lcompat because it confuses FreeBSD per bug#15. + (Tatsuo Ishii) + http://www.pgpool.net/mantisbt/view.php?id=15 + + - Fix segfault when pgpool.conf does not set log_standby_delay. + (Tatsuo Ishii) + + This is caused by wrong initialization for log_standby_delay in + pool_config.l. + Per bug#74. http://www.pgpool.net/mantisbt/view.php?id=74 + + - doc: Modify descriptions about restrictions of parallel mode + Muliple rows INSERT using VALUES are not supported in parallel mode. + (Yugo Nagata) + + - Avoid calling find_primary_node_repeatedly() when standby node goes + down. (Tatsuo Ishii) + + This will reduce the time to failover. Per bug #75, patch modified by + Tatsuo Ishii. http://www.pgpool.net/mantisbt/view.php?id=75 + + - Fix error message in read_password_packet(). (Tatsuo Ishii) + + - Fix memory leak when do_query() fails in timestamp rewriting. + (Tatsuo Ishii) + + For this purpose free_select_result() is changed to accept NULL argument. + Per Coverity report "1111454, 1111455 Resource leak". + + - Fix target node selection logic when "DEALLOCATE portal|statement". + (Tatsuo Ishii) + + When "DEALLOCATE portal|statement" is used and last prepared statement or + portal was not found, target node selection map is not set. Probably this + is not actually harmful because prepared statement or portal was not found + is an error case. The bug was there since day 0. + + Per Coverity report "1111491 Structurally dead code". + + - Fix range check bug of MAX_NUM_BACKENDS in corner case. (Tatsuo Ishii) + + MAX_NUM_BACKENDS is the allowed max number of DB nodes (128, at this + point). In reality, probably no one ever tried more than 128 DB nodes + and that's the reason why nobody noticed. + + Per Coverity report "1111429, 1111430 and 1111431 Out-of-bounds write". + + - Fix that the script forgets to allow public access to pgpool_catalog. + (Tatsuo Ishii) + + The bug prevents inserting data into user tables if pgpool_catalog is + created in native replication mode. The bug was there from day 1. I + wonder why nobody noticed until today. + Per [pgpool-general-jp: 1229]. + http://www.sraoss.jp/pipermail/pgpool-general-jp/2013-November/001228.html + + - Fix uninitialized variable in error case in pool_do_auth(). + (Tatsuo Ishii) + + If there's no valid backend, pgpool will return garbage pid to frontend in + auth phase. Actually because no backend is available, frontend will be + disconnected later on. So this is not harmless. + Per Coverity report "1127331 Uninitialized scalar variable". + + - Fix to add node id range check when issue an error message using node + id. (Tatsuo Ishii) + Per Coverity report #1111433 "Out-of-bounds read". + + - Fix buffer overrun bug and resource leak bug of parse_copy_data(). + (Tatsuo Ishii) + Per Coverity report 1111427 "Out-of-bounds write" and 1111453 "Resource + leak". + + - Fix possible segfault in CopyDataRaws(). (Tatsuo Ishii) + Coverity pointed out that if pool_get_id() returns an error, VALID_BACKEND + will access out of array. + Per Coverity report 1111413 "Memory - illegal accesses". + + - Fix strftime() usage in pool_pools(). (Tatsuo Ishii) + + The buffer is not large enough as expected by the second parameter. This + is not harmless because the format string will not produce longer result + string than the buffer. + Per Coverity report 1111426 "Out-of-bounds access". + + - Fix resource leak in make_persistent_db_connection. (Tatsio Ishii) + + For this pupose, new static function free_persisten_db_connection_memory + is added. + Per Coverity report #1111468. + +=============================================================================== + 3.0.13 (umiyameboshi) 2013/09/06 + +* Version 3.0.13 + + This is a bugfix release against pgpool-II 3.0.12. + + __________________________________________________________________ + +* Bug fixes + + - Fix a mistake in ssh command of doc/basebackup.sh (Tatsuo Ishii) + + - Fix a bug in parsing prepared statements with transaction handling in + replication mode (Tatsuo Ishii) + + Parse() automatically starts a transaction for non SELECT query to keep + consistency among nodes in replication mode. But this wasn't closed. If + wrong query comes in, the transaction goes into an abort state but pgpool + does not close the transaction. Thus next query causes error because the + transaction is still in abort status. + + This problem was reported in [pgpool-general: 1877] by Sean Hogan. + + [pgpool-general: 1877] current transaction is aborted, commands ignored + http://www.sraoss.jp/pipermail/pgpool-general/2013-July/001905.html + + - Fix typos of the japanese document (Yugo Nagata) + =============================================================================== 3.0.12 (umiyameboshi) 2013/07/10 @@ -2939,7 +3573,7 @@ =============================================================================== - 3.0.11 (umeyameboshi) 2013/04/26 + 3.0.11 (umiyameboshi) 2013/04/26 * Version 3.1.7 [parent: 89066fda917f]