Fix memory leak in certain error case.

Per Coverity report "1111457 Resource leak".

Fix memory leak when do_query() fails.

Per Coverity report "1111444 Resource leak".

Fix data inconsistency problem with native replication mode + extended protocol case.

It is reported that concurrent INSERT using JDBC driver causes data
difference among database node. This only happens following conditions
are all met:

1) Native replication mode
2) Extended protocol used
3) The portal created by parse message is reused by bind message
4) autocommit is on
5) SERIAL (sequence) is used

Pgpool-II's parse message function knows it has to lock the target
table when INSERT (plus #5) is issued by clients. Unfortunately bind
message function did not know it. Once parse/bind/execute finishes,
pgpool releases the lock obtained by parse because of #4. JDBC wants
to reuse the portal and starts the cycle from bind message, which does
not obtain lock. As as result, lock-free INSERT are floating around
which causes data inconsistency of course.  The solution is, lock the
table in bind phase.

For this bind needs to issue LOCK in extended protocol. This was a
little bit hard because the module (do_command()) to issue internal
SQL command (other than SELECT) does not support extended protocol. To
solve the problem do_query() is modified so that it accepts other than
SELECT because it already accepts extended protocol. The modification
is minimum and is only tested for the case called from insert_lock(). I
do not recommend to replace every occurrence of do_command() with
do_query() at this point.

BTW the reason why the bug is not reported is, most users uses JDBC
with auto commit = off. In this case, the lock obtained by parse
persists until user explicitly issues commit or rollback.

Per bug report by Steve Kuekes in [pgpool-general: 2142].

Avoid calling find_primary_node_repeatedly() when standby node goes down.

This will reduce the time to failover. Per bug #75, patch modified by
Tatsuo Ishii.

Modify descriptions about restrictions of parallel mode

Muliple rows INSERT using VALUES are not supported in parallel mode.

Fix segfault when pgpool.conf does not set log_standby_delay.

This is caused by wrong initialization for log_standby_delay in
pool_config.l. Per bug#74.

Remove -lcompat because it confuses FreeBSD per bug#15.

Replace pg_config by $(PG_CONFIG) in Makefiles so it can be overridden at build time when compiling for different PG major versions.

Patch contributed by Christoph Berg ([pgpool-general: 2127]).

Fix incorrect time stamp rewriting in replication mode for certain time zones.

Time stamp rewriting calls "SELECT now()" to get current
time. Unfortunately the buffer for the current time is too small for
certain time zones such as "02:30". Note that non-30-minutes-time-zone
such as "0900" does not reveal the problem. This explains why we
haven't the bug report until today. Bug reported in [pgpool-general:
2113] and fix provided by Sean Hogan.

Prepare 3.1.9

Prepare 3.1.9

Fix a typo of the japanese document

Fix bug in parsing prepared statements with transaction handling in replication mode reported in [pgpool-general: 1877].

Parse() automatically starts a transaction for non SELEC query to keep
consistency among nodes in replication mode. But it does not set
allow_close_transaction variable. If wrong query comes in, the
transaction goes into an abort state but pgpool does not close the
transaction. Thus next query causes error because the transaction is
still in abort status.

Fix mistake in ssh command.

Prepare 3.1.8

Fix to verify the backend node number in pcp_recovery_node

When an invalid number is used, null value is passed as an arguments
of recovery script, and this causes a malfunction. In especially,
rsync may delete unrelated files in basebackup scripts.

Add ssl_ca_cert and ssl_ca_cert_dir descriptions to the japanese document

Move ssl_ca_cert and ssl_ca_cert_dir descriptions to the SSL section

Merge branch 'V3_1_STABLE' of ssh://git.postgresql.org/pgpool2 into V3_1_STABLE

Fix segmentation fault of child that occurs when startup packet has
no PostgreSQL user information.

When a startup packet has no PostgreSQL user specified, pgpool-II
terminated abnormally. You can reproduce it by

 $ psql -p 9999 -U ''

If enable_pool_hba is on, a child process terminates by segmentation
fault. Otherwise if enable_pool_hba is off, the error message is

 ERROR: pool_discard_cp: cannot get connection pool for user (null) database (null)

In both cases, psql terminates with no message on frontend.

To resolve it, if PostgreSQL user is not specified in startup packet,
the message as following is output to both log and frontend. This is
the same behavior as PostgreSQL.

 FATAL: no PostgreSQL user name specified in startup packet

Fix pg_md5 command crash.

Fix contributed by Muhammad Usama(from [pgpool-hackers: 302])

While looking at the pgpool-II code I found a potential crash or stack
smash in pg_md5 utility.
The problem is update_pool_passwd() calls pg_md5_encrypt() function to get
the md5 password, and the password format generated by pg_md5_encrypt()
function is
"md5" followed by 32-hex digits, which sums up to 35 characters while the
host variable defined in update_pool_passwd() function to hold this
password can contain maximum 32 characters.

