pgpool2.git / summary / log / commit / refs
commit 07bb220657169343e85116a837f29a6127b4007a
Author: Nozomi Anzai <anzai@sraoss.co.jp>
Date: Mon Feb 18 02:51:14 2013 +0000
Prepare 3.2.3.
NEWS | 1239 +++++++++++++++++++++++++++++++++
doc/pgpool-ja.html | 1970 +++++++++++++++++++++++++++++++++++++++++++++-------
2 files changed, 2960 insertions(+), 249 deletions(-)
diff --git a/NEWS b/NEWS
index 94382b628..cae4c9763 100644
--- a/NEWS
+++ b/NEWS
@@ -2,6 +2,587 @@
===============================================================================
3.2 Series (2012/08/03 - )
+===============================================================================
+
+ 3.2.3 (namameboshi) 2013/2/18
+
+* Version 3.2.3
+
+ This is a bug fix release against pgpool-II 3.2.2. Main purpose
+ of this release is to fix fatal problem with pgpool-II 3.2.2's
+ health checking. If all of following conditions are met, pgpool
+ main process disappeared and all client connections to pgpool-II
+ hang forever when failover happens. And the only way to recover
+ from it is, manualy killing the pgpool child process and restart
+ pgpool-II.
+
+ - health checking is enabled
+
+ - connecting method to PostgreSQL is TCP/IP, not UNIX domain
+ socket(i.e. "backend_hostnameN" is not empty string)
+
+ __________________________________________________________________
+
+* Bug fixes
+
+ - Fix connect_inet_domain_socket_by_port() bug introduced in
+ 3.2.2. (Tatsuo Ishii)
+
+ When non blocking connect() reports EINPROGRESS or EALREADY, it
+ calls select(2) to wait for read or write fd ready. However it
+ mistakenly checks error condition using getsockopt(). It should
+ be called when select() returns > 0, rather than 0. Because of
+ this, connect_inet_domain_socket_by_port() could return
+ succeeded fd even it actually failed.
+
+ And what is worse, this health_check() mistakenly believes that
+ backend is alive and tries to write to backend socket, which of
+ course fails. This triggers to call notice_backend_error(),
+ which sends SIGUSR1 signal to pgpool main's parent process. This
+ will result in various weird things: for example, if you start
+ pgpool from a shell, the signal kills the shell. If you start
+ pgpool in background, pgpool's parent is the process #1. As long
+ as you started pgpool as non root, it's ok. Even if you start
+ pgpool as root, init just reopens /dev/initctl by receiving
+ SIGUSR1. These all annoying bugs have been there since pgpool
+ was born. The connect_inet_domain_socket_by_port() bug just
+ reveals it. To fix this, I modified notice_backend_error and
+ child_exit() so that it does nothing when called from pgpool
+ main process itself to prevent pgpool from shooting itself in
+ the foot.
+
+ - Fix to show pool_passwd in "SHOW pool_status". (Yugo Nagata)
+
+ - Fix a typo at configure's help in configure.in. (Yugo Nagata)
+
+===============================================================================
+
+ 3.2.2 (namameboshi) 2013/2/8
+
+* Version 3.2.2
+
+ This is a bugfix release against pgpool-II 3.2.1.
+
+ __________________________________________________________________
+
+* Bug fixes
+
+ - Fix compile errors on FreeBSD. (Tatsuo Ishii)
+
+ - Fix pgpool does not recognize VIEWs other than in default schema,
+ which is usually "public". (Tatsuo Ishii)
+
+ This makes pgpool to create caches for such a VIEW's query results,
+ which of course should not be allowed.
+
+ Problem reported and patch provided by jgentsch in bug id #30.
+
+ #30 pgpool 3.2.1 - views in schema other than public are caching
+ Reporter: jgentsch
+ Date: 2012-10-19 23:13
+ http://www.pgpool.net/mantisbt/view.php?id=30
+
+ - Fix race condition when using md5 authentication. (Tatsuo Ishii)
+
+ The file descriptor to pool_passwd is opened in pgpool main and pgpool
+ child inherits it. When concurrent connections try to authenticate md5
+ method, they call pool_get_passwd and seek the fd and cause random md5
+ auth failure because underlying fd is shared. Fix is, let individual
+ pgpool child open the file by calling pool_reopen_passwd_file.
+
+ Problem reported and analyzed by Jason Slagle in pgpool-general:1141.
+
+ [pgpool-general: 1141] Possible race condition in pool_get_passwd
+ From: Jason Slagle
+ Date: Sun, 28 Oct 2012 01:12:52 -0400
+ http://www.sraoss.jp/pipermail/pgpool-general/2012-October/001160.html
+
+ - Clarify load balance condition information in manual. (Tatsuo Ishii)
+
+ - Fix segfault due to bug with query cache array handling. (Tatsuo Ishii)
+
+ The cache arrary is used to keep temporary cache results in a transaction.
+ If there are more than 128 SELECTs in a transaction, the module expands
+ cache_arrary by using realloc. However it does not record the new pointer
+ returned by realloc. So the module keeps on using the old pointer which is
+ absoleted.
+
+ This problem is reported in bug track #31 by jgentsch.
+
+ #31 pgpool V3_2_STABLE - segfault in pool_memqcache.c:2529
+ Reporter:jgentsch
+ Date: 2012-10-23 06:25
+ http://www.pgpool.net/mantisbt/view.php?id=31
+
+ - Fix hung up while repeating pcp_attach_node and pcp_detatch_node
+ (Tatsuo Ishii)
+
+ When node status is changed by pcp_attach_node and pcp_detatch_node,
+ failover() sends SIGUSR1 to pcp_child process expecting it exits to
+ refresh node status. In this situation lots of pgpool children exit and
+ produce SIGCHLD as well. The SIGCHLD handler reaper() tries catch all
+ SIGCHLD but sometimes it fails depending on the system load and timing.
+ If SIGCHLD produced by pcp child is not caught, the process becomes
+ zombie and never restarted.
+
+ This problem is reported in bug track #32 (by oleg_myrk) etc.
+
+ #32 PGPool hangs on pcp_attach/detach
+ Reporter: oleg_myrk
+ Date: 2012-10-24 00:01
+ http://www.pgpool.net/mantisbt/view.php?id=32
+
+ - Fix pool_send_severity_message() not to use uninitialized memory.
+ (Tatsuo Ishii)
+
+ It cause a segmentaion fault.
+ Reported in Bug #33's attached valgrind output by dudee.
+
+ #33 pgpool-II 3.2.1 segfault
+ Reporter: dudee
+ Date: 2012-10-30 19:16
+ http://www.pgpool.net/mantisbt/view.php?id=33
+
+ - Fix bug with query cache returning incorrect data in some cases when a
+ persistent table and temp table have same name. (Tatsuo Ishii)
+
+ Here is a sequence to trigger the bug:
+
+ 1) CREATE TABLE t1(i int); -- create a persistent table
+ 2) INSERT INTO t1 VALUES(1);
+ 3) SELECT * FROM t1; -- query cache entry created
+ 4) CREATE TEMP TABLE t1(i int); -- create a temp table
+ 5) SELECT * FROM t1; -- query cache entry mistakenly created!
+
+ Problem is #3 creates relcache entry for t1, and #5 incorrecly uses it
+ and believes that temp table t1 is not a temp table.
+
+ - Add a description about "-f" to help message. (Tatsuo Ishii)
+
+ - Fix reaper() not to exit wait3() loop when catches pcp or worker child
+ exit event. (Tatsuo Ishii)
+
+ Otherwise reaper() mistakenly ignore some process exit event and make a
+ risk of creating zombie process and forgetting to create new process.
+
+ Problem reported and fix suggested by Goto in [pgpool-general-jp: 1123].
+ http://www.sraoss.jp/pipermail/pgpool-general-jp/2012-November/001122.html
+ (in Japanese)
+
+ - Fix a typo of configure help message. (Yugo Nagata)
+
+ - Add wd_hostname to pool_process_reporting.c. (Yugo Nagata)
+
+ Otherwise, wd_hostname is not contained in results of SHOW pool_status and
+ cp_pool_status.
+
+ - Fix connect_inet_domain_socket_by_port() to not error out when connect(2)
+ returns EISCONN (Socket is already connected) error. (Tatsuo Ishii)
+
+ This could happen with non blocking socket and should be treated as normal.
+ Per bug track #29 (by spork) and pgpool-general 1218 (by Mikola Rose).
+
+ #29 pgpool 3.2.1 cannot connect to db hosts
+ Reporter: spork
+ Date: 2012-10-18 15:03
+ http://www.pgpool.net/mantisbt/view.php?id=29
+
+ [pgpool-general: 1218] pgpool 3.2.1 - Health check failing to connect
+ From: Mikola Rose
+ Date: Tue, 4 Dec 2012 20:21:55 +0000
+ http://www.sraoss.jp/pipermail/pgpool-general/2012-December/001237.html
+
+ - Fix health_check() to check the health check timer before retrying
+ with template1 database. (Tatuo Ishii)
+
+ Without this, the retry with node 0 always fails because health check timer
+ may be already expired.
+
+ - Fix pool_search_relcache() to use MASTER or MASTER_NODE_ID macro, rather
+ than REAL_MASTER_NODE_ID. (Tatsuo Ishii)
+
+ In case node 0 fail back in streaming replication mode, pgpool does not
+ restart child process. So REAL_MASTER_NODE_ID looks for node 0 con info,
+ which is not present until new connection to backend made. Thus referring
+ to node con info results in segfault. MASTER or MASTER_NODE_ID are safe in
+ this situation because they look at cached former master node id.
+
+ - Fix long standing bug "portal not found" error when replication delay
+ is too much in streaming replication mode. (Tatsuo Ishii)
+
+ The bug had been there since the delay threshold was introduced.
+
+ We changed destination DB node if delay threshold exceeds in bind,
+ describe and execute. However, if parse sends to different node, bind,
+ describe or execute will fail because no parsed statement or portal
+ exists. Solution is, not to send to different parse node even
+ if delay threshold is too much.
+
+ - Fix pg_md5 to output "\n" after user inputs password. (Yugo Nagata)
+
+ - Fix to print error message when the port number for watchdog is already used.
+ (Yugo Nagata)
+
+ This issue was reported by Will Ferguson in [pgpool-general: 1167].
+
+ [pgpool-general: 1167] Re: Watchdog error - wd_init: delegate_IP already exists
+ From: Will Ferguson
+ Date: Tue, 6 Nov 2012 13:03:36 +0000
+ http://www.sraoss.jp/pipermail/pgpool-general/2012-November/001186.html
+
+ - Fix child_exit() to not call send_frontend_exits() if there's no
+ connection pool. (Tatsuo Ishii)
+
+ Otherwise, it segfaults because send_frontend_exits() referes to objects
+ pointed to by pool_connection_pool. Per bug track #44 by tuomas.
+
+ #44 pgpool went haywire after slave shutdown triggering master failover
+ Reporter: tuomas
+ Date: 2012-12-11 00:33
+ http://www.pgpool.net/mantisbt/view.php?id=44
+
+ - Fix bug that only tables in white_memqcache_table_list was cached when
+ black_memqcache_table_list has any tables. (Yugo Nagata)
+
+ - Fix read_startup_packet() to reset alarm and free StartupPacket when
+ pool_read() returns 0 which means incorrect packet length. (Nozomi Anzai)
+
+ Previously, authentication timeout occurs when connected by a program
+ monitoring the pgpool port.It is reported in bug track #35.
+
+ #35 Authentication is timeout
+ Reporter: tuomas
+ Date: 2012-11-20 11:54
+ http://www.pgpool.net/mantisbt/view.php?id=35
+
+ - Fix long standing bug with pool_open(). (Tatsuo Ishii)
+
+ It initializes wrong buffer pointer. Actually this is harmless because the
+ pointer is initialized by prior memset() call, though.
+
+ - Log that failover is avoided because "fail_over_on_backend_error" is
+ turned off. (Tatsuo Ishii)
+
+ - Fix LISTEN/NOTIFY handling bugs. (Tatsuo Ishii)
+
+ 1) In streaming replication mode:
+
+ Session 1: LISTEN aaa;
+ Session 2: NOTIFY aaa;
+ Session 1: LISTEN aaa; --- hangs
+
+ (If LISTEN and NOTIFY are issued in a same session, it works fine.)
+
+ We assume that packets come from all nodes. However in streaming
+ replication mode, notification message only comes from primary
+ node and we should avoid reading from standby nodes.
+
+ 2) In streaming replication mode: If primary node is not node 0, it
+ hangs like #1 even if fix applies. This is because MASTER_NODE_ID
+ macro (actually pool_virtual_master_db_node_id()) always returns
+ REAL_MASTER_NODE_ID, which is node 0 (if it is alive). The function
+ should return PRIMARY_NODE_ID in master/slave mode.
+
+ 3) In replication mode, LISTEN/NOTIFY simply does not work. In the
+ mode, NOTIFY is sent to all backends. However the order of arrival of
+ 'Notification response' is not necessarily the master first and then
+ slaves. So if it arrives slave first, we should try to read from
+ master, rather than just discard it. Fixed in pool_process_query().
+
+ 4) In replication mode, if LISTEN and NOTIFY are issued in a same
+ session, the session is disconnected because do_command() may receive
+ other than 'N', 'E', 'S' and 'C'. The solution is, put 'A' packet on a
+ stack and pop out when it is convenient. For this purpose, new
+ functions pool_push(), pool_pop() and pool_stacklen() are added.
+
+ This probmel is reported in but grack #45 by rpashin.
+
+ #45 LISTEN/NOTIFY doesn't work if cluster contains more then 1 node in
+ streaming replication mode
+ Reporter: rpashin
+ Date: 2012-12-12 00:09
+ http://www.pgpool.net/mantisbt/view.php?id=45
+
+ Considering the size of the patch, I do not back patch to 3.1 or
+ before(so far, we have not heard any complaints on 3.1 or before).
+
+ - Fix connect_inet_domain_socket_by_port() to call select(2) rather than
+ error out when connect(2) returns EINPROGESS or EALREADY error.
+ (Tatsuo Ishii)
+
+ When using non-blocking socket, despite the errors like
+ "Connection timed out", actually connection has been established.
+ To solve the problem we should use select(2) to wait for connection
+ establishing when connect(2) reports EINPROGRESS or EALREADY, instead
+ of doing a retry tight loop.
+
+ This problem is reported in bug track #46 by mcousin.
+
+ #46 Watchdog failing to connect sometimes
+ Reporter: mcousin
+ Date: 2012-12-15 01:01
+ http://www.pgpool.net/mantisbt/view.php?id=46
+
+ - Add caution to increase num_init_children if watchdog enabled in manual.
+ (Tatsuo Ishii)
+
+ See [pgpool-general: 1330] for more details.
+
+ [pgpool-general: 1330] WatchDog and pgool sudden stop working
+ From: Tomas Halgas
+ Date: Fri, 18 Jan 2013 14:47:23 +0100
+ http://www.sraoss.jp/pipermail/pgpool-general/2013-January/001350.html
+
+ - Fix segmentation fault while pgpool-II stating up or fail over when
+ watchdog is enabled. (Yugo Nagata)
+
+ This is caused by wrong usage of pthread, namely pthread_detach and
+ pthread_join are mixed together. Solution is to use pthread_join only
+ if we need to get status of child thread. BTW, the problem could occu
+ on moderately modern OS such as Fedora 17, but the reason why the problem
+ is not observed on other OSs is, just we were lucky.
+
+ Problem reported in [pgpool-general: 1179] by Lonni J Friedman.
+
+ [pgpool-general: 1179] 3.2.1 segfaults at startup on Fedora17.
+ From: Lonni J Friedman
+ Date: Mon, 12 Nov 2012 15:58:29 -0800
+ http://www.sraoss.jp/pipermail/pgpool-general/2012-November/001198.html
+
+ Patch provided by chads in bug track #48.
+
+ pthread_detach is being used wrong; causes pgpool to segfault.
+ Reporter: chads
+ Date: 2013-01-16 05:44
+ http://www.pgpool.net/mantisbt/view.php?id=48
+
+ - Avoid split-brain situation reported in [pgpool-general: 1046] (Yugo Nagata)
+
+ After all backend nodes are detached from pgpools and then some backend node
+ are attached to these, multiple active pgpools could exist simultaneously,
+ that is to say, split-brain situation occurs.
+
+ In this fix, when once all backend DB nodes are detached from pgpool, the pgpool
+ stays DOWN status until this is restarted. The pgpool in DOWN status cannot
+ escalate to active (delegate IP holder), so split-brain situation is avoided.
+
+ [pgpool-general: 1046]
+ watchdog enabled delegate_IP on multiple nodes simultaneously
+ From: Lonni J Friedman
+ Date: Wed, 26 Sep 2012 09:05:09 -0700
+ http://www.sraoss.jp/pipermail/pgpool-general/2012-September/001064.html
+
+ - Avoid a possible hang during the active pgpool exits. (Yugo Nagata)
+
+ When exiting, the active pgpool brings down the virtual IP and then
+ sends a packet to other pgpools. However, the packet sometimes is sent
+ before the virtual IP is brought down completely. In this case the packet
+ sender is set to this IP. When the IP is brought down before other pgpools
+ respond, the active pgpool can not recieve the response, and hang up.
+
+ In this fix, the active pgpool confirms that the virtual IP is brought
+ down before sending the packet.
+
+ - Modify descriptions of restrictions on watchdog. (Yugo Nagata)
+
+ - Modify pgpool.conf.sample* and documents to correct information of
+ whether a certain parameter change requires restart. (Yugo Nagata)
+
+ - Add pool_passwd option to pgpool.conf.sample*, pool_process_reporting.c,
+ and documents. (Yugo Nagata)
+
+ Otherwise, wd_hostname is not contained in results of SHOW pool_status and
+ pcp_pool_status.
+
+===============================================================================
+
+ 3.2.1 (namameboshi) 2012/10/12
+
+* Version 3.2.1
+
+ This is a bugfix release against pgpool-II 3.2.0.
+
+ __________________________________________________________________
+
+* Bug fixes
+
+ - Fix send_cached_messages(). (Tatsuo Ishii)
+
+ Before it had 8192 bytes fix length buffer for each row data and if data
+ exceeded 8192 bytes, it just crashed.
+ To fix this, eliminate copying raw data which is passed as an argument
+ to buffer and pass the pointer to send_message.
+
+ - Fix that extended queries failed due to query cache. (Nozomi Anzai)
+
+ - Fix read_startup_packet(). (Tatsuo Ishii)
+
+ If packet length is lower than 0, it should have returned immediately.
+ Otherwise it would cause memory allocation error later on.
+ per pgpool-general:886. Also add canceling alarm.
+
+ [pgpool-general: 886] read_startup_packet: out of memory
+ From: Lonni J Friedman
+ Date: Wed, 8 Aug 2012 10:18:15 -0700
+ http://www.sraoss.jp/pipermail/pgpool-general/2012-August/000896.html
+
+ - Fix too watchdog process's aggressively kill other processes when pgpool
+ shuts down. (Tatsuo Ishii)
+
+ watchdog process calls kill(0,SIG) to kill all processes related to
+ watchdog. Unfortunately this will kill not only watchdog related
+ processes but parent pgpool and even httpd in case when pgpool was
+ invoked from pgpoolAdmin because they are in the same process
+ group.
+ So for now, fix is removing call to the kill() and setpgid() because
+ setpgid() does nothing useful.
+
+ In the future, we should call setsid() to establish new process group
+ in any case.
+
+ - Fix query cache to regist such queries that start with "-- comment" or
+ have comments more than one. (Nozomi Anzai)
+
+ - Fix query cache to ignore multi statement. (Nozomi Anzai)
+
+ In previous, queries like "SELECT 1;UPDATE..." were cached, too, but it
+ was wrong.
+
+ - Add a watchdog restriction to documents. (Yugo Nagata)
+
+ - Add NOTICE message handling to s_do_auth(). (Tatsuo Ishii)
+
+ Without this, health check responses false alarm and causes failover.
+ per bug track:
+
+ #25 s_do_auth doesn't handle NoticeResponse (N) message
+ Date: 2012-08-28 03:57
+ Reporter: singh.gurjeet
+ Date:
+ http://www.pgpool.net/mantisbt/view.php?id=25
+
+ - Remove unnecessary/confusing debug log from s_do_auth().(Tatsuo Ishii)
+
+ - Fix buffer overrun in Execute when memory cache enabled.
+ (Tatsuo Ishii)
+
+ If one of bind parameter < 0, it was possible to produce more than 2
+ byte string for "%02X" due to sign extention.
+ Also use snprintf, rather than sprintf to prevent from possible buffer
+ overrun in the future.
+
+ - Fix long standing memory leak bug with free_select_result() since
+ pgpool-II 2.3 was born in December 2009. (Tatsuo Ishii)
+
+ Actually this bug only appears when operated in replication mode
+ (triggered by timestamp rewriting process by coincidence).
+ Per bug track #24:
+
+ #24 Severe memory leak in an OLTP environment
+ Date: 2012-08-28 03:43
+ Reporter: singh.gurjeet
+ Date:
+ http://www.pgpool.net/mantisbt/view.php?id=24
+
+ - Fix typo in cache_reporting(). (Tatsuo Ishii)
+
+ - Fix inifinit loop in SSL mode. (Tatsuo Ishii)
+
+ When there's pending data in SSL layer of frontend, pool_process_query()
+ checks pending data in backend. If there's non, it loops again and checks
+ frontend/backend receive buffer by using is_cache_empty().
+ Unfortunately it first checks pending data in SSL layer of frontend,
+ thus goes to backend data and checks again (infinite loop).
+
+ The solution is, if there's pending data in SSL layer of frontend and
+ query is not in progress, call ProcessFrontendResponse() to process new
+ request from frontend.
+
+ - Fix is_system_catalog() to use pgpool_regclass if available.
+ (Tatsuo Ishii)
+
+ - Fix memory leak in pool_get_insert_table_name(). (Tatsuo Ishii)
+
+ If session context's memory contex is used for nodeToString(), memory is
+ not freed until session ends.
+ See bug track #24 for more details.
+
+ #24 Severe memory leak in an OLTP environment
+ Date: 2012-08-28 03:43
+ Reporter: singh.gurjeet
+ http://www.pgpool.net/mantisbt/view.php?id=24
+
+ - Use fcntl(2) rather than flock(2) to lock oid map files. (Tatsuo Ishii)
+
+ flock(2) is not portable and cannot be used on Solaris.
+ Patch contributed by Ibrar Ahmed.
+
+ - Fix oversight of get_next_master_node() when operated in raw mode.
+ (Tatsuo Ishii)
+
+ If master node goes down, it always returned master node id 0.
+ See [pgpool-general: 1039] for more details.
+
+ [pgpool-general: 1039] Raw failover not working as expected on pgpool-II
+ v3.2.0
+ From: Quentin White
+ Date: Tue, 25 Sep 2012 07:45:34 +0000
+ http://www.sraoss.jp/pipermail/pgpool-general/2012-September/001057.html
+
+ - Fix segfault of do_query(). (Tatsuo Ishii)
+
+ When memqcache enabled and extended protocol is used, do_query()
+ accesses system catalog and use pool_read2(). Unfortunately parse message
+ packet is given to Parse() and the packet contents is on pool_read2's
+ buffer. Thus do_query could break the packet contents, and it leads to
+ segfault.
+
+ Solution is, allocate memory and copies the packet contents and pass to
+ Parse(). Note that query context holds query string, which is in the
+ packet as well. So we need to copy it and save the pointer in the
+ query context.
+
+ We think the problem is not only with Parse() but with other protocol
+ modules. So this fix is not Parse() only, rather for other modules. For
+ this purpose ProcessFrontendResponse() is changed.
+
+ See bugtrack in detai.
+
+ #21 pgpool-II 3.2.0 cannot execute sql through jdbc
+ Date: 2012-08-17 16:31
+ Reporter: elisechiang
+ http://www.pgpool.net/mantisbt/view.php?id=21
+
+ - Fix to set unix domain socket path for pgpool PCP communication before
+ setting up signal handlers. (Yugo Nagata)
+
+ Previously, unlink of the socket in exitting process was failed because
+ the path of the socket was not set.
+ Patch contributed by Gilles Darold
+
+ [pgpool-hackers: 131] Found bug with watchdog resulting in pgpool
+ segmentation fault
+ From: Gilles Darold
+ Date: Thu, 13 Sep 2012 18:54:42 +0200
+ http://www.sraoss.jp/pipermail/pgpool-hackers/2012-September/000130.html
+
+ - Fix to output the message when, in watchdog, ifup/down or arping command
+ does not exist. (Yugo Nagata)
+
+ - Fix long standing problem with do_query(). (Tatsuo Ishii)
+
+ When 1) extended protocol used and 2)unnamed portal is used and 3) no
+ explicit transaction is used, user's unnamed portal is removed by Sync
+ message.
+ This is because Sync message closes transaction and unnamed portal is
+ removed. This leads to "portal "" does not exist" error.
+
+ Fix is, use "Flush" message instead of Sync. Main difference between
+ using Sync and Flush is, Flush does not return Ready for Query message.
+ So do_query() does not return until all expected responses are returned.
+ It seems the order of messages returned from backend is random, and
+ do_query () manages it by using state bits.
+
===============================================================================
3.2.0 (namameboshi) 2012/08/03
@@ -407,6 +988,309 @@
===============================================================================
3.1 Series (2011/09/08 - )
+===============================================================================
+
+ 3.1.6 (hatsuiboshi) 2013/2/8
+
+* Version 3.1.6
+
+ This is a bugfix release against pgpool-II 3.1.5
+
+ __________________________________________________________________
+
+* Bug fixes
+
+ - Fix race condition when using md5 authentication. (Tatsuo Ishii)
+
+ The file descriptor to pool_passwd is opened in pgpool main and pgpool
+ child inherits it. When concurrent connections try to authenticate md5
+ method, they call pool_get_passwd and seek the fd and cause random md5
+ auth failure because underlying fd is shared. Fix is, let individual
+ pgpool child open the file by calling pool_reopen_passwd_file.
+
+ Problem reported and analyzed by Jason Slagle in pgpool-general:1141.
+
+ [pgpool-general: 1141] Possible race condition in pool_get_passwd
+ From: Jason Slagle
+ Date: Sun, 28 Oct 2012 01:12:52 -0400
+ http://www.sraoss.jp/pipermail/pgpool-general/2012-October/001160.html
+
+ - Fix hung up while repeating pcp_attach_node and pcp_detatch_node
+ (Tatsuo Ishii)
+
+ When node status is changed by pcp_attach_node and pcp_detatch_node,
+ failover() sends SIGUSR1 to pcp_child process expecting it exits to
+ refresh node status. In this situation lots of pgpool children exit and
+ produce SIGCHLD as well. The SIGCHLD handler reaper() tries catch all
+ SIGCHLD but sometimes it fails depending on the system load and timing.
+ If SIGCHLD produced by pcp child is not caught, the process becomes
+ zombie and never restarted.
+
+ This problem is reported in bug track #32 (by oleg_myrk) etc.
+
+ #32 PGPool hangs on pcp_attach/detach
+ Reporter: oleg_myrk
+ $B!!(BDate: 2012-10-24 00:01
+ http://www.pgpool.net/mantisbt/view.php?id=32
+
+ - Fix pool_send_severity_message() not to use uninitialized memory.
+ (Tatsuo Ishii)
+
+ It cause a segmentaion fault.
+ Reported in Bug #33's attached valgrind output by dudee.
+
+ #33 pgpool-II 3.2.1 segfault
+ Reporter: dudee
+ Date: 2012-10-30 19:16
+ http://www.pgpool.net/mantisbt/view.php?id=33
+
+ - Add a description about "-f" to help message. (Tatsuo Ishii)
+
+ - Fix reaper() not to exit wait3() loop when catches pcp or worker child
+ exit event. (Tatsuo Ishii)
+
+ Otherwise reaper() mistakenly ignore some process exit event and make a
+ risk of creating zombie process and forgetting to create new process.
+
+ Problem reported and fix suggested by Goto in [pgpool-general-jp: 1123].
+ http://www.sraoss.jp/pipermail/pgpool-general-jp/2012-November/001122.html
+ (in Japanese)
+
+ - Fix pool_search_relcache() to use MASTER or MASTER_NODE_ID macro, rather
+ than REAL_MASTER_NODE_ID. (Tatsuo Ishii)
+
+ In case node 0 fail back in streaming replication mode, pgpool does not
+ restart child process. So REAL_MASTER_NODE_ID looks for node 0 con info,
+ which is not present until new connection to backend made. Thus referring
+ to node con info results in segfault. MASTER or MASTER_NODE_ID are safe in
+ this situation because they look at cached former master node id.
+
+ - Fix long standing bug "portal not found" error when replication delay
+ is too much in streaming replication mode. (Tatsuo Ishii)
+
+ The bug had been there since the delay threshold was introduced.
+
+ We changed destination DB node if delay threshold exceeds in bind,
+ describe and execute. However, if parse sends to different node, bind,
+ describe or execute will fail because no parsed statement or portal
+ exists. Solution is, not to send to different parse node even
+ if delay threshold is too much.
+
+ - Fix pg_md5 to output "\n" after user inputs password. (Yugo Nagata)
+
+ - Fix child_exit() to not call send_frontend_exits() if there's no
+ connection pool. (Tatsuo Ishii)
+
+ Otherwise, it segfaults because send_frontend_exits() referes to objects
+ pointed to by pool_connection_pool. Per bug track #44 by tuomas.
+
+ #44 pgpool went haywire after slave shutdown triggering master failover
+ Reporter: tuomas
+ Date: 2012-12-11 00:33
+ http://www.pgpool.net/mantisbt/view.php?id=4
+
+ - Fix read_startup_packet() to reset alarm and free StartupPacket when
+ pool_read() returns 0 which means incorrect packet length. (Nozomi Anzai)
+
+ Previously, authentication timeout occurs when connected by a program
+ monitoring the pgpool port.It is reported in bug track #35 by tuomas.
+
+ #35 Authentication is timeout
+ Reporter: tuomas
+ Date: 2012-11-20 11:54
+ http://www.pgpool.net/mantisbt/view.php?id=3
+
+ - Fix long standing bug with pool_open(). (Tatsuo Ishii)
+
+ It initializes wrong buffer pointer. Actually this is harmless because the
+ pointer is initialized by prior memset() call, though.
+
+ - Modify documents to correct information of whether a certain parameter
+ change requires restart. (Yugo Nagata)
+
+ - Add pool_passwd option to pgpool.conf.sample*, and documents. (Yugo Nagata)
+
+
+===============================================================================
+
+ 3.1.5 (hatsuiboshi) 2012/10/12
+
+* Version 3.1.5
+
+ This is a bugfix release against pgpool-II 3.1.4
+
+ __________________________________________________________________
+
+* Bug fixes
+
+ - Fix read_startup_packet. (Tatsuo Ishii)
+
+ If packet length is lower than 0, it should
+ have returned immediately. Otherwise it would cause memory allocation
+ error later on. per pgpool-general:886.
+ Also add canceling alarm.
+
+ - Add NOTICE message handling to s_do_auth. (Tatsuo Ishii)
+
+ Without this, health check responses false alarm and causes failover.
+ per bug track:
+ http://www.pgpool.net/mantisbt/view.php?id=25
+ Also allow to receive ready for query packet *not* right after backend
+ keydata. I'm not sure if this could happen in the real world but the
+ protocol seems to allow this.
+
+ - Remove unnecessary/confusing debug log from s_do_auth.(Tatsuo Ishii)
+
+ - Fix inifinit loop in SSL mode. When there's pending data in SSL layer
+ of frontend, pool_process_query() checks pending data in backend.
+ (Tatsuo Ishii)
+
+ If there's non, it loops again and checks frontend/backend receive buffer
+ by using is_cache_empty(). Unfortunately it first checks pending data
+ in SSL layer of frontend, thus goes to backend data and checks again
+ (infinite loop).
+ The solution is, if there's pending data in SSL layer of frontend and
+ query is not in progress, call ProcessFrontendResponse() to process new
+ request from frontend.
+
+ - Fix is_system_catalog to use pgpool_regclass if available.
+ (Tatsuo Ishii)
+
+ - Fix memory leak in pool_get_insert_table_name(). (Tatsuo Ishii)
+
+ If session context's memory contex is used for nodeToString(), memory is
+ not freed until session ends.
+
+ - Fix possible memory leak in nodeToString(). (Tatsuo Ishii)
+
+ Since the memory context could be session context, memory used for
+ String object may be considerable if user session continues for hours or
+ days.
+ See bug track #24 for more details.
+
+ - Fix long standing problem with do_query(). (Tatsuo Ishii)
+
+ When 1) extended protocol used and 2)unnamed portal is used and 3) no
+ explicit transaction is used, user's unnamed portal is removed by Sync
+ message.
+ This is because Sync message closes transaction and unnamed portal is
+ removed. This leads to "portal "" does not exist" error.
+
+ Fix is, use "Flush" message instead of Sync. Main difference between
+ using Sync and Flush is, Flush does not return Ready for Query message.
+ So do_query() does not return until all expected responses are returned.
+ It seems the order of messages returned from backend is random, and
+ do_query () manages it by using state bits.
+
+
+===============================================================================
+
+ 3.1.4 (hatsuiboshi) 2012/08/06
+
+* Version 3.1.4
+
+ This is a bugfix release against pgpool-II 3.1.3.
+
+ __________________________________________________________________
+
+* Bug fixes
+
+ * General
+
+ - Adopt PostgreSQL 9.2. (Tatsuo Ishii)
+
+ * Bug fixes
+
+ - Fix pool_send_and_wait() to send or not to send COMMIT / ABORT
+ depending on the transaction state on each node. (Tatsuo Ishii)
+
+ It is possible that only primary is in an explicit transaction but
+ standby is not in it if multi statement query has been sent.
+ Per bug report [pgpool-general-jp: 1049].
+
+ - Fix load balance in Solaris. (Tatsuo Ishii)
+
+ Problem is, random() in using random() in Solaris results in strange
+ load balancing calculation.
+ Use srand()/rand() instead although they produce lesser quality random
+ Problem reported at [pgpool-general: 396].
+
+ [pgpool-general: 396] strange load balancing issue in Solaris
+ http://www.pgpool.net/pipermail/pgpool-general/2012-April/000397.html
+
+ - Add params to the result of "SHOW pool_status": backend_data_directory,
+ ssl_ca_cert, ssl_ca_cert_dir. (Nozomi Anzai)
+
+ - Fix segfault of pcp_systemdb_info not in parallel mode. (Nozomi Anzai)
+
+ - Fix "unnamed prepared statment does not exist" error. (Tatsuo Ishii)
+
+ This is caused by pgpool's internal query, which breaks client's
+ unnamed statements. To fix this, if extended query is used, named
+ statement/portal for internal are used for internal query.
+
+ - Fix is_system_catalog(). Its relcach was accidently defined as
+ "session local". (Tatsuo Ishii)
+
+ - Fix hangup when query conflict occurs in Hot-Standby mode.
+ (Yugo Nagata)
+
+ Query example to reproduce:
+
+ (S1) BEGIN;
+ (S1) SELECT * FROM t;
+ (S2) DELETE FROM t;
+ (S2) VACUUM t;
+
+ - Improve reading and writing pid_file. (Tatsuo Ishii)
+
+ - Fix pool_process_query() bug reported in [pgpool-general: 672].
+ (Tatsuo Ishii)
+
+ This is caused by the function waits for primary node which does not
+ have pending data, while standbys have pending data.
+
+ [pgpool-general: 672] Transaction never finishes
+ http://www.pgpool.net/pipermail/pgpool-general/2012-June/000676.html
+
+ - 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.
+
+ - 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
+
===============================================================================
3.1.3 (hatsuiboshi) 2012/04/23
@@ -789,6 +1673,236 @@
===============================================================================
3.0 Series (2010/09/10 - )
+===============================================================================
+
+ 3.0.10 (hatsuiboshi) 2013/2/8
+
+* Version 3.0.10
+
+ This is a bugfix release against pgpool-II 3.0.9
+
+ __________________________________________________________________
+
+* Bug fixes
+
+ - Fix race condition when using md5 authentication. (Tatsuo Ishii)
+
+ The file descriptor to pool_passwd is opened in pgpool main and pgpool
+ child inherits it. When concurrent connections try to authenticate md5
+ method, they call pool_get_passwd and seek the fd and cause random md5
+ auth failure because underlying fd is shared. Fix is, let individual
+ pgpool child open the file by calling pool_reopen_passwd_file.
+
+ Problem reported and analyzed by Jason Slagle in pgpool-general:1141.
+
+ [pgpool-general: 1141] Possible race condition in pool_get_passwd
+ From: Jason Slagle
+ Date: Sun, 28 Oct 2012 01:12:52 -0400
+ http://www.sraoss.jp/pipermail/pgpool-general/2012-October/001160.html
+
+ - Fix pool_send_severity_message() not to use uninitialized memory.
+ (Tatsuo Ishii)
+
+ It cause a segmentaion fault.
+ Reported in Bug #33's attached valgrind output by dudee.
+
+ #33 pgpool-II 3.2.1 segfault
+ Reporter: dudee
+ Date: 2012-10-30 19:16
+ http://www.pgpool.net/mantisbt/view.php?id=33
+
+ - Fix reaper() not to exit wait3() loop when catches pcp or worker child
+ exit event. (Tatsuo Ishii)
+
+ Otherwise reaper() mistakenly ignore some process exit event and make a
+ risk of creating zombie process and forgetting to create new process.
+
+ Problem reported and fix suggested by Goto in [pgpool-general-jp: 1123].
+ http://www.sraoss.jp/pipermail/pgpool-general-jp/2012-November/001122.html
+ (in Japanese)
+
+ - Fix pool_search_relcache() to use MASTER or MASTER_NODE_ID macro, rather
+ than REAL_MASTER_NODE_ID. (Tatsuo Ishii)
+
+ In case node 0 fail back in streaming replication mode, pgpool does not
+ restart child process. So REAL_MASTER_NODE_ID looks for node 0 con info,
+ which is not present until new connection to backend made. Thus referring
+ to node con info results in segfault. MASTER or MASTER_NODE_ID are safe in
+ this situation because they look at cached former master node id.
+
+ - Fix long standing bug "portal not found" error when replication delay
+ is too much in streaming replication mode. (Tatsuo Ishii)
+
+ The bug had been there since the delay threshold was introduced.
+
+ We changed destination DB node if delay threshold exceeds in bind,
+ describe and execute. However, if parse sends to different node, bind,
+ describe or execute will fail because no parsed statement or portal
+ exists. Solution is, not to send to different parse node even
+ if delay threshold is too much.
+
+ - Fix pg_md5 to output "\n" after user inputs password. (Yugo Nagata)
+
+ - Fix child_exit() to not call send_frontend_exits() if there's no
+ connection pool. (Tatsuo Ishii)
+
+ Otherwise, it segfaults because send_frontend_exits() referes to objects
+ pointed to by pool_connection_pool. Per bug track #44 by tuomas.
+
+ #44 pgpool went haywire after slave shutdown triggering master failover
+ Reporter: tuomas
+ Date: 2012-12-11 00:33
+ http://www.pgpool.net/mantisbt/view.php?id=44
+
+ - Fix read_startup_packet() to reset alarm and free StartupPacket when
+ pool_read() returns 0 which means incorrect packet length. (Nozomi Anzai)
+
+ Previously, authentication timeout occurs when connected by a program
+ monitoring the pgpool port.It is reported in bug track #35 by tuomas.
+
+ #35 Authentication is timeout
+ Reporter: tuomas
+ Date: 2012-11-20 11:54
+ http://www.pgpool.net/mantisbt/view.php?id=35
+
+ - Fix long standing bug with pool_open(). (Tatsuo Ishii)
+
+ It initializes wrong buffer pointer. Actually this is harmless because the
+ pointer is initialized by prior memset() call, though.
+
+ - Add a description about "-f" to help message. (Tatsuo Ishii)
+
+ - Modify documents to correct information of whether a certain parameter
+ change requires restart. (Yugo Nagata)
+
+ - Add pool_passwd option to pgpool.conf.sample*, and documents. (Yugo Nagata)
+
+===============================================================================
+
+ 3.0.9 (hatsuiboshi) 2012/10/12
+
+* Version 3.0.9
+
+ This is a bugfix release against pgpool-II 3.0.8
+
+ __________________________________________________________________
+
+* Bug fixes
+
+ - Fix read_startup_packet. (Tatsuo Ishii)
+
+ If packet length is lower than 0, it should
+ have returned immediately. Otherwise it would cause memory allocation
+ error later on. per pgpool-general:886.
+ Also add canceling alarm.
+
+ - Add NOTICE message handling to s_do_auth. (Tatsuo Ishii)
+
+ Without this, health check responses false alarm and causes failover.
+ per bug track:
+ http://www.pgpool.net/mantisbt/view.php?id=25
+ Also allow to receive ready for query packet *not* right after backend
+ keydata. I'm not sure if this could happen in the real world but the
+ protocol seems to allow this.
+
+ - Remove unnecessary/confusing debug log from s_do_auth.(Tatsuo Ishii)
+
+ - Fix inifinit loop in SSL mode. When there's pending data in SSL layer
+ of frontend, pool_process_query() checks pending data in backend.
+ (Tatsuo Ishii)
+
+ If there's non, it loops again and checks frontend/backend receive buffer
+ by using is_cache_empty(). Unfortunately it first checks pending data
+ in SSL layer of frontend, thus goes to backend data and checks again
+ (infinite loop).
+ The solution is, if there's pending data in SSL layer of frontend and
+ query is not in progress, call ProcessFrontendResponse() to process new
+ request from frontend.
+
+ - Fix is_system_catalog to use pgpool_regclass if available.
+ (Tatsuo Ishii)
+
+ - Fix memory leak in pool_get_insert_table_name(). (Tatsuo Ishii)
+
+ If session context's memory contex is used for nodeToString(), memory is
+ not freed until session ends.
+
+ - Fix possible memory leak in nodeToString(). (Tatsuo Ishii)
+
+ Since the memory context could be session context, memory used for
+ String object may be considerable if user session continues for hours or
+ days.
+ See bug track #24 for more details.
+
+ - Fix long standing problem with do_query(). (Tatsuo Ishii)
+
+ When 1) extended protocol used and 2)unnamed portal is used and 3) no
+ explicit transaction is used, user's unnamed portal is removed by Sync
+ message.
+ This is because Sync message closes transaction and unnamed portal is
+ removed. This leads to "portal "" does not exist" error.
+
+ Fix is, use "Flush" message instead of Sync. Main difference between
+ using Sync and Flush is, Flush does not return Ready for Query message.
+ So do_query() does not return until all expected responses are returned.
+ It seems the order of messages returned from backend is random, and
+ do_query () manages it by using state bits.
+
+===============================================================================
+
+ 3.0.8 (umiyameboshi) 2012/08/0
+
+* Version 3.0.8
+
+ This is a bugfix release against pgpool-II 3.0.7
+
+ __________________________________________________________________
+
+* Bug fixes
+
+ * General
+
+ - Adopt PostgreSQL 9.2. (Tatsuo Ishii)
+
+ * Bug fixes
+
+ - Fix load balance in Solaris. (Tatsuo Ishii)
+
+ Problem is, random() in using random() in Solaris results in strange
+ load balancing calculation.
+ Use srand()/rand() instead although they produce lesser quality random
+ Problem reported at [pgpool-general: 396].
+
+ [pgpool-general: 396] strange load balancing issue in Solaris
+ http://www.pgpool.net/pipermail/pgpool-general/2012-April/000397.html
+
+ - Fix segfault of pcp_systemdb_info not in parallel mode. (Nozomi Anzai)
+
+ - Fix "unnamed prepared statment does not exist" error. (Tatsuo Ishii)
+
+ This is caused by pgpool's internal query, which breaks client's
+ unnamed statements. To fix this, if extended query is used, named
+ statement/portal for internal are used for internal query.
+
+ - Fix is_system_catalog(). Its relcach was accidently defined as
+ "session local". (Tatsuo Ishii)
+
+ - Improve reading and writing pid_file. (Tatsuo Ishii)
+
+ - Fix pool_process_query() bug reported in [pgpool-general: 672].
+ (Tatsuo Ishii)
+
+ This is caused by the function waits for primary node which does not
+ have pending data, while standbys have pending data.
+
+ [pgpool-general: 672] Transaction never finishes
+ http://www.pgpool.net/pipermail/pgpool-general/2012-June/000676.html
+
+ - 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.
+
===============================================================================
3.0.7 (umiyameboshi) 2012/04/23
@@ -1270,6 +2384,93 @@
===============================================================================
2.3 Series (2009/12/07 - 2010/02/22)
+===============================================================================
+
+ 2.3.4 (tomiteboshi) 2012/08/06
+
+* Version 2.3.4
+
+ This version fixes various bugs since 2.3.3.
+
+ __________________________________________________________________
+
+* Bug fixes
+
+ - Fix do_error_execute_command() so that it discards responses from
+ backend until ErrorResponse received. (Toshihiro Kitagawa)
+
+ Note that we need to preserve non-error responses (i.e. ReadyForQuery)
+ and put back them using pool_unread().
+ Otherwise, ReadyForQuery response of DEALLOCATE. This could happen if
+ PHP PDO used.
+
+ - Fix SimpleForwardToFrontend() so that it reset select_in_transaction
+ flag and execute_select flag when bind error occurred while executing
+ SELECT. (Toshihiro Kitagawa)
+
+ - Fix SSL connection sometimes hung if lots of data read from backend.
+ This is caused by the buffering in OpenSSL layer. To fix the problem,
+ (Tatsuo Ishii)
+
+ we check the buffer has any pending data by using SSL_pending() before
+ calling select(2).
+ See thread [Pgpool-general] Fwd: PGPOOL II 2.3.3 hang in ssl mode for
+ more details.
+
+ - Fix bug with pcp_check_fd()'s timeout handling. (Tatsuo Ishii)
+
+ Per erboles.
+ Subject: [Pgpool-general] question about pcp_check_fd
+ Date: Sun, 23 May 2010 18:21:41 -0500
+ To: pgpool <pgpool-general@pgfoundry.org>
+
+ - Do not force replication of DEALLOCATE if operated in master/slave mode.
+ Reported by Jan Kantert. (Toshihiro Kitagawa)
+
+ See:
+ Subject: [Pgpool-hackers] Problems with PgPool 2.3.3 Prepare /
+ Deallocation handling in Master/Slave mode
+ Date: Fri, 28 May 2010 20:59:47 +0200
+ For more details.
+
+ - Make timestamp rewriting schema aware. (Tatsuo Ishii)
+
+ - Do not rewrite statement which accesses columns having now() etc. as the
+ default value but the data type are not timestamp etc. (Tatsuo Ishii)
+
+ Otherwise we have an error in DMLS. See:
+ Subject: [Pgpool-general] function epoch seems to be causing error
+ To: pgpool-general@pgfoundry.org
+ Date: Mon, 16 Aug 2010 21:48:31 +0000 (UTC)
+ For more details.
+
+ - Fix insert_lock to be schema aware. (Tatsuo Ishii)
+
+ - Fix long standing bug with timestamp rewriting against array and complex
+ types. (Tatsuo Ishii)
+
+
+ Failed examples are:
+
+ INSERT INTO r1(col[1], col2.foo) VALUES (1, 2); -- insert_column_item
+ UPDATE r1 SET col1[1] = 1, col2.foo = 1; -- set_target
+ PREPARE "p" (int4[]) AS SELECT $1[1]; -- c_expr
+ SELECT (ARRAY[1,2,3])[1];
+ SELECT (ARRAY[ARRAY[1]])[1][1];
+ SELECT ('{1,2,3}'::int[])[1];
+ SELECT ('{1,2,3}'::int[3])[1];
+ SELECT r1.col[1], (r1.col1).bar, (r1.col1).* FROM r1; -- columnref
+ SELECT (r1.col1).baz[1], (r1.col1).baz[1][2] FROM r1;
+
+ Patch provided by Akio Ishida.
+
+ - Fix buffer overrun problem when pcp password is longer than 32.
+ (Tatsuo Ishii)
+
+ - Fix wait_for_query_response() not to send param status to frontend if
+ frontend is NULL. This could happen while processing reset_query_list.
+ (Tatsuo Ishii)
+
===============================================================================
2.3.3 (tomiteboshi) 2010/04/23
@@ -1562,6 +2763,44 @@
===============================================================================
2.2 Series (2009/02/08 - 2010/04/15)
+===============================================================================
+
+ 2.2.8 (urukiboshi) 2012/08/06
+
+* Version 2.2.8
+
+ It includes various fixes for bugs various bug fixes in 2.2.7.
+
+ __________________________________________________________________
+
+* Bug fixes
+
+ - Fix do_error_execute_command() so that it discards responses from
+ backend until ErrorResponse received. (Toshihiro Kitagawa)
+
+ Note that we need to preserve non-error responses (i.e. ReadyForQuery)
+ and put back them using pool_unread().
+ Otherwise, ReadyForQuery response of DEALLOCATE. This could happen if
+ PHP PDO used.
+
+ - Fix SimpleForwardToFrontend() so that it reset select_in_transaction
+ flag and execute_select flag when bind error occurred while executing
+ SELECT. (Toshihiro Kitagawa)
+
+ - Fix bug with pcp_check_fd()'s timeout handling. (Tatsuo Ishii)
+
+ Per erboles.
+ Subject: [Pgpool-general] question about pcp_check_fd
+ Date: Sun, 23 May 2010 18:21:41 -0500
+ To: pgpool <pgpool-general@pgfoundry.org>
+
+ - Fix buffer overrun problem when pcp password is longer than 32.
+ (Tatsuo Ishii)
+
+ - Fix wait_for_query_response() not to send param status to frontend if
+ frontend is NULL. This could happen while processing reset_query_list.
+ (Tatsuo Ishii)
+
===============================================================================
2.2.7 (urukiboshi) 2010/04/15
diff --git a/doc/pgpool-ja.html b/doc/pgpool-ja.html
index a207a995b..686e59e7e 100644
--- a/doc/pgpool-ja.html
+++ b/doc/pgpool-ja.html
@@ -8,7 +8,7 @@
<body>
<!-- hhmts start -->
-Last modified: Thu Jan 31 08:10:02 JST 2013
+Last modified: Fri Feb 8 11:10:02 JST 2013
<!-- hhmts end -->
<body bgcolor="#ffffff">
@@ -1770,7 +1770,7 @@ SELECTなどの問い合わせがロードバランスされます。
</p>
<ul>
<li>PostgreSQLのバージョンが7.4以降である</li>
- <li>レプリケーションモードまたはマスタースレーブモードである</li>
+ <li>レプリケーションモードまたはマスタースレーブモードである</li>
<li>問い合わせが明示的なトランクザションブロックの内側にない(つまり、BEGINを発行していない)</li>
<li>SELECT文(WITH付も含む。<a href="#BLACK_FUNCTION_LIST">black_list</a> または
<a href="#WHITE_FUNCTION_LIST">white_list</a> で指定された書き込みを含むSELECTを除く)
@@ -1778,17 +1778,17 @@ SELECTなどの問い合わせがロードバランスされます。
<li>SELECT INTO 文ではない</li>
<li>SELECT FOR UPDATE/SELECT FOR SHARE文ではない</li>
<li>クエリ文字列が SELECTまたはWITH で始まる(ignore_leading_white_space = trueの場合は空白は無視します)</li>
- <li>マスタースレーブモードの場合、更に以下の条件が満たされなければなりません。<span class="version">V3.0 -</span></li>
- <ul>
- <li>一時テーブルを使っていない</li>
- <li>unloggedテーブルを使っていない</li>
- <li>システムカタログを使っていない</li>
- <li>トランザクションブロックの内側であっても上記条件と下記条件を満たせばロードバランスされます。</li>
- <ul>
- <li>トランザクション分離レベルがSERIALIZABLEでない</li>
- <li>トランザクション内で更新を伴うクエリが実行されていない(更新を伴うクエリが実行されるまではロードバランスされます)</li>
- </ul>
- </ul>
+ <li>マスタースレーブモードの場合、更に以下の条件が満たされなければなりません。<span class="version">V3.0 -</span></li>
+ <ul>
+ <li>一時テーブルを使っていない</li>
+ <li>unloggedテーブルを使っていない</li>
+ <li>システムカタログを使っていない</li>
+ <li>トランザクションブロックの内側であっても上記条件と下記条件を満たせばロードバランスされます。</li>
+ <ul>
+ <li>トランザクション分離レベルがSERIALIZABLEでない</li>
+ <li>トランザクション内で更新を伴うクエリが実行されていない(更新を伴うクエリが実行されるまではロードバランスされます)</li>
+ </ul>
+ </ul>
</ul>
<p>
(<a href="#replicate_select">replicate_selectの項目</a>も参考にしてください)
@@ -4063,31 +4063,8 @@ pgpoolが生きていて PostgreSQLと繋がっている場合でも、
</p>
</dd>
-<dt><a name="WD_LIFECHECK_DBNAME"></a>wd_lifecheck_dbname <span class="version">V3.3 ～</span></dt>
- <dd>
- <p>
- pgpool-II の死活監視で接続するデータベースです。
- デフォルトは "template1" です。
- </p>
- </dd>
-
-<dt><a name="WD_LIFECHECK_USER"></a>wd_lifecheck_user <span class="version">V3.3 ～</span></dt>
- <dd>
- <p>
- pgpool-II の死活監視を行うユーザです。
- デフォルトは "nobody" です。
- </p>
- </dd>
</dl>
-<dt><a name="WD_LIFECHECK_PASSWORD"></a>wd_lifecheck_password <span class="version">V3.3 ～</span></dt>
- <dd>
- <p>
- pgpool-II の死活監視を行うユーザのパスワードです。
- デフォルトは "" です。
- </p>
- </dd>
-
<h4>仮想 IP</h4>
<dl>
@@ -5439,215 +5416,910 @@ SELECTの最終実行ステータスとパフォーマンスのおおよその
<h1 id="release">リリースノート</h1>
-<h2><a name="release3.2.0"></a>3.2.0 (namameboshi) 2012/08/03</h2>
+<h2><a name="release3.2.3"></a>3.2.3 (namameboshi) 2013/2/18</h2>
<h3>概要</h3>
-<p>
-このバージョンは 3.2 系列の最初の版で、3.1 系からの「メジャーバージョンアップ」にあたります。
+<p>pgpool-II 3.2.2 に対するバグ修正リリースです。
+ おもに、3.2.2 のヘルスチェックに関する致命的な問題を修正するものです。</p>
+<p>以下の条件がすべて満たされたとき、フェイルオーバ発生時に pgpool のメインプロセスが消滅し、
+ pgpool-II へのクライアントの接続がすべてハングします。
+ また、その状態から復帰するには、pgpool の子プロセスを手動で kill し、pgpool-II を
+ 再起動するしかありませんでした。</p>
+ <ul>
+ <li>ヘルスチェックが有効である。 </li>
+ <li>PostgreSQL への接続を、UNIX ドメインソケットではなく TCP/IP で行なっている
+ （※ pgpool.conf のバックエンドノード設定において "backend_hostnameN" が空欄でない）。</li>
+ </ul>
</p>
-<h3>互換性のない変更</h3>
-
-<ul>
-<li>メモリベースのメモリキャッシュ機能を追加したため、旧来のメモリキャッシュ機能は削除しました。
- <ul>
- <li>これにともない、enable_query_cache パラメータを削除しました。</li>
- </ul>
-</li>
-</ul>
-
-<h3 id="3.2_new_feartures">新機能</h3>
-
+<h3>バグ修正</h3>
<ul>
-<li><a href="#memqcache">メモリベースのクエリキャッシュ</a>を追加しました。
- (Tatsuo Ishii, Nozomi Anzai, Yugo Nagata)
-<p>オリジナルは Masanori Yamazaki さんが作成し、開発グループで改良しました。</p>
-
-<dl>
-<dt>概要</dt>
+<li><a href="#322_bugfix_connect">3.2.2</a> で入り込んだ connect_inet_domain_socket_by_port() の
+ バグを修正しました。 (Tatsuo Ishii)
<p>
- メモリ上にキャッシュが置かれるので高速であるばかりでなく、データが更新されると自動的にキャッシュが無効になり、
- pgpool-II の再起動の必要がありません。
+ 接続において non blocking の connect() が EINPROGRESS や EALREADY という結果を返したときには、
+ select(2) を呼んで read / write ファイルディスクリプタの準備されるまで待つようにしました。
</p>
<p>
- オンメモリクエリキャッシュは、問い合わせの SELECT 文(拡張問い合わせの場合は更にバインドパラメータ)と
- 検索結果をペアで記録し、2 回目以降に同じ SELECT 文が発行された場合に、キャッシュから結果を返します。
- 通常の SELECT 文処理と違って、PostgreSQL にアクセスしないだけでなく、
- pgpool 内部の SQL パース処理などを経由しないため、非常に高速です。
+ 本来は select() が 0 以上を返したときにそうするべきところを、0 を返したときだけになっていました。
+ その結果、connect_inet_domain_socket_by_port() が実際には失敗しているのに
+ 成功していたと誤って返していました。
</p>
<p>
- 反面、キャッシュにヒットしない場合は通常の SELECT 文の処理に加えてキャッシュ処理のオーバヘッドが生じるので、
- かえって遅くなります。また、あるテーブルが更新された場合、そのテーブルを参照している
- すべてのキャッシュが自動削除されるため（自動削除しない設定も可能）、
- 更新処理が多いシステムではオンメモリクエリキャッシュを有効にしていることでかえって遅くなります。
- キャッシュのヒット率が 70% 以下の場合は、オンメモリクエリキャッシュの設定を有効にしないほうが良いでしょう。
+ またさらに、これによって health_check() がバックエンドが生きているものと誤認し、
+ バックエンドソケットに書き込みを行なおうとし、失敗していました。
+ これをトリガに notice_backend_error() が呼ばれ、SIGUSR1 シグナルが pgpool のメインプロセスの
+ 親プロセスに送られます。
+ その結果、pgpool をシェルから起動していれば、シェルを kill する、ということになります。
</p>
+ <p>
+ pgpool をバックグラウンドで起動していれば #1 プロセスを kill します。
+ これは、pgpool を root として起動していなければ問題ありません。
+ もっとも root として起動していても、SIGUSR1 を受け取って /dev/initctl を再度 open するだけなので、
+ 実際に問題はありません。
+ </p>
+ <p>
+ これらの困った問題は pgpool が誕生した時点から存在していましたが、
+ connect_inet_domain_socket_by_port() のバグによって表面化しました。
+ 修正には、notice_backend_error() と child_exit() を変更し、
+ pgpool のメインプロセス自体から呼ばれたときには、自分自身を kill しないように、何も行なわないようにしました。
+ </p>
+</li>
-<dt>キャッシュストレージの選択</dt>
- <dd>
- <p>
- メモリキャッシュのストレージには、共有メモリと memcached のどちらかを選択することができます
- （併用はできません）。
- </p>
- <ul>
- <li>共有メモリを使用するクエリキャッシュは高速で、memcached の立ち上げも必要なく、手軽に利用できます。
- ただし、共有メモリサイズの上限によって保存できるキャッシュの量に制限があります。
- </li>
- <li>memcached をキャッシュストレージに使用する場合は、ネットワークアクセスのオーバヘッドがあるものの、
- 比較的自由にキャッシュメモリの大きさを設定できます。
- </li>
- </ul>
- </dd>
-
-<dt>制限事項</dt>
- <dd>
- <ul>
- <li>
- オンメモリクエリキャッシュでは、テーブルに変更があると、関連するキャッシュを自動的に削除して
- 古いデータが返却されないようにする機能があります。
- このため、pgpool は常に UPDATE や INSERT や ALTER TABLE などのコマンドが発行されたかどうかを
- モニタしています。<br>
- しかし、トリガ、外部キーや DROP TABLE CASCADE などの働きによって暗黙的にテーブルが更新されたことは
- pgpool-II からはわからないため、この機能が働きません。<br>
- この問題を回避するためには、 memqcache_expire を使って一定時間経過したキャッシュを削除するようにするか、
- <a href="#BLACK_MEMQCACHE_TABLE_LIST">black_memqcache_table_list</a> を使って、該当テーブルが
- キャッシュされないようにしてください。
- </li>
+<li>設定パラメータの一覧を表示する "<a href="#pool_status">SHOW pool_status</a>" で
+ <a href="#POOL_PASSWD">pool_passwd</a> が表示されていないのを修正しました。(Yugo Nagata)</li>
- <li>
- 複数の pgpool-II を動かす環境で共有メモリを使ったオンメモリクエリキャッシュを使用すると、
- ある pgpool-II 経由でテーブルが更新された時に、他の pgpool-II のキャッシュが削除されず、
- 古いデータを読みだしてしまうことがあります。<br>
- このような環境では、キャッシュストレージに memcached を使ってください。
- </li>
- </ul>
- </dd>
+<li>configure.in にある configure のヘルプの typo を修正しました。 (Yugo Nagata)</li>
+</ul>
-<dt>新しいパラメータ</dt>
- <dd>
- <ul>
- <li>メモリキャッシュ全般に関するパラメータ
- <a href="#MEMORY_CACHE_ENABLED">memory_cache_enabled</a>、
- <a href="#MEMQCACHE_METHOD">memqcache_method</a>、
- <a href="#MEMQCACHE_EXPIRE">memqcache_expire</a>、
- <a href="#MEMQCACHE_MAXCACHE">memqcache_maxcache</a>、
- <a href="#MEMQCACHE_OIDDIR">memqcache_oiddir</a> を追加しました。(Tatsuo Ishii)</li>
+<h2><a name="release3.2.2"></a>3.2.2 (namameboshi) 2013/2/8</h2>
+<h3>概要</h3>
+<p>
+このバージョンは 3.2.1 に対するバグ修正リリースです。
+</p>
+<h3>バグ修正</h3>
+<ul>
+<li>FreeBSD で発生するコンパイルエラーを修正しました。 (Tatsuo Ishii)</li>
- <li>共有メモリを使ったメモリキャッシュに関するパラメータ
- <a href="#MEMQCACHE_TOTAL_SIZE">memqcache_total_size</a>、
- <a href="#MEMQCACHE_MAX_NUM_CACHE">memqcache_max_num_cache</a>、
- <a href="#MEMQCACHE_CACHE_BLOCK_SIZE">memqcache_cache_block_size</a> を追加しました。
- (Tatsuo Ishii)</li>
+<li>デフォルトのスキーマ（通常は public）以外で作られたビューが認識
+ されていなかったバグを修正しました。(Tatsuo Ishii)
+<p>
+ このバグのため、本来キャッシュされるべきでない、該当するビューのクエリ結果がキャッシュされていました。
+</p>
+<p>
+ この問題はバグトラック #30 で jgentsch さんによって報告され、パッチを提供頂きました。
+</p>
+<blockquote>
+ #30 pgpool 3.2.1 - views in schema other than public are caching<br />
+ Reporter: jgentsch<br />
+ Date: 2012-10-19 23:13<br />
+ <a href="http://www.pgpool.net/mantisbt/view.php?id=30">
+ http://www.pgpool.net/mantisbt/view.php?id=30</a>
+</blockquote>
+</li>
- <li>memcached を使ったメモリキャッシュに関するパラメータ
- <a href="#MEMQCACHE_MEMCACHED_HOST">memqcache_memcached_host</a>、
- <a href="#MEMQCACHE_MEMCACHED_PORT">memqcache_memcached_port</a> を追加しました。
- (Tatsuo Ishii)
- </li>
+<li>md5 認証で競合が発生する不具合が修正されました。(Tatsuo Ishii)
+<p>
+ pool_passwd のファイル識別子は pgpool の親プロセスで開かれたものが子プロセス
+ に引き継がれてます。複数の接続で同時に md5 認証を行う際には、pool_get_passwd が呼ばれ、
+ ファイル識別子が走査されますが、ファイル識別子が共有されるために md5 認証が
+ 失敗することがありました。この問題は、個々の子プロセスで pool_passwd ファイルを
+ 開き直すことで解決されました。
+</p>
+<p>
+ この問題は [pgpool-general:1141] にて、Jason Slagle さんによって報告・解析されました。
+</p>
+<blockquote>
+ [pgpool-general: 1141] Possible race condition in pool_get_passwd<br />
+ From: Jason Slagle<br />
+ Date: Sun, 28 Oct 2012 01:12:52 -0400<br />
+ <a href="http://www.sraoss.jp/pipermail/pgpool-general/2012-October/001160.html">
+ http://www.sraoss.jp/pipermail/pgpool-general/2012-October/001160.html</a>
+</blockquote>
+</li>
- <li>リレーションキャッシュに関するパラメータ
- <a href="#RELCACHE_EXPIRE">relcache_expire</a>、
- <a href="#RELCACHE_SIZE">relcache_size</a> を追加しました。(Tatsuo Ishii)</li>
+<li>ロードバランスの条件について、より詳しい情報をマニュアルに追記しました。 (Tatso Ishii)</li>
- <li>一時テーブルかどうかをチェックするフラグ <a href="#CHECK_TEMP_TABLE">check_temp_table</a> パラメータを
- 追加しました。(Tatsuo Ishii)
- </li>
+<li>オンメモリクエリキャッシュ使用時に発生するセグメンテーションフォルトを修正しました。
+ これはキャッシュアレイの処理のバグが原因です。 (Tatsuo Isii)
+<p>
+ トランザクション中の一時キャッシュの結果を保持するためにキャッシュアレイ使用されます。
+ １つのトランザクションに 128 以上の SELECT がある場合には、キャッシュアレイの領域が
+ realloc を用いて拡張されます。しかし、その時に返却される新しいポインタではなく、
+ 古いポインタが使われ続けていました。
+</p>
+<p>
+ この問題はバグトラック #31 にて jgentsch さんによって報告されました。
+</p>
+<blockquote>
+ #31 pgpool V3_2_STABLE - segfault in pool_memqcache.c:2529<br />
+ Reporter:jgentsch<br />
+ Date: 2012-10-23 06:25<br />
+ <a href="http://www.pgpool.net/mantisbt/view.php?id=31">
+ http://www.pgpool.net/mantisbt/view.php?id=31</a>
+</blockquote>
+</li>
- <li>テーブル、一時テーブル、ビューのキャッシュ可否を指定するパラメータ、
- <a href="#WHITE_MEMQCACHE_TABLE_LIST">white_memqcache_table_list</a>、
- <a href="#BLACK_MEMQCACHE_TABLE_LIST">black_memqcache_table_list</a> を追加しました。
- (Nozomi Anzai)</li>
+<li>pcp_attach_node, pcp_detach_node を繰り返し実行したときに起こるハングアップを
+ 修正しました。 (Tatsuo Ishii)
+<p>
+ pcp_attach_node, pap_detach_node によりノードステータスが変更された時、failover()
+ は子プロセスに SIGUSR1 シグナルを送り、プロセスの終了とノードステータスの更新を行います。
+ その時に発せられた SIGCHLD シグナルは全て reaper() ハンドラで受信しますが、システムの
+ 負荷とタイミングによりこれが失敗することがありました。pcp プロセスによる SIGCHLD シグナルの
+ 受信に失敗した場合に、これがゾンビプロセスとなり、pcp プロセスが永遠に再起動されなくなって
+ いました。
+</p>
+<p>
+ この問題はバグトラック #32（oleg_myrk さんによる）他で報告されました。
+</p>
+<blockquote>
+ #32 PGPool hangs on pcp_attach/detach<br />
+ Reporter: oleg_myrk<br />
+ Date: 2012-10-24 00:01<br />
+ <a href="http://www.pgpool.net/mantisbt/view.php?id=32">
+ http://www.pgpool.net/mantisbt/view.php?id=32</a>
+</blockquote>
+</li>
- <li><a href="#MEMQCACHE_AUTO_CACHE_INVALIDATION">memqcache_auto_cache_invalidation</a>
- パラメータを追加しました。(Yugo Nagata)
- <p>
- true であれば、DDL/DML/DCL が発行されたら <a href="#MEMQCACHE_EXPIRE">memqcache_expire</a> を待たずに
- クエリキャッシュを削除します。
- </p>
- </li>
+<li>pool_send_severity_message() で未初期化のメモリを使用しないよう修正しました。
+ (Tatsuo Ishii)
+<p>
+ このバグによりセグメンテーション違反が発生することがありました。
+ バグトラック #33 に投稿された valgrind 実行結果（dudee さんによる）にて報告されました。
+</p>
+<blockquote>
+ #33 pgpool-II 3.2.1 segfault<br />
+ Reporter: dudee<br />
+ Date: 2012-10-30 19:16<br />
+ <a href="http://www.pgpool.net/mantisbt/view.php?id=33">
+ http://www.pgpool.net/mantisbt/view.php?id=33</a>
+</blockquote>
+</li>
- <li><a href="#pool_cache">SHOW pool_cache</a> を追加しました。クエリキャッシュのヒット率や、
- キャッシュストレージの状況を表示します。(Tatsuo Ishii)</li>
+<li>通常のテーブルと同名の一時テーブルがあるときに、クエリキャッシュの結果が不正になる
+ バグを修正しました。 (Tatsuo Ishii)
+<p>
+ 以下はバグを引き起こす処理の例です。
+</p>
+<pre>
+ 1) CREATE TABLE t1(i int); -- 通常のテーブルを作成
+ 2) INSERT INTO t1 VALUES(1);
+ 3) SELECT * FROM t1; -- クエリキャッシュが作成される
+ 4) CREATE TEMP TABLE t1(i int); -- 一時テーブルの作成
+ 5) SELECT * FROM t1; -- 誤ったクエリキャッシュが作成される!
+</pre>
+<p>
+ #3 で t1 のキャッシュが生成されますが、#5 でこれが不正に使われており、一時テーブル t1 が
+ 一時テーブルと見なされていないのが問題でした。
+</p>
+</li>
- <li><a href="#install">configure</a> に --with-memcached オプションを追加しました。(Tatsuo Ishii)</li>
+<li>ヘルプメッセージに -f オプションの説明を追加しました。 (Tatsuo Ishii)</li>
- <li><a href="#start">pgpool コマンド</a> に "-C, --clear-oidmaps" オプションを追加しました。
- (Nozomi Anzai)
- <p>
- memcached を使ったメモリキャッシュを行なっている pgpool が -C つきで起動・再起動したときは、
- oid マップを削除せず再利用します。
- </p>
- </li>
- </ul>
- </dd>
- </dl>
+<li>pcp または worker 子プロセスの終了イベントを受信したときに、reaper() で wait3()
+ ループを終了しないように修正しました。 (Tatsuo Ishii)
+<p>
+ 修正前は、reaper() は子プロセスの終了イベントを誤って無視してしまい、ゾンビプロセスを作り、
+ 新しいプロセスを生成できないことがありました。
+</p>
+<p>
+ この問題は[pgpool-general-jp: 1123]にて、後藤さんより報告され、修正の示唆を頂きました。
+</p>
+<blockquote>
+ [pgpool-general-jp: 1123] Re: オンラインリカバリ後にゾンビプロセスになる<br />
+ From: GOTO, Daisuke<br />
+ Date: Wed, 21 Nov 2012 19:56:17 +0900<br />
+ <a href="http://www.sraoss.jp/pipermail/pgpool-general-jp/2012-November/001122.html">
+ http://www.sraoss.jp/pipermail/pgpool-general-jp/2012-November/001122.html</a>
+</blockquote>
</li>
-<li><a href="#watchdog">Watchdog 機能</a> を追加しました。(Atsushi Mitani, Yugo Nagata)
-<p>Atsushi Mitani が作成し、Yugo Nagata がテストしました。</p>
-
-<dl>
-<dt>概要</dt>
- <dd>
- <p>
- watchdog プロセスは pgpool-II 本体から起動される、高可用性を目的としたプロセスです。以下の機能を提供します。
- </p>
+<li>configure のヘルプメッセージの typo を修正しました。 (Yugo Nagata)</li>
- <dl>
- <dt>pgpool サービスの死活監視</dt>
- <dd>
- <p>
- watchdog は、pgpool のプロセスではなくサービスの応答を監視します。
- 監視対象の pgpool から PostgreSQL に問い合わせを行ない、その応答をチェックします。
- </p>
- <p>
- また watchdog は、pgpool から上位のサーバ（アプリケーションサーバなど）への接続も監視します。
- 上位サーバから PostgreSQL への接続・応答を pgpool のサービスとして死活監視します。
- </p>
- </dd>
+<li>wd_hostname を pool_process_reporting.c に追加しました。 (Yugo Nagata)
+<p>
+ 以前は SHOW pool_status, pcp_pool_status の結果に wd_hostname が出力されていませんでした。
+</p>
+</li>
- <dt>watchdog プロセスの相互監視</dt>
- <dd>
- <p>
- 各 watchdog はお互いの監視対象のサーバの情報を交換します。
- これにより、pgpool サーバの情報を最新に保てるだけでなく、
- 各 watchdog プロセスの相互 監視を行なっています。
- </p>
- </dd>
+<li>connect(2) が EISCONN（ソケットが接続済み）エラーを返したときには、
+ connect_inet_domain_socket_by_port() はエラーを出力しないよう修正しました。
+ (Tatsuo Ishii)
+<p>
+ これはノンブロッキングソケットでは起こり得る、正常のこととして扱われるべきです。
+ バグトラック #29 （by spork）と pgpool-general 1218（by Mikola Rose）で報告されました。
+</p>
+<blockquote>
+ #29 pgpool 3.2.1 cannot connect to db hosts<br />
+ Reporter: spork<br />
+ Date: 2012-10-18 15:03<br />
+ <a href="http://www.pgpool.net/mantisbt/view.php?id=29">
+ http://www.pgpool.net/mantisbt/view.php?id=29</a>
+</blockquote>
+<blockquote>
+ [pgpool-general: 1218] pgpool 3.2.1 - Health check failing to connect<br />
+ From: Mikola Rose<br />
+ Date: Tue, 4 Dec 2012 20:21:55 +0000<br />
+ <a href="http://www.sraoss.jp/pipermail/pgpool-general/2012-December/001237.html">
+ http://www.sraoss.jp/pipermail/pgpool-general/2012-December/001237.html</a>
+</blockquote>
+</li>
- <dt>障害発生検知時のアクティブ、スタンバイ切り替え</dt>
- <dd>
- <p>
- pgpool のサービスに障害を検知した場合、watchdog は他の watchdog に障害検知を通知します。
- 故障した pgpool がアクティブの場合、他の watchdog は新しいアクティブを投票で決め、
- アクティブ・スタンバイの切り替えを行ないます。
- </p>
- </dd>
+<li>health_check() が template1 データベースに再接続を試みる前に、ヘルスチェックタイマーを
+ チェックするよう修正しました。 (Tastuo Ishii)
+<p>
+ 修正前は、ヘルスチェックタイマーが既に期限を向かえているために、0番ノードへのヘルスチェックの
+ 再接続が常に失敗していました。
+</p>
+</li>
- <dt>サーバ切り替えと連動した仮想 IP アドレスの自動付け替え</dt>
- <dd>
- <p>
- スタンバイが新しいアクティブに昇格する際、新アクティブ機の watchdog は
- アクティブ用の仮想 IP インターフェースを起動します。
- 一方、旧アクティブ機の watchdog はアクティブ用仮想 IP インターフェースを停止します。
- </p>
- <p>
- これにより、サーバが切り替わった後もアクティブは同じ IP アドレスでサービスを継続することができます。
- </p>
- </dd>
+<li>pool_search_relcache() が REAL_MASTER_NODE_ID ではなく MASTER, MASTER_NODE_ID
+ を使用するように修正しました。 (Tatsuo Ishii)
+<p>
+ ストリーミングレプリケーションモードで 0 番ノードがフェールバックした場合、pgpool は
+ 子プロセスを再起動しません。そのとき、REAL_MASTER_NODE_ID は 0 番ノードの接続情報を探しにいきますが、
+ これはバックエンドへの新しい接続が確立するまで存在しません。
+ そのため、接続情報の参照によって、セグメンテーションフォルトが発生していました。
+ この状況でも、MASTER または MASTER_NODE_ID は以前にキャッシュされたマスターノード ID を見にいくため、
+ 安全に使うことが出来ます。
+</p>
+</li>
- <dt> サーバ復旧時、スタンバイ機としての自動登録</dt>
- <dd>
- <p>
- 障害機の復旧や新規サーバを追加する場合、watchdog はサーバの情報を他のwatchdog に通知し、
- 他の watchdog からはアクティブや他のサーバの情報を受け取ります。
- </p>
- <p>
- これにより追加したサーバはスタンバイ機として自動的に追加されます。
- </p>
- </dd>
- </dl>
+<li>ストリーミングレプリケーションモードでレプリケーション遅延が大きくなったときに、
+ "portal not found" エラーが発生するバグを修正しました。 (Tatsuo Ishii)
+<p>
+ これは delay_threshold が導入以来、ずっと存在していたバグです。
+</p>
+<p>
+ bind, describe, execute の実行時に遅延が域値を越えた場合、送り先の DB ノードは
+ 変更されていました。しかし、parse がそれとは異なるノードに送られていた場合、送り先ノードには
+ parse された ステートメントやポータルが存在しないために bind, describe, execute は
+ 失敗していました。 修正後は、大きな遅延が発生した場合でも、これらは parse が実行された
+ ノード以外には送られないようになりました。
+</p>
+</li>
- </dd>
+<li>pg_md5 で、ユーザからのパスワード入力の後には改行するように修正しました。 (Yugo Nagata)</li>
+
+<li>watchdog のポート番号が既に使用されていた場合にエラーメッセージを出力するよう修正しました。
+ (Yugo Nagata)
+<p>
+ この問題は [pgpool-general: 1167] で Will Ferguson さんによって報告されました。
+</p>
+<blockquote>
+ [pgpool-general: 1167] Re: Watchdog error - wd_init: delegate_IP already exists<br />
+ From: Will Ferguson<br />
+ Date: Tue, 6 Nov 2012 13:03:36 +0000<br />
+ <a href="http://www.sraoss.jp/pipermail/pgpool-general/2012-November/001186.html">
+ http://www.sraoss.jp/pipermail/pgpool-general/2012-November/001186.html</a>
+</blockquote>
+</li>
+
+<li>コネクションプールが存在しない場合には、child_exit() が send_frontend_exits()
+ を呼ばないよう修正しました。 (Tatsuo Ishii)
+<p>
+ send_frontend_exits() は pool_connection_pool で指されてるオブジェクトを参照しているため、
+ 修正前にはセグメンテーションフォルトが発生していました。バグトラック #44 の tuomas さんの報告によります。
+</p>
+<blockquote>
+ #44 pgpool went haywire after slave shutdown triggering master failover<br />
+ Reporter: tuomas<br />
+ Date: 2012-12-11 00:33<br />
+ <a href="http://www.pgpool.net/mantisbt/view.php?id=44">
+ http://www.pgpool.net/mantisbt/view.php?id=44</a>
+</blockquote>
+</li>
+
+<li>オンメモリクエリキャッシュで、black_memqcache_table_list にテーブルが指定されている場合に
+ white_memqcache_table_list に指定されたテーブルのみがキャッシュされていたバグを修正しました。
+ (Yugo Nagata)</li>
+
+<li>pool_read() が不正なパケットを読み込んだ場合に、read_startup_packet() がアラームクロック
+ をリセットして StartupPacket を解放するよう修正しました。 (Nozomi Anzai)
+<p>
+ 修正前は、pgpool ポートの監視を行うプログラムの接続により、認証のタイムアウトが発生していました。
+ この問題は、バグトラック #35 で報告されました。
+</p>
+<blockquote>
+ #35 Authentication is timeout<br />
+ Reporter: tuomas <br />
+ Date: 2012-11-20 11:54<br />
+ <a href="http://www.pgpool.net/mantisbt/view.php?id=35">
+ http://www.pgpool.net/mantisbt/view.php?id=35</a>
+</blockquote>
+</li>
+
+<li>pool_open() が誤ったバッファポインタを初期化していたバグを修正しました。 (Tatsuo Ishii)
+<p>
+ このポインタは事前に memset() によって初期化されているため、実際にはこのバグによる害は
+ ありませんでした。
+</p>
+</li>
+
+<li>fail_over_on_backend_error が無効のためファイルオーバが行われなかった場合には、
+ ログメッセージを出力するようにしました。 (Tatsuo Ishii)</li>
+
+<li>LISTEN/NOTIFY の処理に関するバグを修正しました。 (Tatsuo Ishii)
+<p>
+ 1) ストリームレプリケーションモードにおいて以下の状況でハングアップが起きていました。
+</p>
+<pre>
+ Session 1: LISTEN aaa;
+ Session 2: NOTIFY aaa;
+ Session 1: LISTEN aaa; --- ハング
+</pre>
+<p>
+ （LISTEN と NOTIFY が同じセッションで発行された場合には問題ありませんでした。）
+</p>
+<p>
+ pgpool では、パケットは全てのバックエンドから送られてくることを前提にしていました。
+ しかし、ストリーミングレプリケーションモードでは notifiction メッセージはプライマリノードからしか
+ 送られて来ません。このハングは、スタンバイノードからのパケット読込を回避することで修正しました。
+</p>
+<p>
+ 2) この修正後も、ストリーミングレプリケーションモードでプライマリノードが 0 番ノードの場合には、
+ #1 と同様のハングが発生していました。これは、MASTER_NODE_ID マクロが
+ 常に REAL_MASTER_NODE_ID を返していたためです。 master/slave モードでは、これが
+ PRIMARY_NODE_ID を返すように修正しました。
+</p>
+<p>
+ 3) レプリケーションモードでは LISTEN/NOTIFY は全く動作していませんでした。このモード
+ では NOTIFY は全てのバックエンドに送られます。しかし、その応答の順番はマスターが最初で、
+ 次がスレーブとは限りません。最初にスレーブから応答した場合には、単にそれを破棄するのではなく、
+ マスターから読込を行うように pool_process_query() を修正しました。
+</p>
+<p>
+ 4) レプリケーションモードで、LISTENとNOTIFYが同じセッションから発行された場合、
+ db_command() が 'N', 'E', 'S', 'C' 以外のパケットを受信するために、そのセッションは切断されていました。
+ これは、'A'パケットをスタックに入れておき、都合の良いときに取り出すことで解決しました。
+ そのための関数、pool_push(), pool_pop(), pool_stacklen() が追加されています。
+</p>
+<p>
+ このバグはバグトラック #45 で rpashin さんにより報告されました。
+</p>
+<blockquote>
+ #45 LISTEN/NOTIFY doesn't work if cluster contains more then 1 node in<br />
+ streaming replication mode<br />
+ Reporter: rpashin <br />
+ Date: 2012-12-12 00:09<br />
+ <a href="http://www.pgpool.net/mantisbt/view.php?id=45">
+ http://www.pgpool.net/mantisbt/view.php?id=45</a>
+</blockquote>
+<p>
+ 修正のサイズが大きいため、この修正は 3.1 以前にはバックパッチされません。
+ （これまでのところ、3.1 以前でこの障害の報告はありません。）
+</p>
+</li>
+
+<li id="322_bugfix_connect">connect(2) が EINPREGESS または EALREADY エラーを返したときには、
+ connect_inet_domain_socket_by_port() は エラーを出力せずに、select(2) を実行するよう
+ 修正しました。 (Tatsuo Ishii)
+<p>
+ ノンブロッキングソケットでは、"Connection timed out" エラーにもかかわらず、実際には
+ 接続は確立されています。これを解決するためには、connect(2) が EINPROGRESS または
+ EALREADY を返した場合には、再試行ループではなく select(2) を使って接続を待つ必要があります。
+</p>
+<p>
+ この問題は、バグトラック #46 で mcousin さんにより報告されました。
+</p>
+<blockquote>
+ #46 Watchdog failing to connect sometimes<br />
+ Reporter: mcousin <br />
+ Date: 2012-12-15 01:01<br />
+ <a href="http://www.pgpool.net/mantisbt/view.php?id=46">
+ http://www.pgpool.net/mantisbt/view.php?id=46</a>
+</blockquote>
+</li>
+
+<li>watchdog 使用時は num_init_children を大きめに設定するよう、マニュアルに注意書きを
+ 追記しました。 (Tatsuo Ishii)
+<p>
+ 詳しくは[pgpool-general: 1330] をご覧ください。
+</p>
+<blockquote>
+ [pgpool-general: 1330] WatchDog and pgool sudden stop working<br />
+ From: Tomas Halgas<br />
+ Date: Fri, 18 Jan 2013 14:47:23 +0100<br />
+ <a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-January/001350.html">
+ http://www.sraoss.jp/pipermail/pgpool-general/2013-January/001350.html</a>
+</blockquote>
+</li>
+
+<li>watchdog を有効にしたときに、 pgpool-II の起動時、ファイルオーバ時に発生する
+ セグメンテーションフォルトを修正しました。 (Yugo Nagata)
+<p>
+ このバグの原因は pthread_detach と pthread_join を併用するという pthread の誤使用でした。
+ スレッドのステータス取得のため、pthread_join のみを用いることで
+ 修正しました。なお、この問題は Fedora 17 などの比較的最近のOSで発生しましたが、
+ 幸運にも他の OS では観察されていませんでした。
+</p>
+<p>
+ この問題は [pgpool-general: 1179] にて、Lonni J Friedman さんによって報告されました。
+</p>
+<blockquote>
+ [pgpool-general: 1179] 3.2.1 segfaults at startup on Fedora17.<br />
+ From: Lonni J Friedman<br />
+ Date: Mon, 12 Nov 2012 15:58:29 -0800<br />
+ <a href="http://www.sraoss.jp/pipermail/pgpool-general/2012-November/001198.html">
+ http://www.sraoss.jp/pipermail/pgpool-general/2012-November/001198.html</a>
+</blockquote>
+<p>
+ 修正パッチはバグトラック #48 にて、chads さんによって提供頂きました。
+</p>
+<blockquote>
+ pthread_detach is being used wrong; causes pgpool to segfault.<br />
+ Reporter: chads <br />
+ Date: 2013-01-16 05:44<br />
+ <a href="http://www.pgpool.net/mantisbt/view.php?id=48">
+ http://www.pgpool.net/mantisbt/view.php?id=48</a>
+</blockquote>
+</li>
+
+<li>[pgpool-general: 1046] で報告されたスプリットブレインが発生しないよう修正しました。
+ (Yugo Nagata)
+<p>
+ 全てのバックエンドから切り離された pgpool-II にバックエンドを復帰させた時に、複数の
+ アクティブ pgpool が存在してしまう状況（スプリットブレイン）が発生していました。
+ 修正後は、一度全てのバックエンドから切り離された pgpool-II は、再起動されない限り、
+ ダウン状態に留まります。ダウン状態の pgpool-II はアクティブになれないため、上述の
+ スプリットブレインは回避されます。
+</p>
+<blockquote>
+ [pgpool-general: 1046]<br />
+ watchdog enabled delegate_IP on multiple nodes simultaneously<br />
+ From: Lonni J Friedman<br />
+ Date: Wed, 26 Sep 2012 09:05:09 -0700<br />
+ <a href="http://www.sraoss.jp/pipermail/pgpool-general/2012-September/001064.html">
+ http://www.sraoss.jp/pipermail/pgpool-general/2012-September/001064.html</a>
+</blockquote>
+</li>
+
+<li>アクティブ pgpool の終了時にハングすることがあったのを修正しました。
+ (Yugo Nagata)
+<p>
+ アクティブ pgpool は終了時に仮想 IP を停止してパケットを他の pgpool に送ります。
+ しかし、仮想 IP が完全に停止する前にパケットが送信されることがありました。その場合、
+ パケットの送信元には仮想 IP がセットされるため、仮想IPの停止後はアクティブ pgpool パケットの
+ 応答を受け取れなくなり、ハングしていました。
+</p><p>
+ 修正後は、アクティブ pgpool は仮想 IP の停止を確認した後に、パケットを送信します。
+</p>
+</li>
+
+<li>マニュアルの「watchdogの制限事項」の項目を加筆・修正しました。 (Yugo Nagata)</li>
+
+<li>pgpool.conf.sample* およびドキュメント中の、「パラメータ変更に再起動が必要かどうか」
+ の情報を追記・修正しました。 (Yugo Nagata)</li>
+
+<li>pool_passwd に関する記述を pgpool_conf.sample*、 ドキュメント、 および
+ pool_process_reporting.c に追加しました。 (Yugo Nagata)
+<p>
+ 修正前は、SHOW pool_status, pcp_pool_status の出力に pool_passwd が含まれて
+ いませんでした。
+</p>
+</li>
+</ul>
+
+<h2><a name="release3.2.1"></a>3.2.1 (namameboshi) 2012/10/12</h2>
+<h3>概要</h3>
+<p>
+このバージョンは 3.2.0 に対するバグ修正リリースです。
+</p>
+<h3>バグ修正</h3>
+<ul>
+<li>send_cached_messages() を修正しました。 (Tatsuo Ishii)
+ <p>
+ これまでは、行データが 8192 byte 以上のときはバッファ長を 8192 byte に修正して
+ キャッシュしているだけでした。
+ </p>
+ <p>
+ これを、引数としてわたってきたバッファ用の raw データのコピーを削除して、
+ send_message へのポインタを無視するようにしました。
+ </p>
+</li>
+
+<li>クエリキャッシュ機能により、拡張問い合わせが失敗していたのを修正しました。 (Nozomi Anzai)</li>
+
+<li>read_startup_packet() を修正しました。(Tatsuo Ishii)
+ <p>
+ パケット長が 0 以下のときは直ちに return するべきでしたが、そうなっていなく、
+ メモリ確保時にエラーになっていました。
+ </p>
+ <p>これは pgpool-general:886 を参照してください。また、キャンセルアラームを追加しました。</p>
+ <blockquote>
+ [pgpool-general: 886] read_startup_packet: out of memory<br>
+ From: Lonni J Friedman<br>
+ Date: Wed, 8 Aug 2012 10:18:15 -0700<br>
+ <a href="http://www.sraoss.jp/pipermail/pgpool-general/2012-August/000896.html">
+ http://www.sraoss.jp/pipermail/pgpool-general/2012-August/000896.html</a>
+ </blockquote>
+</li>
+
+<li>pgpool をシャットダウンするときに、watchdog のプロセス終了方法を修正しました。 (Tatsuo Ishii)
+ <p>
+ watchdog プロセスは kill(0,SIG) を呼んで watchdog 関連のプロセスを終了していました。
+ これによってかえって、親プロセスや pgpool や httpd プロセスまでもを終了させることがありました。
+ これは、pgpoolAdmin によって invoke されている場合に、すべてが同じプロセスグループになるためです。
+ </p>
+ <p>将来は、どんな場合でもsetsid()によって新しいプロセスグループを作るべきだと思います。</p>
+</li>
+
+<li>"-- コメント" で始まったりコメントが複数あるクエリで、
+ クエリキャッシュが使えなかったのを修正しました。(Nozomi Anzai)
+</li>
+
+<li>マルチステートメントのクエリはキャッシュしないようにしました。(Nozomi Anzai)
+ <p>これまでは "SELECT 1;UPDATE..." のようなクエリもキャッシュしていましたが、誤りでした。</p>
+</li>
+
+<li>ドキュメントに watchdog の制限を追記しました。(Yugo Nagata)</li>
+
+<li>s_do_auth() に NOTICE メッセージを追加しました。(Tatsuo Ishii)
+ <p>これがなかったために、ヘルスチェックが false アラームを受け取りフェイルオーバしていました。</p>
+ <p>これはバグトラックで報告されました。</p>
+ <blockquote>
+ #25 s_do_auth doesn't handle NoticeResponse (N) message<br>
+ Date: 2012-08-28 03:57<br>
+ Reporter: singh.gurjeet<br>
+ <a href="http://www.pgpool.net/mantisbt/view.php?id=25">http://www.pgpool.net/mantisbt/view.php?id=25</a>
+ </blockquote>
+</li>
+
+<li>s_do_auth() から、不要かつ混乱をまねくデバッグメッセージを削除しました。(Tatsuo Ishii)</li>
+
+<li>メモリキャッシュ有効時に Execute() でバッファオーバーランするのを修正しました。(Tatsuo Ishii)
+ <p>
+ bind パラメータのひとつが 0 より小さいとき、符号拡張のために "%02X" で
+ 2 バイト以上の文字を生成する可能性がありました。
+ </p>
+ <p>
+ また、そのあとにバッファオーバランを招く可能性を排除するため、sprintf()
+ ではなく snprintf() を使うようにしました。
+ </p>
+</li>
+
+<li>2009 年 12 月にリリースした pgpool-II 2.3 以来ずっと存在した
+ free_select_result() のメモリーリークを修正しました。(Tatsuo Ishii)
+ <p>
+ 実際にはこのバグは、レプリケーションモードでしか発生しません
+ （タイムスタンプ書き換え時に偶然発生することがありました）。
+ </p>
+ <p>これはバグトラック #24 で報告されました。</p>
+ <blockquote>
+ #24 Severe memory leak in an OLTP environment<br>
+ Date: 2012-08-28 03:43<br>
+ Reporter: singh.gurjeet<br>
+ <a href="http://www.pgpool.net/mantisbt/view.php?id=24">http://www.pgpool.net/mantisbt/view.php?id=24</a>
+</blockquote>
+</li>
+
+<li>cache_reporting() の typo を修正しました。(Tatsuo Ishii)</li>
+
+<li>SSL モードでの無限ループを修正しました。 (Tatsuo Ishii)
+ <p>
+ フロントエンドの SSL レイヤで溜っているデータがあるとき、
+ pool_process_query() がバックエンドに溜っているデータをチェックします。
+ もしそれが無かったときは再度ループして、フロントエンド/バックエンドがバッファを受け取っていないか
+ is_cache_empty() を以ってチェックします。
+ しかし、フロントエンドの SSL レイヤでデータが溜っているのを一度検知すると、
+ バックエンドに行ってまたチェックしようとします（無限ループ）。
+ </p>
+ <p>
+ これを解決するには、フロントエンドの SSL レイヤに溜っているデータがあり
+ かつ クエリが実行中でなければ、ProcessFrontendResponse() を呼んで
+ フロントエンドへの新しいリクエストをするようにしました。
+</p>
+</li>
+
+<li>is_system_catalog() で、可能ならば pgpool_regclass を使うようにしました。(Tatsuo Ishii)</li>
+
+<li>pool_get_insert_table_name() のメモリリークを修正しました。(Tatsuo Ishii)
+ <p>
+ nodeToString() でセッションコンテクストのメモリコンテクストを使ったあと、
+ セッション終了までは、メモリを開放していませんでした。
+ </p>
+ <p>詳しくはバグトラックをご覧ください。</p>
+ <blockquote>
+ #24 Severe memory leak in an OLTP environment<br>
+ Date: 2012-08-28 03:43<br>
+ Reporter: singh.gurjeet<br>
+ <a href="http://www.pgpool.net/mantisbt/view.php?id=24">http://www.pgpool.net/mantisbt/view.php?id=24</a>
+ </blockquote>
+</li>
+
+<li>OID マップファイルをロックするのに flock(2) ではなく fcntl(2) を使うようにしました。(Tatsuo Ishii)
+ <p>
+ flock(2) は環境に依存し、Solaris で使えませんでした。
+ パッチは Ibrar Ahmed さんからいただきました。
+ </p>
+</li>
+
+<li>Raw モードで稼働しているとき、get_next_master_node() で見落としがあったのを修正しました。(Tatsuo Ishii)
+ <p>マスタノードがダウンしたとき、必ずマスタノード ID 0 を返していました。</p>
+ <p>詳細は [pgpool-general: 1039] をご覧ください。</p>
+ <blockquote>
+ [pgpool-general: 1039] Raw failover not working as expected on pgpool-II v3.2.0
+ From: Quentin White<br>
+ Date: Tue, 25 Sep 2012 07:45:34 +0000<br>
+ <a href="http://www.sraoss.jp/pipermail/pgpool-general/2012-September/001057.html">
+ http://www.sraoss.jp/pipermail/pgpool-general/2012-September/001057.html</a>
+ </blockquote>
+</li>
+
+<li>do_query() のセグメンテーションフォルトを修正しました。(Tatsuo Ishii)
+ <p>
+ クエリキャッシュが有効で拡張問い合わせが使われているとき、do_query() はシステムカタログに接続し、
+ pool_read2() を使います。
+ しかし、parse メッセージパケットを Parse() で取得し、パケットの内容が pool_read2() のバッファにあります。
+ このため、do_query() はパケットの内容を分割できず、セグメンテーションフォルトを引き起こしていました。
+ </p>
+ <p>
+ これを解決するために、メモリを確保し、パケット内容をコピーし、Parse() を飛ばすようにしました。
+ ただし、パケットの中にはクエリコンテクストが参照しているクエリ文字列も含まれています。
+ そのため、このクエリ文字列をコピーしてポインタをクエリコンテクストに保持する必要があります。
+ </p>
+ <p>
+ これは、Parse() だけの話でなく、他のプロトコルモジュールにもある問題と考えています。
+ 本修正はそれらにも適用しますが、そのためには、ProcessFrontendResponse() を変更します。
+ </p>
+
+ <p>この問題はバグトラック #21 で報告されました。</p>
+ <blockquote>
+ #21 pgpool-II 3.2.0 cannot execute sql through jdbc<br>
+ Date: 2012-08-17 16:31<br>
+ Reporter: elisechiang<br>
+ <a href="http://www.pgpool.net/mantisbt/view.php?id=21">http://www.pgpool.net/mantisbt/view.php?id=21</a>
+ </blockquote>
+</li>
+
+<li>PCP 通信で UNIX ドメインソケットパスをセットするのを、
+ シグナルハンドラのセットアップ前に行なうように修正しました。(Yugo Nagata)
+ <p>これまでは、このパス情報がなかったために、プロセス終了時のソケットの削除が失敗していました。</p>
+ <p>パッチは Gilles Darold さんが提供しました。</p>
+ <blockquote>
+ [pgpool-hackers: 131] Found bug with watchdog resulting in pgpool segmentation fault
+ From: Gilles Darold<br>
+ Date: Thu, 13 Sep 2012 18:54:42 +0200<br>
+ <a href="http://www.sraoss.jp/pipermail/pgpool-hackers/2012-September/000130.html">
+ http://www.sraoss.jp/pipermail/pgpool-hackers/2012-September/000130.html</a>
+ </blockquote>
+</li>
+
+<li>watchdog の ifup/ifdown や arping コマンドが存在しないときに
+ メッセージを出すようにしました。 (Yugo Nagata)</li>
+
+<li>ずっとあった do_query() で "portal "" does not exist" エラーが出るのを修正しました。(Tatsuo Ishii)
+ <p>
+ 1) 拡張問い合わせを使っていて、
+ 2) unnamed portal が使われていて、
+ 3) 明示的なトランザクションを使っていないとき、
+ ユーザの unnamed portal が Sync メッセージで削除されていました。
+ </p>
+ <p>
+ これは、Sync メッセージがトランザクションを終了して unnamed portal を削除するためです。
+ このために "portal "" does not exist" というエラーが出ていました。
+ </p>
+ <p>
+ これを修正するために、Sync ではなく Flush メッセージを使うようにしました。
+ 二者の主な違いとしては、Flush は Ready For Query メッセージを返さないことです。
+ したがって do_query() は、来るべきであろうメッセージをすべて待ってから return するようになります。
+ </p>
+ <p>
+ バックエンドからメッセージが来る順序はランダムに見えますが、do_query() は
+ それを状態のビットを以って管理しています。
+ </p>
+</li>
+</ul>
+
+<h2><a name="release3.2.0"></a>3.2.0 (namameboshi) 2012/08/03</h2>
+<h3>概要</h3>
+<p>
+このバージョンは 3.2 系列の最初の版で、3.1 系からの「メジャーバージョンアップ」にあたります。
+</p>
+
+<h3>互換性のない変更</h3>
+
+<ul>
+<li>メモリベースのメモリキャッシュ機能を追加したため、旧来のメモリキャッシュ機能は削除しました。
+ <ul>
+ <li>これにともない、enable_query_cache パラメータを削除しました。</li>
+ </ul>
+</li>
+</ul>
+
+<h3 id="3.2_new_feartures">新機能</h3>
+
+<ul>
+<li><a href="#memqcache">メモリベースのクエリキャッシュ</a>を追加しました。
+ (Tatsuo Ishii, Nozomi Anzai, Yugo Nagata)
+<p>オリジナルは Masanori Yamazaki さんが作成し、開発グループで改良しました。</p>
+
+<dl>
+<dt>概要</dt>
+ <p>
+ メモリ上にキャッシュが置かれるので高速であるばかりでなく、データが更新されると自動的にキャッシュが無効になり、
+ pgpool-II の再起動の必要がありません。
+ </p>
+ <p>
+ オンメモリクエリキャッシュは、問い合わせの SELECT 文(拡張問い合わせの場合は更にバインドパラメータ)と
+ 検索結果をペアで記録し、2 回目以降に同じ SELECT 文が発行された場合に、キャッシュから結果を返します。
+ 通常の SELECT 文処理と違って、PostgreSQL にアクセスしないだけでなく、
+ pgpool 内部の SQL パース処理などを経由しないため、非常に高速です。
+ </p>
+ <p>
+ 反面、キャッシュにヒットしない場合は通常の SELECT 文の処理に加えてキャッシュ処理のオーバヘッドが生じるので、
+ かえって遅くなります。また、あるテーブルが更新された場合、そのテーブルを参照している
+ すべてのキャッシュが自動削除されるため（自動削除しない設定も可能）、
+ 更新処理が多いシステムではオンメモリクエリキャッシュを有効にしていることでかえって遅くなります。
+ キャッシュのヒット率が 70% 以下の場合は、オンメモリクエリキャッシュの設定を有効にしないほうが良いでしょう。
+ </p>
+
+<dt>キャッシュストレージの選択</dt>
+ <dd>
+ <p>
+ メモリキャッシュのストレージには、共有メモリと memcached のどちらかを選択することができます
+ （併用はできません）。
+ </p>
+ <ul>
+ <li>共有メモリを使用するクエリキャッシュは高速で、memcached の立ち上げも必要なく、手軽に利用できます。
+ ただし、共有メモリサイズの上限によって保存できるキャッシュの量に制限があります。
+ </li>
+ <li>memcached をキャッシュストレージに使用する場合は、ネットワークアクセスのオーバヘッドがあるものの、
+ 比較的自由にキャッシュメモリの大きさを設定できます。
+ </li>
+ </ul>
+ </dd>
+
+<dt>制限事項</dt>
+ <dd>
+ <ul>
+ <li>
+ オンメモリクエリキャッシュでは、テーブルに変更があると、関連するキャッシュを自動的に削除して
+ 古いデータが返却されないようにする機能があります。
+ このため、pgpool は常に UPDATE や INSERT や ALTER TABLE などのコマンドが発行されたかどうかを
+ モニタしています。<br>
+ しかし、トリガ、外部キーや DROP TABLE CASCADE などの働きによって暗黙的にテーブルが更新されたことは
+ pgpool-II からはわからないため、この機能が働きません。<br>
+ この問題を回避するためには、 memqcache_expire を使って一定時間経過したキャッシュを削除するようにするか、
+ <a href="#BLACK_MEMQCACHE_TABLE_LIST">black_memqcache_table_list</a> を使って、該当テーブルが
+ キャッシュされないようにしてください。
+ </li>
+
+ <li>
+ 複数の pgpool-II を動かす環境で共有メモリを使ったオンメモリクエリキャッシュを使用すると、
+ ある pgpool-II 経由でテーブルが更新された時に、他の pgpool-II のキャッシュが削除されず、
+ 古いデータを読みだしてしまうことがあります。<br>
+ このような環境では、キャッシュストレージに memcached を使ってください。
+ </li>
+ </ul>
+ </dd>
+
+<dt>新しいパラメータ</dt>
+ <dd>
+ <ul>
+ <li>メモリキャッシュ全般に関するパラメータ
+ <a href="#MEMORY_CACHE_ENABLED">memory_cache_enabled</a>、
+ <a href="#MEMQCACHE_METHOD">memqcache_method</a>、
+ <a href="#MEMQCACHE_EXPIRE">memqcache_expire</a>、
+ <a href="#MEMQCACHE_MAXCACHE">memqcache_maxcache</a>、
+ <a href="#MEMQCACHE_OIDDIR">memqcache_oiddir</a> を追加しました。(Tatsuo Ishii)</li>
+
+ <li>共有メモリを使ったメモリキャッシュに関するパラメータ
+ <a href="#MEMQCACHE_TOTAL_SIZE">memqcache_total_size</a>、
+ <a href="#MEMQCACHE_MAX_NUM_CACHE">memqcache_max_num_cache</a>、
+ <a href="#MEMQCACHE_CACHE_BLOCK_SIZE">memqcache_cache_block_size</a> を追加しました。
+ (Tatsuo Ishii)</li>
+
+ <li>memcached を使ったメモリキャッシュに関するパラメータ
+ <a href="#MEMQCACHE_MEMCACHED_HOST">memqcache_memcached_host</a>、
+ <a href="#MEMQCACHE_MEMCACHED_PORT">memqcache_memcached_port</a> を追加しました。
+ (Tatsuo Ishii)
+ </li>
+
+ <li>リレーションキャッシュに関するパラメータ
+ <a href="#RELCACHE_EXPIRE">relcache_expire</a>、
+ <a href="#RELCACHE_SIZE">relcache_size</a> を追加しました。(Tatsuo Ishii)</li>
+
+ <li>一時テーブルかどうかをチェックするフラグ <a href="#CHECK_TEMP_TABLE">check_temp_table</a> パラメータを
+ 追加しました。(Tatsuo Ishii)
+ </li>
+
+ <li>テーブル、一時テーブル、ビューのキャッシュ可否を指定するパラメータ、
+ <a href="#WHITE_MEMQCACHE_TABLE_LIST">white_memqcache_table_list</a>、
+ <a href="#BLACK_MEMQCACHE_TABLE_LIST">black_memqcache_table_list</a> を追加しました。
+ (Nozomi Anzai)</li>
+
+ <li><a href="#MEMQCACHE_AUTO_CACHE_INVALIDATION">memqcache_auto_cache_invalidation</a>
+ パラメータを追加しました。(Yugo Nagata)
+ <p>
+ true であれば、DDL/DML/DCL が発行されたら <a href="#MEMQCACHE_EXPIRE">memqcache_expire</a> を待たずに
+ クエリキャッシュを削除します。
+ </p>
+ </li>
+
+ <li><a href="#pool_cache">SHOW pool_cache</a> を追加しました。クエリキャッシュのヒット率や、
+ キャッシュストレージの状況を表示します。(Tatsuo Ishii)</li>
+
+ <li><a href="#install">configure</a> に --with-memcached オプションを追加しました。(Tatsuo Ishii)</li>
+
+ <li><a href="#start">pgpool コマンド</a> に "-C, --clear-oidmaps" オプションを追加しました。
+ (Nozomi Anzai)
+ <p>
+ memcached を使ったメモリキャッシュを行なっている pgpool が -C つきで起動・再起動したときは、
+ oid マップを削除せず再利用します。
+ </p>
+ </li>
+ </ul>
+ </dd>
+ </dl>
+</li>
+
+<li><a href="#watchdog">Watchdog 機能</a> を追加しました。(Atsushi Mitani, Yugo Nagata)
+<p>Atsushi Mitani が作成し、Yugo Nagata がテストしました。</p>
+
+<dl>
+<dt>概要</dt>
+ <dd>
+ <p>
+ watchdog プロセスは pgpool-II 本体から起動される、高可用性を目的としたプロセスです。以下の機能を提供します。
+ </p>
+
+ <dl>
+ <dt>pgpool サービスの死活監視</dt>
+ <dd>
+ <p>
+ watchdog は、pgpool のプロセスではなくサービスの応答を監視します。
+ 監視対象の pgpool から PostgreSQL に問い合わせを行ない、その応答をチェックします。
+ </p>
+ <p>
+ また watchdog は、pgpool から上位のサーバ（アプリケーションサーバなど）への接続も監視します。
+ 上位サーバから PostgreSQL への接続・応答を pgpool のサービスとして死活監視します。
+ </p>
+ </dd>
+
+ <dt>watchdog プロセスの相互監視</dt>
+ <dd>
+ <p>
+ 各 watchdog はお互いの監視対象のサーバの情報を交換します。
+ これにより、pgpool サーバの情報を最新に保てるだけでなく、
+ 各 watchdog プロセスの相互 監視を行なっています。
+ </p>
+ </dd>
+
+ <dt>障害発生検知時のアクティブ、スタンバイ切り替え</dt>
+ <dd>
+ <p>
+ pgpool のサービスに障害を検知した場合、watchdog は他の watchdog に障害検知を通知します。
+ 故障した pgpool がアクティブの場合、他の watchdog は新しいアクティブを投票で決め、
+ アクティブ・スタンバイの切り替えを行ないます。
+ </p>
+ </dd>
+
+ <dt>サーバ切り替えと連動した仮想 IP アドレスの自動付け替え</dt>
+ <dd>
+ <p>
+ スタンバイが新しいアクティブに昇格する際、新アクティブ機の watchdog は
+ アクティブ用の仮想 IP インターフェースを起動します。
+ 一方、旧アクティブ機の watchdog はアクティブ用仮想 IP インターフェースを停止します。
+ </p>
+ <p>
+ これにより、サーバが切り替わった後もアクティブは同じ IP アドレスでサービスを継続することができます。
+ </p>
+ </dd>
+
+ <dt> サーバ復旧時、スタンバイ機としての自動登録</dt>
+ <dd>
+ <p>
+ 障害機の復旧や新規サーバを追加する場合、watchdog はサーバの情報を他のwatchdog に通知し、
+ 他の watchdog からはアクティブや他のサーバの情報を受け取ります。
+ </p>
+ <p>
+ これにより追加したサーバはスタンバイ機として自動的に追加されます。
+ </p>
+ </dd>
+ </dl>
+
+ </dd>
<dt>新しいパラメータ</dt>
<dd>
@@ -5931,7 +6603,7 @@ SELECTの最終実行ステータスとパフォーマンスのおおよその
<p>
これは主に、memcached_get() が MEMCACHED_NOTFOUND 以外のエラーを返した場合には、
pool_fetch_cache() が "cache not found" を装うように修正することで対処しました。
- また、その場合には後のエラーを防ぐために pool_config->memory_cache_enabled を 0
+ また、その場合には後のエラーを防ぐために pool_config->memory_cache_enabled を 0
にセットするようにしました。
</p>
</li>
@@ -5957,53 +6629,462 @@ autoconf
</p>
</li>
-<li>SSL エラー時に、リトライすべきときにしていなかったのを修正しました。 (Tatsuo Ishii)</li>
+<li>SSL エラー時に、リトライすべきときにしていなかったのを修正しました。 (Tatsuo Ishii)</li>
+
+<li> ハングアップを起こさないよう pool_process_query() を修正しました。 (Tatsuo Ishii)
+ <p>
+ プライマリ以外のノードがパケットを送信した際に、pgpool はセッションを終了しようとしてハングアップすることがありました。
+ これは ssl_read が エラーではなく EOF を返すようになり、フェイルオーバが実行されなくなっためです。
+ 例えば [pgpool-gerenal: 766] では以下のような報告があります。
+ </p>
+<pre>
+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.
+</pre>
+ <p>
+ このケースでは、pool_process_query() は POOL_END ではなく POOL_ERROR を返すべきです。
+ </p>
+
+ <blockquote>
+ Subject: <a href="http://www.pgpool.net/pipermail/pgpool-general/2012-July/000774.html">[pgpool-general: 766]</a>
+ Re: pgpool dropping backends too much<br />
+ From: Karl von Randow <br />
+ Date: Thu, 19 Jul 2012 16:07:41 +1200
+ </blockquote>
+</li>
+
+<li>バックエンドから来たたくさんのクエリ結果を読み込んでいる間に
+ フロントエンドが終了したときに、pgpool はバックエンドからの読み込みを続行し、
+ すべてのクエリが送られるまでフロントエンドへの書き込みを行ないます。(Tatsuo Ishii)
+ <p>
+ クエリ結果が巨大だとこれは非常に長い時間を要します。
+ pgpool のセッションを極力早く終了するには、レプリケーションモード以外では、
+ フロントエンドへの書き込みに失敗したらエラーを返すように、pool_flush_it を変更しました。
+ レプリケーションモードでは、以前どおりの挙動、すなわちバックエンド間での同期書き込みを行ないます。
+ </p>
+ <p>
+ そのほか、SimpleForwardToFrontend が、pool_write_and_flush がエラーを返してきたときに
+ それを無視せず、認識するようにしました。
+ </p>
+</li>
+
+</ul>
+
+<hr>
+
+<h2><a name="release3.1.6"></a>3.1.5 (hatsuiboshi) 2012/10/12</h2>
+<h3>概要</h3>
+<p>このバージョンは3.1.5に対するバグ修正リリースです。</p>
+<ul>
+
+<li>md5 認証で競合が発生する不具合が修正されました。(Tatsuo Ishii)
+<p>
+ pool_passwd のファイル識別子は pgpool の親プロセスで開かれたものが子プロセスに引き継がれてます。
+ 複数の接続で同時に md5 認証を行う際には、pool_get_passwd が呼ばれ、ファイル識別子が走査されますが、
+ ファイル識別子が共有されるために md5 認証が失敗することがありました。
+ この問題は、個々の子プロセスで pool_passwd ファイルを開き直すことで解決されました。
+</p>
+<p>
+ この問題は [pgpool-general:1141] にて、Jason Slagle さんによって報告・解析されました。
+</p>
+<blockquote>
+ [pgpool-general: 1141] Possible race condition in pool_get_passwd<br />
+ From: Jason Slagle<br />
+ Date: Sun, 28 Oct 2012 01:12:52 -0400<br />
+ <a href="http://www.sraoss.jp/pipermail/pgpool-general/2012-October/001160.html">
+ http://www.sraoss.jp/pipermail/pgpool-general/2012-October/001160.html</a>
+</blockquote>
+</li>
+
+<li>pcp_attach_node, pcp_detach_node を繰り返し実行したときに起こるハングアップを
+ 修正しました。 (Tatsuo Ishii)
+<p>
+ pcp_attach_node, pap_detach_node によりノードステータスが変更された時、failover()
+ は子プロセスに SIGUSR1 シグナルを送り、プロセスの終了とノードステータスの更新を行います。
+ その時に発せられた SIGCHLD シグナルは全て reaper() ハンドラで受信しますが、
+ システムの負荷とタイミングによりこれが失敗することがありました。
+ pcp プロセスによる SIGCHLD シグナルの受信に失敗した場合に、これがゾンビプロセスとなり、
+ pcp プロセスが永遠に再起動されなくなっていました。
+</p>
+<p>
+ この問題はバグトラック #32（oleg_myrk さんによる）他で報告されました。
+</p>
+<blockquote>
+ #32 PGPool hangs on pcp_attach/detach<br />
+ Reporter: oleg_myrk
+ Date: 2012-10-24 00:01
+ <a href="http://www.pgpool.net/mantisbt/view.php?id=32">
+ http://www.pgpool.net/mantisbt/view.php?id=32</a>
+</blockquote>
+</li>
+
+<li>pool_send_severity_message() で未初期化のメモリを使用しないよう修正しました。
+ (Tatsuo Ishii)
+<p>
+ このバグによりセグメンテーション違反が発生することがありました。
+ バグトラック #33 に投稿された valgrind 実行結果（dudee さんによる）にて報告されました。
+</p>
+<blockquote>
+ #33 pgpool-II 3.2.1 segfault<br />
+ Reporter: dudee
+ Date: 2012-10-30 19:16
+ <a href="http://www.pgpool.net/mantisbt/view.php?id=33">
+ http://www.pgpool.net/mantisbt/view.php?id=33</a>
+</blockquote>
+</li>
+
+<li>通常のテーブルと同名の一時テーブルがあるときに、クエリキャッシュの結果が不正になる
+ バグを修正しました。 (Tatsuo Ishii)
+<p>
+ 以下はバグを引き起こす処理の例です。
+</p>
+<pre>
+ 1) CREATE TABLE t1(i int); -- 通常のテーブルを作成
+ 2) INSERT INTO t1 VALUES(1);
+ 3) SELECT * FROM t1; -- クエリキャッシュが作成される
+ 4) CREATE TEMP TABLE t1(i int); -- 一時テーブルの作成
+ 5) SELECT * FROM t1; -- 誤ったクエリキャッシュが作成される!
+</pre>
+<p>
+ #3 で t1 のキャッシュが生成されますが、#5 でこれが不正に使われており、一時テーブル t1 が
+ 一時テーブルと見なされていないのが問題でした。
+</p>
+</li>
+
+<li>ヘルプメッセージに -f オプションの説明を追加しました。 (Tatsuo Ishii)</li>
+
+<li>pcp または worker 子プロセスの終了イベントを受信したときに、reaper() で wait3()
+ ループを終了しないように修正しました。 (Tatsuo Ishii)
+<p>
+ 修正前は、reaper() は子プロセスの終了イベントを誤って無視してしまい、ゾンビプロセスを作り、
+ 新しいプロセスを生成できないことがありました。
+</p>
+<p>
+ この問題は[pgpool-general-jp: 1123]にて、後藤さんより報告され、修正の示唆を頂きました。
+</p>
+<blockquote>
+ [pgpool-general-jp: 1123] Re: オンラインリカバリ後にゾンビプロセスになる<br />
+ From: GOTO, Daisuke
+ Date: Wed, 21 Nov 2012 19:56:17 +0900
+ <a href="http://www.sraoss.jp/pipermail/pgpool-general-jp/2012-November/001122.html">
+ http://www.sraoss.jp/pipermail/pgpool-general-jp/2012-November/001122.html</a>
+</blockquote>
+</li>
+
+<li>pool_search_relcache() が REAL_MASTER_NODE_ID ではなく MASTER, MASTER_NODE_ID
+ を使用するように修正しました。 (Tatsuo Ishii)
+<p>
+ ストリーミングレプリケーションモードで 0 番ノードがフェールバックした場合、pgpool は
+ 子プロセスを再起動しません。そのとき、REAL_MASTER_NODE_ID は 0 番ノードの接続情報を
+ 探しにいきますが、これはバックエンドへの新しい接続が確立するまで存在しません。
+ そのため、接続情報の参照によって、セグメンテーションフォルトが発生していました。
+ この状況でも、MASTER または MASTER_NODE_ID は以前にキャッシュされた
+ マスターノード ID を見にいくため、安全に使うことが出来ます。
+</p>
+</li>
+
+<li>ストリーミングレプリケーションモードでレプリケーション遅延が大きくなったときに、
+ "portal not found" エラーが発生するバグを修正しました。 (Tatsuo Ishii)
+<p>
+ これは delay_threshold が導入以来、ずっと存在していたバグです。
+</p>
+<p>
+ bind, describe, execute の実行時に遅延が域値を越えた場合、送り先の DB ノードは
+ 変更されていました。しかし、parse がそれとは異なるノードに送られていた場合、送り先ノードには
+ parse された ステートメントやポータルが存在しないために bind, describe, execute は
+ 失敗していました。 修正後は、大きな遅延が発生した場合でも、これらは parse が実行された
+ ノード以外には送られないようになりました。
+</p>
+</li>
+
+<li>pg_md5 で、ユーザからのパスワード入力の後には改行するように修正しました。 (Yugo Nagata)</li>
+
+<li>watchdog のポート番号が既に使用されていた場合にエラーメッセージを出力するよう修正しました。
+ (Yugo Nagata)
+<p>
+ この問題は [pgpool-general: 1167] で Will Ferguson さんによって報告されました。
+</p>
+<blockquote>
+ [pgpool-general: 1167] Re: Watchdog error - wd_init: delegate_IP already exists<br />
+ From: Will Ferguson
+ Date: Tue, 6 Nov 2012 13:03:36 +0000
+ <a href="http://www.sraoss.jp/pipermail/pgpool-general/2012-November/001186.html">
+ http://www.sraoss.jp/pipermail/pgpool-general/2012-November/001186.html</a>
+</blockquote>
+</li>
+
+<li>コネクションプールが存在しない場合には、child_exit() が send_frontend_exits()
+ を呼ばないよう修正しました。 (Tatsuo Ishii)
+<p>
+ send_frontend_exits() は pool_connection_pool で指されてるオブジェクトを参照しているため、
+ 修正前にはセグメンテーションフォルトが発生していました。バグトラック #44 の tuomas さんの報告によります。
+</p>
+<blockquote>
+ #44 pgpool went haywire after slave shutdown triggering master failover<br />
+ Reporter: tuomas
+ Date: 2012-12-11 00:33
+ <a href="http://www.pgpool.net/mantisbt/view.php?id=44">
+ http://www.pgpool.net/mantisbt/view.php?id=44</a>
+</blockquote>
+</li>
+
+<li>pool_read() が不正なパケットを読み込んだ場合に、read_startup_packet() がアラームクロック
+ をリセットして StartupPacket を解放するよう修正しました。 (Nozomi Anzai)
+<p>
+ 修正前は、pgpool ポートの監視を行うプログラムの接続により、認証のタイムアウトが発生していました。
+ この問題は、バグトラック #35 で報告されました。
+</p>
+<blockquote>
+ #35 Authentication is timeout<br />
+ Reporter: tuomas
+ Date: 2012-11-20 11:54
+ <a href="http://www.pgpool.net/mantisbt/view.php?id=35">
+ http://www.pgpool.net/mantisbt/view.php?id=35</a>
+</blockquote>
+</li>
+
+<li>pool_open() が誤ったバッファポインタを初期化していたバグを修正しました。 (Tatsuo Ishii)
+<p>
+ このポインタは事前に memset() によって初期化されているため、実際にはこのバグによる害は
+ ありませんでした。
+</p>
+</li>
+
+<li>ドキュメント中の、「パラメータ変更に再起動が必要かどうか」の情報を追記・修正しました。(Yugo Nagata)</li>
+
+<li>pool_passwd に関する記述を pgpool_conf.sample*、および,ドキュメントに追加しました。 (Yugo Nagata)
+</li>
+</ul>
+
+<h2><a name="release3.1.5"></a>3.1.5 (hatsuiboshi) 2012/10/12</h2>
+<h3>概要</h3>
+<p>このバージョンは3.1.4に対するバグ修正リリースです。</p>
+
+<h3>バグ修正</h3>
+<ul>
+<li>read_startup_packet() を修正しました。(Tatsuo Ishii)
+ <p>
+ パケット長が 0 以下のときは直ちに return するべきでしたが、そうなっていなく、
+ メモリ確保時にエラーになっていました。
+ </p>
+ <p>これは pgpool-general:886 を参照してください。また、キャンセルアラームを追加しました。</p>
+ <blockquote>
+ [pgpool-general: 886] read_startup_packet: out of memory<br>
+ From: Lonni J Friedman<br>
+ Date: Wed, 8 Aug 2012 10:18:15 -0700<br>
+ <a href="http://www.sraoss.jp/pipermail/pgpool-general/2012-August/000896.html">
+ http://www.sraoss.jp/pipermail/pgpool-general/2012-August/000896.html</a>
+ </blockquote>
+</li>
+
+<li>s_do_auth() に NOTICE メッセージを追加しました。(Tatsuo Ishii)
+ <p>これがなかったために、ヘルスチェックが false アラームを受け取りフェイルオーバしていました。</p>
+ <p>これはバグトラックで報告されました。</p>
+ <blockquote>
+ #25 s_do_auth doesn't handle NoticeResponse (N) message<br>
+ Date: 2012-08-28 03:57<br>
+ Reporter: singh.gurjeet<br>
+ <a href="http://www.pgpool.net/mantisbt/view.php?id=25">http://www.pgpool.net/mantisbt/view.php?id=25</a>
+ </blockquote>
+</li>
+
+<li>s_do_auth() から、不要かつ混乱をまねくデバッグメッセージを削除しました。(Tatsuo Ishii)</li>
+
+<li>SSL モードでの無限ループを修正しました。 (Tatsuo Ishii)
+ <p>
+ フロントエンドの SSL レイヤで溜っているデータがあるとき、
+ pool_process_query() がバックエンドに溜っているデータをチェックします。
+ もしそれが無かったときは再度ループして、フロントエンド/バックエンドがバッファを受け取っていないか
+ is_cache_empty() を以ってチェックします。
+ しかし、フロントエンドの SSL レイヤでデータが溜っているのを一度検知すると、
+ バックエンドに行ってまたチェックしようとします（無限ループ）。
+ </p>
+ <p>
+ これを解決するには、フロントエンドの SSL レイヤに溜っているデータがあり
+ かつ クエリが実行中でなければ、ProcessFrontendResponse() を呼んで
+ フロントエンドへの新しいリクエストをするようにしました。
+</p>
+</li>
+
+<li>is_system_catalog() で、可能ならば pgpool_regclass を使うようにしました。(Tatsuo Ishii)</li>
+
+<li>pool_get_insert_table_name() のメモリリークを修正しました。(Tatsuo Ishii)
+ <p>
+ nodeToString() でセッションコンテクストのメモリコンテクストを使ったあと、
+ セッション終了までは、メモリを開放していませんでした。
+ </p>
+ <p>詳しくはバグトラックをご覧ください。</p>
+ <blockquote>
+ #24 Severe memory leak in an OLTP environment<br>
+ Date: 2012-08-28 03:43<br>
+ Reporter: singh.gurjeet<br>
+ <a href="http://www.pgpool.net/mantisbt/view.php?id=24">http://www.pgpool.net/mantisbt/view.php?id=24</a>
+ </blockquote>
+</li>
+
+<li>do_query() のセグメンテーションフォルトを修正しました。(Tatsuo Ishii)
+ <p>
+ クエリキャッシュが有効で拡張問い合わせが使われているとき、do_query() はシステムカタログに接続し、
+ pool_read2() を使います。
+ しかし、parse メッセージパケットを Parse() で取得し、パケットの内容が pool_read2() のバッファにあります。
+ このため、do_query() はパケットの内容を分割できず、セグメンテーションフォルトを引き起こしていました。
+ </p>
+ <p>
+ これを解決するために、メモリを確保し、パケット内容をコピーし、Parse() を飛ばすようにしました。
+ ただし、パケットの中にはクエリコンテクストが参照しているクエリ文字列も含まれています。
+ そのため、このクエリ文字列をコピーしてポインタをクエリコンテクストに保持する必要があります。
+ </p>
+ <p>
+ これは、Parse() だけの話でなく、他のプロトコルモジュールにもある問題と考えています。
+ 本修正はそれらにも適用しますが、そのためには、ProcessFrontendResponse() を変更します。
+ </p>
+
+ <p>この問題はバグトラック #21 で報告されました。</p>
+ <blockquote>
+ #21 pgpool-II 3.2.0 cannot execute sql through jdbc<br>
+ Date: 2012-08-17 16:31<br>
+ Reporter: elisechiang<br>
+ <a href="http://www.pgpool.net/mantisbt/view.php?id=21">http://www.pgpool.net/mantisbt/view.php?id=21</a>
+ </blockquote>
+</li>
+</ul>
+
+<h2><a name="release3.1.4"></a>3.1.4 (hatsuiboshi) 2012/08/06</h2>
+<h3>概要</h3>
+<p>このバージョンは3.1.3に対するバグ修正リリースです。</p>
+<p>また、PostgreSQL 9.2 に対応しました。</p>
+
+<h3>バグ修正</h3>
+<ul>
+
+<li>各ノードにおいて、トランザクション状態によって COMMIT / ABORT するかどうかを判定できるように、
+ pool_send_and_wait() を修正しました。(Tatsuo Ishii)
+ <p>
+ マルチステートメントが送信されたとき、明示的なトランザクション内にあるプ
+ ライマリか、明示的なトランザクション内でないスタンバイで発生する可能性が
+ ありました。
+ </p>
+ <p>これは、[pgpool-general-jp: 1049] で報告されました。</p>
+
+ <blockquote>
+ Subject:
+ <a href="http://www.pgpool.net/pipermail/pgpool-general-jp/2012-April/001048.html">[pgpool-general-jp: 1049]</a>
+ COMMITでエラー<br>
+ From: 稲村暢亮<br>
+ Date: Mon, 30 Apr 2012 13:48:48 +0900
+ </blockquote>
+</li>
+
+<li>Solaris でのロードバランスを修正しました。(Tatsuo Ishii)
+ <p>Solaris での random() 関数の仕様のために問題があったため、rand() に変更しました。</p>
+ <p>この事象は [pgpool-general: 396] で報告されました。</p>
+
+ <blockquote>
+ <a href="http://www.pgpool.net/pipermail/pgpool-general/2012-April/000397.html">[pgpool-general: 396]</a>
+ strange load balancing issue in Solaris<br>
+ From: Aravinth<br>
+ Date: Sat, 28 Apr 2012 07:26:58 +0530
+ </blockquote>
+</li>
+
+<li><a href="#pool_status">SHOW pool_status</a> の出力結果に、
+ <a href="#BACKEND_DATA_DIRECTORY">backend_data_directory</a>,
+ <a href="#SSL_CA_CERT">ssl_ca_cert</a>,
+ <a href="#SSL_CA_CERT_DIR">ssl_ca_cert_dir</a> がなかったので追加しました。(Nozomi Anzai)
+</li>
+
+<li>パラレルモードでないとき、<a href="#pcp_systemdb_info">pcp_systemdb_info</a> コマンドが
+ segfault してたのを修正しました。(Nozomi Anzai)</li>
+
+<li>"unnamed prepared statment does not exist" というエラーが出るのを修正しました。(Tatsuo Ishii)
+ <p>
+ このエラーは pgpool が内部的に発行しているクエリで発生し、
+ クライアントが発行する unnamed ステートメントを破壊していました。
+ </p>
+ <p>
+ 拡張問い合わせクエリが実行されたときには、内部的に発行するクエリのステートメントとポータルに
+ 名前をつけるようにしました。
+ </p>
+</li>
+
+<li>ホットスタンバイモードでクエリ衝突が起きたときにハングアップするのを修正しました。(Yugo Nagata)
+ <p>これは、以下の手順で再現します。</p>
+<pre>(S1) BEGIN;
+(S1) SELECT * FROM t;
+(S2) DELETE FROM t;
+(S2) VACUUM t;
+</pre>
+</li>
+
+<li>pid ファイルの読み書きを改善しました。(Tatsuo Ishii)</li>
+
+<li><a href="http://www.pgpool.net/pipermail/pgpool-general/2012-June/000676.html">[pgpool-general: 672]</a>
+ で報告された、process_query() のバグを修正しました。(Tatsuo Ishii)
+ <p>
+ プライマリでは処理するデータがなく スタンバイにはある状態のときに、
+ プライマリの処理を待ってしまうことがありました。
+ </p>
+ <blockquote>
+ Subject: <a href="http://www.pgpool.net/pipermail/pgpool-general/2012-June/000676.html">[pgpool-general: 672]</a>
+ Transaction never finishes<br>
+ From: Luiz Pasqual<br>
+ Date: Thu, 28 Jun 2012 09:55:23 -0300
+ </blockquote>
+</li>
+
-<li> ハングアップを起こさないよう pool_process_query() を修正しました。 (Tatsuo Ishii)
+<li>マスタ・スレーブモードでの BEGIN TRANSACTION の扱いを修正しました。(Tatsuo Ishii)
<p>
- プライマリ以外のノードがパケットを送信した際に、pgpool はセッションを終了しようとしてハングアップすることがありました。
- これは ssl_read が エラーではなく EOF を返すようになり、フェイルオーバが実行されなくなっためです。
- 例えば [pgpool-gerenal: 766] では以下のような報告があります。
- </p>
-<pre>
-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.
-</pre>
+ これは <a href="http://www.pgpool.net/pipermail/pgpool-general/2012-July/000719.html">[pgpool-general: 714]</a>
+ で報告されました。
+ </p>
<p>
- このケースでは、pool_process_query() は POOL_END ではなく POOL_ERROR を返すべきです。
+ 3.1 以降、BEGIN TRANSACTION をすべてのノードに送るようにしました。
+ PostgreSQL の仕様では、スタンバイノードには BEGIN TRANSACTION READ WRITE を送ることはできませんが、
+ BEGIN WORK ISOLATION LEVEL SERIALIZABLE についてチェックしておらず、スタンバイノードに送信していました。
+ もちろんこれは誤りで、スタンバイノードが SERIALIZABLE モードになることは許されていません。
+ </p>
+ <p>
+ そのため、BEGIN WORK ISOLATION LEVEL SERIALIZABLE をチェックするようにしました。
</p>
<blockquote>
- Subject: <a href="http://www.pgpool.net/pipermail/pgpool-general/2012-July/000774.html">[pgpool-general: 766]</a>
- Re: pgpool dropping backends too much<br />
- From: Karl von Randow <br />
- Date: Thu, 19 Jul 2012 16:07:41 +1200
+ Subject: <a href="http://www.pgpool.net/pipermail/pgpool-general/2012-July/000719.html">[pgpool-general: 714]</a>
+ Load Balancing / Streaming Replication / Isolation Level serializable<br>
+ From: Philip Hofstetter<br>
+ Date: Wed, 11 Jul 2012 17:04:26 +0200
</blockquote>
</li>
-<li>バックエンドから来たたくさんのクエリ結果を読み込んでいる間に
- フロントエンドが終了したときに、pgpool はバックエンドからの読み込みを続行し、
- すべてのクエリが送られるまでフロントエンドへの書き込みを行ないます。(Tatsuo Ishii)
+<li>SET TRANSACTION ISOLATION LEVELSERIALIZABLE などのクエリはプライマリのみに送るよう
+ send_to_where() を修正しました。(Tatsuo Ishii)
<p>
- クエリ結果が巨大だとこれは非常に長い時間を要します。
- pgpool のセッションを極力早く終了するには、レプリケーションモード以外では、
- フロントエンドへの書き込みに失敗したらエラーを返すように、pool_flush_it を変更しました。
- レプリケーションモードでは、以前どおりの挙動、すなわちバックエンド間での 同期書き込みを行ないます。
+ マスタ・スレーブモードで、以前はこのクエリはプライマリだけではなくスタンバイにも送られていましたが、
+ もちろんこれはエラーとなります。同じようなクエリとして以下のものがあります。
</p>
+ <ul>
+ <li>SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL SERIALIZABLE</li>
+ <li>SET transaction_isolation TO 'serializable'</li>
+ <li>SET default_transaction_isolation TO 'serializable'</li>
+ </ul>
+ <p>
+ これは <a href="http://www.pgpool.net/pipermail/pgpool-general/2012-July/000720.html">[pgpool-general: 715]</a>
+ で報告されました。
<p>
- そのほか、SimpleForwardToFrontend が、pool_write_and_flush がエラーを返してきたときに
- それを無視せず、認識するようにしました。
- </p>
-</li>
+ <blockquote>
+ Subject: <a href="http://www.pgpool.net/pipermail/pgpool-general/2012-July/000720.html">[pgpool-general: 715]</a>
+ Re: Load Balancing / Streaming Replication / Isolation Level serializable<br />
+ From: Tastuo Ishii<br />
+ Date: Thu, 12 Jul 2012 00:16:58 +0900
+ </blockquote>
+</li>
</ul>
-<hr>
-
-<h2><a name="release3.1.2"></a>3.1.3 (hatsuiboshi) 2012/01/31</h2>
+<h2><a name="release3.1.3"></a>3.1.3 (hatsuiboshi) 2012/01/31</h2>
<h3>概要</h3>
<p>
このバージョンは3.1.2に対するバグ修正リリースです。
@@ -6348,7 +7429,398 @@ Date: Wed, 05 Oct 2011 15:15:07 -0700
</li><li>pgpool-regclass()をPostgreSQL 9.1でコンパイルできるようにしました(Tatsuo Ishii)
</li><li>英語版と日本語版のpgpool-IIマニュアルを更新、同期しました(Tatsuo Ishii)
</li></ul>
-<p></p>
+
+<hr>
+
+<h2>3.0.10 (umiyameboshi) 2013/2/8</h2>
+<h3>概要</h3>
+<p>
+このバージョンでは、3.0.9における様々なバグが修正されています。
+</p>
+
+<h3>バグ修正</h3>
+<ul>
+
+<li>md5 認証で競合が発生する不具合が修正されました。(Tatsuo Ishii)
+<p>
+ pool_passwd のファイル識別子は pgpool の親プロセスで開かれたものが子プロセス
+ に引き継がれてます。複数の接続で同時に md5 認証を行う際には、pool_get_passwd が
+ 呼ばれ、ファイル識別子が走査されますが、ファイル識別子が共有されるために md5 認証
+ が失敗することがありました。この問題は、個々の子プロセスで pool_passwd ファイルを
+ 開き直すことで解決されました。
+</p>
+<p>
+ この問題は [pgpool-general:1141] にて、Jason Slagle さんによって報告・解析されました。
+</p>
+<blockquote>
+ [pgpool-general: 1141] Possible race condition in pool_get_passwd<br />
+ From: Jason Slagle<br />
+ Date: Sun, 28 Oct 2012 01:12:52 -0400<br />
+ <a href="http://www.sraoss.jp/pipermail/pgpool-general/2012-October/001160.html">
+ http://www.sraoss.jp/pipermail/pgpool-general/2012-October/001160.html</a>
+</blockquote>
+</li>
+
+<li>pool_send_severity_message() で未初期化のメモリを使用しないよう修正しました。
+ (Tatsuo Ishii)
+<p>
+ このバグによりセグメンテーション違反が発生することがありました。
+ バグトラック #33 に投稿された valgrind 実行結果（dudee さんによる）にて報告されました。
+</p>
+<blockquote>
+ #33 pgpool-II 3.2.1 segfault<br />
+ Reporter: dudee
+ Date: 2012-10-30 19:16
+ <a href="http://www.pgpool.net/mantisbt/view.php?id=33">
+ http://www.pgpool.net/mantisbt/view.php?id=33</a>
+</blockquote>
+</li>
+
+<li>通常のテーブルと同名の一時テーブルがあるときに、クエリキャッシュの結果が不正になる
+ バグを修正しました。 (Tatsuo Ishii)
+<p>
+ 以下はバグを引き起こす処理の例です。
+</p>
+<pre>
+ 1) CREATE TABLE t1(i int); -- 通常のテーブルを作成
+ 2) INSERT INTO t1 VALUES(1);
+ 3) SELECT * FROM t1; -- クエリキャッシュが作成される
+ 4) CREATE TEMP TABLE t1(i int); -- 一時テーブルの作成
+ 5) SELECT * FROM t1; -- 誤ったクエリキャッシュが作成される!
+</pre>
+<p>
+ #3 で t1 のキャッシュが生成されますが、#5 でこれが不正に使われており、一時テーブル t1 が
+ 一時テーブルと見なされていないのが問題でした。
+</p>
+</li>
+
+<li>pcp または worker 子プロセスの終了イベントを受信したときに、reaper() で wait3()
+ ループを終了しないように修正しました。 (Tatsuo Ishii)
+<p>
+ 修正前は、reaper() は子プロセスの終了イベントを誤って無視してしまい、ゾンビプロセスを作り、
+ 新しいプロセスを生成できないことがありました。
+</p>
+<p>
+ この問題は[pgpool-general-jp: 1123]にて、後藤さんより報告され、修正の示唆を頂きました。
+</p>
+<blockquote>
+ [pgpool-general-jp: 1123] Re: オンラインリカバリ後にゾンビプロセスになる<br />
+ From: GOTO, Daisuke
+ Date: Wed, 21 Nov 2012 19:56:17 +0900
+ <a href="http://www.sraoss.jp/pipermail/pgpool-general-jp/2012-November/001122.html">
+ http://www.sraoss.jp/pipermail/pgpool-general-jp/2012-November/001122.html</a>
+</blockquote>
+</li>
+
+<li>pool_search_relcache() が REAL_MASTER_NODE_ID ではなく MASTER, MASTER_NODE_ID
+ を使用するように修正しました。 (Tatsuo Ishii)
+<p>
+ ストリーミングレプリケーションモードで 0 番ノードがフェールバックした場合、pgpool は
+ 子プロセスを再起動しません。そのとき、REAL_MASTER_NODE_ID は 0 番ノードの接続
+ 情報を探しにいきますが、これはバックエンドへの新しい接続が確立するまで存在しません。
+ そのため、接続情報の参照によって、セグメンテーションフォルトが発生していました。
+ この状況でも、MASTER または MASTER_NODE_ID は以前にキャッシュされたマスター
+ ノード ID を見にいくため、安全に使うことが出来ます。
+</p>
+</li>
+
+<li>ストリーミングレプリケーションモードでレプリケーション遅延が大きくなったときに、
+ "portal not found" エラーが発生するバグを修正しました。 (Tatsuo Ishii)
+<p>
+ これは delay_threshold が導入以来、ずっと存在していたバグです。
+</p>
+<p>
+ bind, describe, execute の実行時に遅延が域値を越えた場合、送り先の DB ノードは
+ 変更されていました。しかし、parse がそれとは異なるノードに送られていた場合、送り先ノードには
+ parse された ステートメントやポータルが存在しないために bind, describe, execute は
+ 失敗していました。 修正後は、大きな遅延が発生した場合でも、これらは parse が実行された
+ ノード以外には送られないようになりました。
+</p>
+</li>
+
+<li>pg_md5 で、ユーザからのパスワード入力の後には改行するように修正しました。 (Yugo Nagata)</li>
+
+<li>watchdog のポート番号が既に使用されていた場合にエラーメッセージを出力するよう修正しました。
+ (Yugo Nagata)
+<p>
+ この問題は [pgpool-general: 1167] で Will Ferguson さんによって報告されました。
+</p>
+<blockquote>
+ [pgpool-general: 1167] Re: Watchdog error - wd_init: delegate_IP already exists<br />
+ From: Will Ferguson
+ Date: Tue, 6 Nov 2012 13:03:36 +0000
+ <a href="http://www.sraoss.jp/pipermail/pgpool-general/2012-November/001186.html">
+ http://www.sraoss.jp/pipermail/pgpool-general/2012-November/001186.html</a>
+</blockquote>
+</li>
+
+<li>コネクションプールが存在しない場合には、child_exit() が send_frontend_exits()
+ を呼ばないよう修正しました。 (Tatsuo Ishii)
+<p>
+ send_frontend_exits() は pool_connection_pool で指されてるオブジェクトを参照しているため、
+ 修正前にはセグメンテーションフォルトが発生していました。バグトラック #44 の tuomas さんの報告によります。
+</p>
+<blockquote>
+ #44 pgpool went haywire after slave shutdown triggering master failover<br />
+ Reporter: tuomas
+ Date: 2012-12-11 00:33
+ <a href="http://www.pgpool.net/mantisbt/view.php?id=44">
+ http://www.pgpool.net/mantisbt/view.php?id=44</a>
+</blockquote>
+</li>
+
+<li>pool_read() が不正なパケットを読み込んだ場合に、read_startup_packet() がアラームクロック
+ をリセットして StartupPacket を解放するよう修正しました。 (Nozomi Anzai)
+<p>
+ 修正前は、pgpool ポートの監視を行うプログラムの接続により、認証のタイムアウトが発生していました。
+ この問題は、バグトラック #35 で報告されました。
+</p>
+<blockquote>
+ #35 Authentication is timeout<br />
+ Reporter: tuomas
+ Date: 2012-11-20 11:54
+ <a href="http://www.pgpool.net/mantisbt/view.php?id=35">
+ http://www.pgpool.net/mantisbt/view.php?id=35</a>
+</blockquote>
+</li>
+
+<li>pool_open() が誤ったバッファポインタを初期化していたバグを修正しました。 (Tatsuo Ishii)
+<p>
+ このポインタは事前に memset() によって初期化されているため、実際にはこのバグによる害は
+ ありませんでした。
+</p>
+</li>
+
+<li>ヘルプメッセージに -f オプションの説明を追加しました。 (Tatsuo Ishii)</li>
+
+<li>ドキュメント中の、「パラメータ変更に再起動が必要かどうか」の情報を追記・修正しました。(Yugo Nagata)</li>
+
+<li>pool_passwd に関する記述を pgpool_conf.sample*、および,ドキュメントに追加しました。 (Yugo Nagata)</li>
+
+</ul>
+
+<h2>3.0.9 (umiyameboshi) 2012/10/12</h2>
+<h3>概要</h3>
+<p>
+このバージョンでは、3.0.8における様々なバグが修正されています。
+</p>
+
+<h3>バグ修正</h3>
+<ul>
+<li>read_startup_packet() を修正しました。(Tatsuo Ishii)
+ <p>
+ パケット長が 0 以下のときは直ちに return するべきでしたが、そうなっていなく、
+ メモリ確保時にエラーになっていました。
+ </p>
+ <p>これは pgpool-general:886 を参照してください。また、キャンセルアラームを追加しました。</p>
+ <blockquote>
+ [pgpool-general: 886] read_startup_packet: out of memory<br>
+ From: Lonni J Friedman<br>
+ Date: Wed, 8 Aug 2012 10:18:15 -0700<br>
+ <a href="http://www.sraoss.jp/pipermail/pgpool-general/2012-August/000896.html">
+ http://www.sraoss.jp/pipermail/pgpool-general/2012-August/000896.html</a>
+ </blockquote>
+</li>
+
+<li>s_do_auth() に NOTICE メッセージを追加しました。(Tatsuo Ishii)
+ <p>これがなかったために、ヘルスチェックが false アラームを受け取りフェイルオーバしていました。</p>
+ <p>これはバグトラックで報告されました。</p>
+ <blockquote>
+ #25 s_do_auth doesn't handle NoticeResponse (N) message<br>
+ Date: 2012-08-28 03:57<br>
+ Reporter: singh.gurjeet<br>
+ <a href="http://www.pgpool.net/mantisbt/view.php?id=25">http://www.pgpool.net/mantisbt/view.php?id=25</a>
+ </blockquote>
+</li>
+
+<li>s_do_auth() から、不要かつ混乱をまねくデバッグメッセージを削除しました。(Tatsuo Ishii)</li>
+
+<li>SSL モードでの無限ループを修正しました。 (Tatsuo Ishii)
+ <p>
+ フロントエンドの SSL レイヤで溜っているデータがあるとき、
+ pool_process_query() がバックエンドに溜っているデータをチェックします。
+ もしそれが無かったときは再度ループして、フロントエンド/バックエンドがバッファを受け取っていないか
+ is_cache_empty() を以ってチェックします。
+ しかし、フロントエンドの SSL レイヤでデータが溜っているのを一度検知すると、
+ バックエンドに行ってまたチェックしようとします（無限ループ）。
+ </p>
+ <p>
+ これを解決するには、フロントエンドの SSL レイヤに溜っているデータがあり
+ かつ クエリが実行中でなければ、ProcessFrontendResponse() を呼んで
+ フロントエンドへの新しいリクエストをするようにしました。
+</p>
+</li>
+
+<li>is_system_catalog() で、可能ならば pgpool_regclass を使うようにしました。(Tatsuo Ishii)</li>
+
+<li>pool_get_insert_table_name() のメモリリークを修正しました。(Tatsuo Ishii)
+ <p>
+ nodeToString() でセッションコンテクストのメモリコンテクストを使ったあと、
+ セッション終了までは、メモリを開放していませんでした。
+ </p>
+ <p>詳しくはバグトラックをご覧ください。</p>
+ <blockquote>
+ #24 Severe memory leak in an OLTP environment<br>
+ Date: 2012-08-28 03:43<br>
+ Reporter: singh.gurjeet<br>
+ <a href="http://www.pgpool.net/mantisbt/view.php?id=24">http://www.pgpool.net/mantisbt/view.php?id=24</a>
+ </blockquote>
+</li>
+
+<li>do_query() のセグメンテーションフォルトを修正しました。(Tatsuo Ishii)
+ <p>
+ クエリキャッシュが有効で拡張問い合わせが使われているとき、do_query() はシステムカタログに接続し、
+ pool_read2() を使います。
+ しかし、parse メッセージパケットを Parse() で取得し、パケットの内容が pool_read2() のバッファにあります。
+ このため、do_query() はパケットの内容を分割できず、セグメンテーションフォルトを引き起こしていました。
+ </p>
+ <p>
+ これを解決するために、メモリを確保し、パケット内容をコピーし、Parse() を飛ばすようにしました。
+ ただし、パケットの中にはクエリコンテクストが参照しているクエリ文字列も含まれています。
+ そのため、このクエリ文字列をコピーしてポインタをクエリコンテクストに保持する必要があります。
+ </p>
+ <p>
+ これは、Parse() だけの話でなく、他のプロトコルモジュールにもある問題と考えています。
+ 本修正はそれらにも適用しますが、そのためには、ProcessFrontendResponse() を変更します。
+ </p>
+
+ <p>この問題はバグトラック #21 で報告されました。</p>
+ <blockquote>
+ #21 pgpool-II 3.2.0 cannot execute sql through jdbc<br>
+ Date: 2012-08-17 16:31<br>
+ Reporter: elisechiang<br>
+ <a href="http://www.pgpool.net/mantisbt/view.php?id=21">http://www.pgpool.net/mantisbt/view.php?id=21</a>
+ </blockquote>
+</ul>
+
+<h2>3.0.8 (umiyameboshi) 2012/08/06</h2>
+
+<ul>
+<li>Solaris でのロードバランスを修正しました。(Tatsuo Ishii)
+ <p>Solaris での random() 関数の仕様のために問題があったため、rand() に変更しました。</p>
+ <p>この事象は [pgpool-general: 396] で報告されました。</p>
+
+ <blockquote>
+ <a href="http://www.pgpool.net/pipermail/pgpool-general/2012-April/000397.html">[pgpool-general: 396]</a>
+ strange load balancing issue in Solaris<br>
+ From: Aravinth<br>
+ Date: Sat, 28 Apr 2012 07:26:58 +0530
+ </blockquote>
+</li>
+
+<li>パラレルモードでないとき、<a href="#pcp_systemdb_info">pcp_systemdb_info</a> コマンドが
+ segfault してたのを修正しました。(Nozomi Anzai)</li>
+
+<li>"unnamed prepared statment does not exist" というエラーが出るのを修正しました。(Tatsuo Ishii)
+ <p>
+ このエラーは pgpool が内部的に発行しているクエリで発生し、
+ クライアントが発行する unnamed ステートメントを破壊していました。
+ </p>
+ <p>
+ 拡張問い合わせクエリが実行されたときには、内部的に発行するクエリのステートメントとポータルに
+ 名前をつけるようにしました。
+ </p>
+</li>
+
+<li>pid ファイルの読み書きを改善しました。(Tatsuo Ishii)</li>
+
+<li><a href="http://www.pgpool.net/pipermail/pgpool-general/2012-June/000676.html">[pgpool-general: 672]</a>
+ で報告された、process_query() のバグを修正しました。(Tatsuo Ishii)
+ <p>
+ プライマリでは処理するデータがなく スタンバイにはある状態のときに、
+ プライマリの処理を待ってしまうことがありました。
+ </p>
+ <blockquote>
+ Subject: <a href="http://www.pgpool.net/pipermail/pgpool-general/2012-June/000676.html">[pgpool-general: 672]</a>
+ Transaction never finishes<br>
+ From: Luiz Pasqual<br>
+ Date: Thu, 28 Jun 2012 09:55:23 -0300
+ </blockquote>
+</li>
+
+<li>wait_for_query_response() が、frontend がないときには何もしないように修正しました。(Tatsuo Ishii)
+ <p>バックエンドをリセットする reset_query_list のクエリを実行に時間がかかったときに
+ 発生する可能性があり、またクラッシュすることがありました。</p>
+</li>
+</ul>
+
+<h2>3.0.7 (umiyameboshi) 2012/04/23</h2>
+<h3>概要</h3>
+<p>
+このバージョンでは、3.0.6におけるバグが修正されています。
+</p>
+
+<h3>バグ修正</h3>
+<ul>
+<li>m4 ファイルを追加しました。これにより古い OS で起こるコンパイルの問題を回避できます。(Tatsuo Ishii)</li>
+<li>シグナル割り込みによって、セマフォが解放されないままプロセスが終了することがあるバグを修正しました。(Tatsuo Ishii)</li>
+<li>reset_query 時のメモリリークを修正しました。 (Tatsuo Ishii)</li>
+<li>以下の場合に parser memory をリストアするよう SimpleQuery() 関数を修正しました。
+ <ol>
+ <li>組み込み show コマンド使用時</li>
+ <li>パラレルクエリモード</li>
+ <li>クエリキャッシュ使用時</li>
+ </ol>
+ さもないと、後で不正な palloc を発生する障害が起きるからです。(Tatsuo Ishii)
+</li>
+<li>pool_ssl_read() 関数が大きいサイズのデータを読み込めるよう修正しました。以下の報告によるものです。(Tatsuo Ishii)<br />
+ <a href=http://www.pgpool.net/pipermail/pgpool-general/2012-March/000299.html">
+ http://www.pgpool.net/pipermail/pgpool-general/2012-March/000299.html</a></li>
+
+<li>PREPARE 文でエラーが起きた際に発生するハングアップを修正しました。Tominari Katsumata さんの報告に基づきます。(Toshihiro Kitagagwa)</li>
+</ul>
+
+<h2>3.0.6 (umiyameboshi) 2012/01/31</h2>
+<h3>概要</h3>
+<p>
+このバージョンでは、3.0.5におけるバグが修正されています。
+</p>
+
+<h3>バグ修正</h3>
+<ul>
+<li>以下のスレッドで報告されている無限ループを修正しました。(Tatsuo Ishii)<br/>
+ <a href="http://www.pgpool.net/pipermail/pgpool-general/2011-December/000099.html">
+ http://www.pgpool.net/pipermail/pgpool-genral/2011-December/000099.html</a><br/>
+ プライマリからから受け取ったバッファが空である一方で、スタンバイのどれかが
+ 受け取ったバッファが空でないとき、pgpool へのパケットが送られてしまう、
+ という可能性が考慮されていませんでした。<br/>
+ この事象は例えば、postgresql.conf を再読み込みしたときに発生することがありました。<br/>
+ この修正では、スタンバイからしか受け取れなかったバッファは無視するようにしました。
+</li>
+</ul>
+
+<h2>3.0.5 (umiyameboshi) 2011/10/31</h2>
+<h3>概要</h3>
+<p>
+このバージョンでは、3.0.4における様々なバグが修正されています。
+</p>
+
+<h3>バグ修正</h3>
+<ul>
+<li>空のクエリの処理に関するバグを修正しました。空のクエリはSELECTクエリと同じ扱いになります。
+ この修正は、空のクエリのあとのロードバランスを可能にします(Kitagawa)</li>
+<li>カラム定義が"DEFAULT nextval(('"x_seq"'::text)::regclass)"のようになっていても
+ insert_lockが正しく動作するように修正しました(Kitagawa)</li>
+<li>pgpool-IIマニュアルのbackend_weightに関する説明を修正しました。
+ それは、pgpool.confの再読み込みで変更できます(Tatsuo)</li>
+<li>rawモードでノードを復帰させたときにノードの状態が更新されないバグを修正しました(Guillaume Lelarge)</li>
+<li>FOR SHARE/UPDATE句のあるサブクエリを含むSELECTがスレーブ(standby)に送られるバグを修正しました(Tatsuo)</li>
+<li>PREPARE文でデフォルト値のタイムスタンプ書き換えに失敗するバグを修正しました。
+ これは以前は動作していましたが、3.0で動作しなくなっていました(Kitagawa)</li>
+<li>rawモード、enable_hbaが無効、バックエンドが2台以上の場合に
+ pgpool子プロセスがクラッシュするのを修正しました(Kitagawa)</li>
+<li>メモリリークをいくつか修正しました(Kitagawa)</li>
+</ul>
+
+<h3>改良</h3>
+<ul>
+<li>カラムのデフォルト値に任意の式を指定してもタイムスタンプ書き換えが動作するようにしました。
+以前は、now()が含まれているものを検知すると、単純にそれをnow()で置き換えてました。
+これは、デフォルト値の誤った書き換えを引き起こします。例えば、timezone('utc'::text, now())です。
+しかし、これは簡易プロトコルのみへの適用であることに注意してください。
+拡張プロトコル(例えばJava, PHP PDO)または、SQLの"PREPARE"にはまだ適用されていません(Tatsuo)</li>
+<li>エラーメッセージ"do_md5: read_password_packet failed"をデバッグレベルにしました(Kitagawa)</li>
+</ul>
<h2>3.0.4 (umiyameboshi) 2011/06/01</h2>
<h3>概要</h3>
[parent: 325dced56b76]