Change "on memory query cache" to "in memory query cache".
Prepare 3.4 alpha1.
Update copyright year.
Remove "parallel query".
Add missing Makefiles

These are included in 3.3 stable. Missing these caused a make dist error.
Add missing incluce files to dist package

This caused a make error.
Change default value for log_line_prefix.

To keep backward compatibility, the default value is changed from
empty string to '%t: pid %p: '.
pgpool_adm was mistakenly left untouched by code reorganisation patch and was
still living in root directory (pgpool2/pgpool_adm) of source code,
The patch moves the module to the appropriate place (pgpool2/src/sql/pgpool_adm)
and makes the Makefile adjustments needed because of move
before this commit pgpool calls save_ps_display_args() at each process fork,
which was not actually required and just an unwanted overhead. Doing it once at
system startup from main process is enough as memory of the parent process is
inherited and copied (COW) in child process.
The commit tries to fix the failover deadlock problem
"[pgpool-II 0000105]: Failover dead lock".
Although the issue is not readily reproducible but analysis of Yugo reveals
the following scenario which can cause the deadlock.

Scenario:

--quote--

When watchdog is used and a backend goes down, pgpools can hang.
This is related to semaphore locking used in failover(),degenerate_backend_set().
I analyzed and made a hypothesis of mechanism as below.

1. A backend goes down during many child processes are accepting connection.

2. A child process (P_c0) which detects the backend down executes
degererate_backend_set(). Then in this function,

    - aquires a semaphore lock (pool_semaphore_lock(REQUEST_INFO_SEM))
    - notifies to other pgpools (wd_degenrate_backend_sent())
    - sends a signal to trigger failover (kill(parent, SIGUSR1))
    - release the lock (pool_semaphore_unlock(REQUEST_INFO_SEM))

    3. Then, other child process (P_c1) which detects backend down acquires the lock
    as similar to P_c0.

    4. watchdog process (P_w) which receives notification from P_c0 in other pgpool
    also executes degenerate_backend_set() in wd_sent_response(), and tries to
    acquires the lock. However, P_w can't acquire lock and goes into waiting since
    P_c1 is already holding the lock.

    5. The parent process (P_p) executes failover() and tries to acquires the lock.
    However, P_p can't get lock and goes waiting for the same reason.

    6. P_c1 tries to notify to other pgpools (wd_degenrate_backend_sent()).
    However, P_w in other pgpools are also waiting lock and can't respond.
    So, P_c1 waits response forever.

    7. As a result, both pgools hang in following status;
    - P_c1: lock holder and waiting response from P_w in other pgpool
    - P_w: waiting lock
    - P_p: waiting lock

--unquote--

Fix:

The commit fixes the mentioned scenario by introducing the request info queues
in place of single request info structure for failover requests.
so the failover reporter process can quickly gets back control after enqueueing
the failover request and continue with its normal duty.

There are few minor behavioural changes happened because of the commit mainly in
the area where the failover() function intimates the PCP child for waking up
after processing the failover.

    1-) Now the failover() function only sends the WAKEUP call to the PCP child
        after executing all the queued failover/failback requests.
    2-) Restart signal is sent to PCP child only once after processing all queued requests.
    3-) failover() function sets the switching flag to true when starting to process
        failover queue and the flag keeps set till complete queue is processed.
Prepare 3.4 beta1.
Fix release note of 3.4.
Fix uninitialized variable.

Per Coverity 1234603.
Fix memory leak.

Per coverity 1234602.
Fix possible NULL pointer reference in ProcessFrontendResponse.

Per coverity 1247717.
Fix missing release note entries in the previous release.
Allow to specify whether including pgpool-regclass.so or not.

PostgreSQL 9.4 or later does not need pgpool-regclass.so because they
have to_regclass.
Fix build error.

make[1]: Entering directory `/var/lib/pgsql/pgpool2'
make[1]: *** No rule to make target `compile', needed by `distdir'.  Stop.

There should be better way...
Prepare for 3.4 beta2.
Prepare for 3.4 beta2.