Register pgpool_regclass in pg_catalog schema.  This is necessary to
deal with clients which restricts schema search path to pg_catalog
only. Postgres_fdw is such a client.

Update copyright year.

Fix bug with do_query which causes hung in extended protocol.

When insert lock is enabled and pgpool_catalog.insert_lock exists,
pgpool-II looks for the row which matches the oid of the target
table. If non, pgpool-II will insert the row to obtain a row lock.
The bug was in the process looking for the row. If extended protocol
is used, pgpool-II was waiting for the row data forever which will
never come because there's no such a row in the table. The fix is when
"command complete" received, let pgpool-II regards as if "data row"
received. The bug was introduced when 3.2.1 was released. A
reproducable test case is provided by Karsten Düsterloh.  See
[pgpool-general: 1684] for more details.

Fix unnecessary degeneration caused by error on commit.

A commit could fail by certain condition including deferred
triggers. If the trigger is related to DML, only the primary fails
because standbys never gets executed such DML in streaming replication
mode. This lead to "kind mismatch error", which causes failover or
session close. This is reported in bug #60, and the reporter claims
that it should not trigger the failover or the session close, rather
continue the session and just report the error on the primary. I think
his complain is fair since in replication mode, such error does not
cause failover or session close. So I make read_kind_from_backend() a
little smarter to not cause failover or session close if only primary
fails on commit in streaming replication mode.

Fix do_query() not to hang when PostgreSQL returns an error.

The typical symptom is "I see SELECT is keep on running according to
pg_stat_activity".  To fix this pgpool-II just exits the process and
kill the existig connection.  This is not gentle but at this point I
believe this is the best solution. Here is an excerpt from source
code:
/*
 * This is fatal. Because: If we operate extended
 * query, backend would not accept subsequent commands
 * until "sync" message issued. However, if sync
 * message issued, unnamed statement/unnamed portal
 * will disappear and will cause lots of problems.  If
 * we do not operate extended query, ongoing
 * transaction is aborted, and subsequent query would
 * not accepted.  In summary there's no transparent
 * way for frontend to handle error case. The only way
 * is closing this session.
 */

Comment out backend1 data. This should have been done before since
pgpool.conf.sample has already done this.

Fix description on SSL.

Fix %H in trigger_failover() to assign new primary node.

Before it assigns the result of get_next_master_node(), which is not
correct in streaming replication mode, which is not necessarily same
as the primary node id. This causes problem in follow_master_command.
Please note that %m(new master node) properly uses passed new
master(or primary) node id. See [pgpool-hackers: 219] for more
details.

Consider timeout waiting for compeletion of failback request in on line recovery.

This will prevent the recovery operation continues forever and we
cannot even shutdown pgpool main process. This could happen especially
while executing follow master command. At this moment, the timeout is
fixed value(5 seconds). This should be enough for the operation since
it does not imply any I/O or DB operation. Before it waited
forever. Problem is, it is possible that right after failover, the
failback request sent can be lost. In the long run we should fix it
but at this moment I prefer to band aid the problem because the fix
will not be trivial.

Add mention about "-D" option.

Prepare 3.1.7.

Prepare 3.1.7

Prepare 3.1.7.

Prepare 3.1.7.

Fix error message mistakes in detect_postmaster_down_error().

Fix pool_has_pgpool_regclass() to check execute privilege of pgpool_regclass().

Bug track #53 shows that if pgpool cannot execute pgpool_regclass(),
the connection to backend hangs. You can reproduce the problem by just
dropping the execute privilege from pgpool_regclass and do some insert
in native replication mode:

