Avoid to send queries to unrelated nodes in streaming replication mode.

Pgpool-II sends certain queries, such as BEGIN, END and SET commands to
all of DB nodes. However in streaming replication mode, only primary
node and at most one standby node are only concerned (if primacy node
is selected as the load balance node, only 1 node is concerned).

Think about 3 nodes cluster. Node 0 is primary, node 1 and 2 are
standby servers. Node 1 is selected as the load balance node. In this
case no query is needed to be sent to node 2, because DMLs are sent to
node 0 while SELECTs are sent to node 1.

For this purpose pool_setall_node_to_be_sent() is modified to only set
related nodes on the where_to_send node map. See [pgpool-hackers: 464]
for more details.
Fix possible buffer overrun problem and memory leak.

To fix the memory leak problem, now libs/pcp/libpcp.a links
strlcpy.o. For this purpose, libs/pcp/Makefile.am is also modified.
Per Coverity 1111465 and 1111482.
Fix possible buffer overrun.

Replace strcpy() with strlcpy(). Per Coverity report 1111478, 1111480,
1111481.
Add dubug messages for analyzing errors in if_up_cmd
Fix freeing NULL.

free_systemdb_info() should check if the argument is NULL or not.
Per Coverity 1111384.
Do not enable query cache on materialized views.

Per bug #95.
Fix memory leak.

Per Coverity 1111446.
Fix a segmentation fault in parallel mode with system_db_hostname is empty

When system_db_hostname is empty, unix domain socket should be used.
However, the directory containing the socket file was't specified in this
case, and the initialization of system DB connection failed. This caused
segmentation fault, when processing a query to system db.
Fix to output debug messages in processing pgpool.conf with -d option

In previous, debug messages in pool_get_config() ware not output
even when -d option was used.
Fix JDBC exception of prepared statement including now() in replication mode

With JDBC, when a prepared statement is executed more than PreparedThreshold times,
the statement is named and Describe message is sent after Parse. With named statement,
pgpool rewrite now() to parameter at Parse in replication mode. Hence, rewritten query
has additonal parameter than original. However, ParameterDescription message sent to
frontend, which is response of Describe, should include OIDs of the same number os
original query's parameters. Otherwize, JDBC raises ArrayIndexoutOfBoundsException.
Fix backend error of prepared statement including now() via JDBC in replication mode

With JDBC, when a prepared statement is executed more than PreparedThreshold times,
the statement is named, and pgpool rewrites now() to parameter in replication mode.
Hence, rewritten query has additonal parameter, so Bind message also should inclued
additional parameter format codes. However, when the number of original parameter was
one, pgpool didn't handle this. This caused a error like "incorrect binary data format
in bind parameter 2" on backend.
Fix a bug of regression test of JDBC that shows OK even when test fails
Add a test of PrepareThreshold to JDBC regression test
Add description about parallel mode doesn't support PREPARE
Fix a typo of pgpool.spec
Fix worker child process keeps failing when there's no primary backend.

Problem identified and fix contributed by Junegunn Choi.

From pgpool-hackers: 471
==================================================================
Hi,

I've identified that worker child process keeps failing when
there's no primary backend in the cluster at the moment.

We're running a streaming replication cluster with 3 nodes. Because of
a sudden H/W problem of the master server, I detached the node from
pgpool using `pcp_detach_node` command, in order to temporarily make
the cluster read-only. pgpool then worked as expected, it rejected
write requests and still served read requests using the remaining two
standby nodes. The problem is, the worker child process which checks
for replication lag, keeps failing and being recreated without a
pause. So naturally it generates massive amount of log messages, and
keeps creating backend connections, which in turn leaves a large
number of TIME_WAIT sockets on the system.

2014-03-27 15:33:57 LOG:   pid: 21996 fork a new worker child pid 28453
2014-03-27 15:33:57 ERROR: pid: 28453 do_query: error message from backend:
recovery is in progress. Exit this session.
2014-03-27 15:33:57 LOG:   pid: 21996 worker child 28453 exits with status
256
2014-03-27 15:33:57 LOG:   pid: 21996 fork a new worker child pid 28455
2014-03-27 15:33:57 ERROR: pid: 28455 do_query: error message from backend:
recovery is in progress. Exit this session.
2014-03-27 15:33:57 LOG:   pid: 21996 worker child 28455 exits with status
256
2014-03-27 15:33:57 LOG:   pid: 21996 fork a new worker child pid 28459
2014-03-27 15:33:57 ERROR: pid: 28459 do_query: error message from backend:
recovery is in progress. Exit this session.
2014-03-27 15:33:57 LOG:   pid: 21996 worker child 28459 exits with status
256
...

Looking at the code, I found that the cause is that it invokes
`pg_current_xlog_location()` on the first remaining standby node, when
it shouldn't. In fact, there's no reason to check for replication lag
in such case.

I've attached a simple patch, which makes worker child to skip checking
when there's no primary node.

Please take a look.
Thanks.
Junegunn Choi.
Close listen socket when smart shutdown request is made.

When smart shutdown process starts, pgpool children still listen on
the port and clients can send further connection requests which fail
in the end. Which is not only waste of time, but also prevents a load
balancer which sits in front of pgpool from realizing the pgpool is
going down.

Problem analyzed and patch provided by Junegunn Choi in pgpool-hackers
474, and enhanced to take care not only inet domain socket but UNIX
domain socket by me.
This is the penultimate patch for integration of memory and exception manager APIs into pgpool.
The commit is very large mainly because of replacing of pool_error(), pool_debug() and pool_log() function calls to ereport(ERROR,..) ereport(DEBUG,..) and ereport(LOG,..)
Below is the description of few areas changed by the commit

Some Important Memory Contexts
============================

    ProcessLoopContext:
    This context resets at every main loop iteration of a process

    TopMemoryContext:
    This context is same as PostgreSQL's TopMemoryContext and lives for a life time of process.

    ErrorContext:
    Same as PostgreSQL's ErrorContext and used for error processing.

    QueryContext:
    Used by pgpool child process and it lives for single query cycle.

Lifecycle of Important Objects
==============================

    SessionContext:
    The session context consists of a backend and frontend connection and it lives for a single iteration of main child process loop.
    So the session context object is created in ProcessLoopContext.

    ProcessContext:
    ConnectionPool:
    BackendConnection:
    The above objects are required for the life of process hence are created in TopMemoryContext which lives throughout the process life time.

    Child Frontend connection:
    Frontend connection object is placed in the ProcessLoopContext since new frontend connection is created at every main loop iteration of pgpool child process.

    PCP Frontend connection:
    This object can live till the pcp process so the object for pcp frontend is created in TopMemoryContext.

new configuration parameters
===========================

    The patch also adds three new configuration parameters to control the error reporting style and details.
    Parameters names and their behaviours are borrowed from PostgreSQL.
    int log_error_verbosity;    /* controls how much detail about error should be emitted */
    int client_min_messages;    /*controls which message should be sent to client */
    int log_min_messages;       /*controls which message should be emitted to server log */

Some other notable changes introduced by the patch.
================================================

    The patch changes the error reporting behaviour and now pgpool-II tries to send all the error and log messages to the connected frontend clients (controllable by "client_min_messages" configuration pa
    The patch added an extra call back "on_system_exit" to the elog API, which is not present in the PostgreSQL.
Fix typo
Add cautions that recovery commands are killed by statement_timeout of PostgreSQL.

recovery_1st_stage_command can be killed if its execution time is
longer than statement_timeout and online recovery fails. The problem
was found and reported by Sean Hogan at [pgpool-general:
2680]. Samething can be said to recovery_2nd_stage_command.