2013-04-07 11:47:54 LOG:   pid 11799: DB node id: 0 backend pid: 11918 statement: SELECT count(*) FROM pg_catalog.pg_proc AS p WHERE p.proname = 'pgpool_regclass'
2013-04-07 11:47:54 LOG:   pid 11799: DB node id: 0 backend pid: 11918 statement: SELECT count(*) FROM pg_catalog.pg_attrdef AS d, pg_catalog.pg_class AS c WHERE d.adrelid = c.oid AND d.adsrc ~ 'nextval' AND c.oid = pgpool_regclass('t1')
2013-04-07 11:47:54 ERROR: pid 11799: do_query: error message from backend: permission denied for function pgpool_regclass
2013-04-07 11:47:54 ERROR: pid 11799: pool_search_relcache: do_query failed
2013-04-07 11:47:54 LOG:   pid 11799: DB node id: 0 backend pid: 11918 statement: SELECT attname, d.adsrc, coalesce((d.ads

To fix the problem, use has_function_privilege() for the query and
passes username to pool_search_relcache() instead of
"pgpool_regclass"(this is just a fake parameter) as the search
key.

Merge branch 'V3_1_STABLE' of ssh://git.postgresql.org/pgpool2 into V3_1_STABLE

Adopt PostgreSQL 9.3. Patch contributed by Asif Rehman.
Slight editing by Tatsuo Ishii.

Fix to calculate replication delay only if standby server is
behind from the primay server.

When the primary server is behind from standby server, negative
value of delay is calculated and the value is assigned to unsigned
variable. It causes a log message informing negative replication
delay. And what is worse, it also causes SELECT queries to be sent
to the primary in load balance even though there are no replication
delay in fact.

The problem is reported and analyzed by Saitoh Hidenori in
[pgpoolgenera-jp: 1145]. (in Japanese)

Fix bug with md5 auth long user name handling.

If user name is longer than 32 bytes, md5 authentication doesn't work.
Problem reported in [pgpool-general: 1526] [pgPool-II 3.2.3] MD5
authentication and username longer than 32 characters.

Fix long standing bug with timestamp rewriting code for processing
extended protocol.

Parse() allocate memory using palloc() while rewriting the parse
message.  Problem is, the rewritten message was kept in the data which
is managed by pool_create_sent_message() etc. The function assumes
that all the data is in session context memory. However, palloc()
allocates memory in query context of course, and gets freeed later on
when the query context disappears. And the function tries to free the
memory as well, which causes various problems, including segfault and
double free. To fix this, memory to store rewritten message is
allocated using session context. The bug was there since pgpool-II 3.0
was born.

Problem analysis and patch contributed by Naoya Anzai.

Fix a compiler warning due to a wrong format specifier.

Remove unnecessary release note entry.

Fix version number in document.

Replace double quote to single quote.

Prepare 3.1.6.

Prepare 3.1.6

Update copyright year.

Add pool_passwd option to pgpool.conf.sample, pool_process_reporting.c,
and documents.

Modify documents to correct information of whether a certain parameter
change requires restart.

Fix long standing bug with pool_open(). It initializes wrong buffer
pointer. Actually this is harmless because the pointer is
initialized by prior memset() call, though.

Fix read_startup_packet() to reset alarm and free StartupPacket
when pool_read() returns 0 which means incorrect packet length.

Fix child_exit() to not call send_frontend_exits() if there's no
connection pool, otherwise it segfaults because send_frontend_exits()
referes to objects pointed to by pool_connection_pool.  This could
happen in worker_child while it tries to do s_do_auth() and it calls
pool_read() failed to read backend socket then calls child_exit().
Per bug track #44.

Fix pg_md5 to output "\n" after user inputs password.

Fix long standing bug "portal not found" error when replication delay
is too much in streaming replication mode.  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 pool_search_relcache() to use MASTER or MASTER_NODE_ID macro,
rather than REAL_MASTER_NODE_ID.  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 reaper() not to exit wait3() loop when catches pcp or worker child
exit event. Otherwise reaper() mistakenly ignore some process exit
event and make a risk of creating zombie process and forgetting to
create new process.  Commit a99744560f54f6723799408cd3623a73b2b335e6
should be enough for pcp child case, but not enough for worker process
case. Problem reported and fix suggested by Goto in
[pgpool-general-jp: 1123].

Fix typo

Add a description about "-f" to help message.

Fix pool_send_severity_message() not to use uninitialized memory.
Reported in Bug#33's attached valgrind output:

==20875== Syscall param write(buf) points to uninitialised byte(s)
==20875==    at 0x52680D0: __write_nocancel (syscall-template.S:82)
==20875==    by 0x41CC49: pool_flush_it (pool_stream.c:436)
==20875==    by 0x41CCF8: pool_flush (pool_stream.c:496)
==20875==    by 0x417AE4: pool_send_severity_message (pool_process_query.c:1722)
==20875==    by 0x417C12: pool_send_error_message (pool_process_query.c:1608)
==20875==    by 0x4182A0: read_kind_from_backend (pool_process_query.c:3768)
==20875==    by 0x449098: ProcessBackendResponse (pool_proto_modules.c:2562)
==20875==    by 0x41B9C4: pool_process_query (pool_process_query.c:274)
==20875==    by 0x40B1DF: do_child (child.c:362)
==20875==    by 0x404BD4: fork_a_child (main.c:1243)
==20875==    by 0x40795B: main (main.c:661)
==20875==  Address 0x87cb243 is 275 bytes inside a block of size 8,192 alloc'd
==20875==    at 0x4C244E8: malloc (vg_replace_malloc.c:236)
==20875==    by 0x41CEF4: pool_open (pool_stream.c:68)
==20875==    by 0x40A7B2: do_accept (child.c:784)
==20875==    by 0x40AA2A: do_child (child.c:185)
==20875==    by 0x404BD4: fork_a_child (main.c:1243)
==20875==    by 0x40795B: main (main.c:661)

Fix hung up while repeating pcp_attach_node and pcp_detatch_node
reported in bug track #32 etc. 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.  The fix is, in failover() after sending SOGUSR1 to
pcp child, issue waitpid() to catch the pcp child exit event and
restart new pcp child process.

Fix race condition when using pool_get_passwd. 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.

Note that this patch requires commit d5930588747f1d0759411f494714a7909efe5e35
which allows to reload to recognize md5 password change.
I know this is not fix but the fix above requires this commit.

Prepare 3.1.5

Fix long standing problem with do_query(). 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.

Fix possible memory leak in nodeToString(). 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 memory leak in pool_get_insert_table_name(). If session context's
memory contex is used for nodeToString(), memory is not freed until
session ends.

Fix is_system_catalog to use pgpool_regclass if available.

Fix inifinit loop in SSL mode. 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.

Remove outdated contents of ChangeLog and replace it with
just "See NEWS." per discussion in pgpool-hackers.

Fix long standing memory leak bug with free_select_result
since pgpool-II 2.3 was born in December 2009.
Actually this bug only appears when operated in replication mode
(triggered by timestamp rewriting process by coincidence).
Per bug track:
http://www.pgpool.net/mantisbt/view.php?id=24

Fix HBA section. enable_pool_hba is disabled by default.

Remove unnecessary/confusing debug log from s_do_auth.

Add NOTICE message handling to s_do_auth. 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.

Fix read_startup_packet. 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.

Merge branch 'V3_1_STABLE' of ssh://git.postgresql.org/pgpool2 into V3_1_STABLE

Prepare 3.1.4

Fix send_to_where() when SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
case in streaming replication mode. It is 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].

Remove unused parameter "query" from is_set_transaction_serializable().

Fix bug with treatment of BEGIN TRANSACTION in master/slave
mode. 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 I added check for BEGIN WORK
ISOLATION LEVEL SERIALIZABLE case, with some refactoring because
there's lots of redundant codes.

Fix wait_for_query_response() not to send param status to frontend if
frontend is NULL. This could happen while processing reset_query_list.

Fix pool_process_query() bug reported in [pgpool-general: 672].
> For some reason, this transaction was aborted, client disconnected
> from pgpool, pgpool aborted the transaction on the slave server
> (192.168.10.11) but not on the master (192.168.10.55).
This is caused by the function waits for primary node which does not
have pending data, while standbys have pending data.

Fix function call case. Before it did not change memory context
before calling raw_parser. This will make trouble afterward if
default pool_memory context is destroyed.

Modify read_pid_file() and write_pid_file().  write_pid_file() used to
use fopen() and friends, but it was pointed out that pid file might
not be written to persistent storage in erroneous system. Solution to
this is using fsync() althoug it's a little bit tricky to use with
fopen() and friends, so I decided to rewrite them to use open(2) and
friends.  Changes made to read_pid_file() as well, but this is rather
for consistency of coding.

Fix to send an error message to the frontend when connection is terminated
due to conflict with recovery.

Fix hangup when query conflict occurs in Hot-Standby mode.
- Query example to reproduce:
  (S1) BEGIN;
  (S1) SELECT * FROM t;
  (S2) DELETE FROM t;
  (S2) VACUUM t;

Fix SmpleQuery() to handle errors by calling check_errors().
- Previously, check_errors() was called only in Execute().

 Please enter the commit message for your changes. Lines starting

Fix is_system_catalog(). Its relcach was accidently defined as "session local".

Fix "unnamed prepared statment does not exist" error.  This is caused
by pgpool's internal query, which breaks client's unnamed statements.
To fix this, if extended query is used (calling
pool_is_doing_extended_query_message()), named statement/portal for
internal are used for internal query.

Update copyright year.

Fix segfault of pcp_systemdb_info not in parallel mode and when enable_query_cache = 'off'.

Add params to the result of "SHOW pool_status": backend_data_directory, ssl_ca_cert, ssl_ca_cert_dir.

Add desctiption of pcp_pool_status command.

Adopt PostgreSQL 9.2.

Fix load balance in Solaris.  If compiled in Solaris, use
srand()/rand() instead of srandom()/random().  Problem is, random() in
Solaris does not respect RAND_MAX (it's 2^16-1 in Solaris). So using
random() in Solaris results in strange load balancing calculation.
Use srand()/rand() instead although they produce lesser quality random
numbers. Problem reported at [pgpool-general: 396].

Fix pool_send_and_wait() to send or not to send commit/abort depending
on the transaction state on each node. 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].

Modify mistaken release date and version no. in pgpool-ja.html.

Prepare 3.1.3

Prepare 3.1.3

Prepare 3.1.3

Prepare 3.1.3