pgpool2.git - commit 6eb7160c4565

pgpool2.git / summary / log / commit / refs

commit    6eb7160c4565bd16283e12a26cb1ffbc85a8a5c5
Author:   Tatsuo Ishii <ishii@postgresql.org>
Date:     Wed Apr 12 08:32:31 2017 +0000

    Remove old html docs and related files.


 doc/basebackup.sh                 |    32 -
 doc/pgpool-de.html                |  4220 ----------
 doc/pgpool-en.html                |  6195 ---------------
 doc/pgpool-fr.html                |  4118 ----------
 doc/pgpool-ja.css                 |   198 -
 doc/pgpool-ja.html                | 15052 ------------------------------------
 doc/pgpool-zh_cn.html             |  5256 -------------
 doc/pgpool.8.in                   |   121 -
 doc/pgpool.css                    |   292 -
 doc/pgpool_adm.odp                |   Bin 17456 -> 0 bytes
 doc/pgpool_adm.png                |   Bin 32437 -> 0 bytes
 doc/pgpool_remote_start           |    13 -
 doc/recovery.conf.sample          |   117 -
 doc/tutorial-en.html              |   707 --
 doc/tutorial-ja.html              |   422 -
 doc/tutorial-memqcache-en.html    |   325 -
 doc/tutorial-memqcache-ja.html    |   370 -
 doc/tutorial-memqcache-zh_cn.html |   322 -
 doc/tutorial-watchdog-en.html     |   306 -
 doc/tutorial-watchdog-ja.html     |   343 -
 doc/tutorial-watchdog-zh_cn.html  |   301 -
 doc/tutorial-zh_cn.html           |   537 --
 doc/watchdog.png                  |   Bin 25489 -> 0 bytes
 doc/wd-en.html                    |   236 -
 doc/wd-en.jpg                     |   Bin 74424 -> 0 bytes
 doc/wd-ja.html                    |   219 -
 doc/wd-ja.jpg                     |   Bin 71978 -> 0 bytes
 doc/wd-zh_cn.html                 |   201 -
 doc/where_to_send_queries.odg     |   Bin 22505 -> 0 bytes
 doc/where_to_send_queries.pdf     |   Bin 49506 -> 0 bytes
 30 files changed, 39903 deletions(-)

diff --git a/doc/basebackup.sh b/doc/basebackup.sh
deleted file mode 100644
index 71fe544ec..000000000
--- a/doc/basebackup.sh
+++ /dev/null
@@ -1,32 +0,0 @@
-#! /bin/sh
-# Recovery script for streaming replication.
-# This script assumes followings:
-#
-# 1) Executed on the primary node by pgpool_recovery function.
-# 2) Executed as "recovery_user" (usually PostgreSQL super user).
-# 3) "postgres" database is available.
-# 4) can connect to "postgres" database via UNIX domain socket without
-#    password.
-# 5) Password less access using ssh from the primary node to the
-#    target node is possible.
-# 6) Arguments for the scripts are:
-#	$1: database cluster path on the primary node
-#	$2: hostname or IP address to be recovered
-#	$3: database cluster path on target node
-#	$4: port number of of the primary database cluster
-# 7) psql, rsync, ssh are available in the command search path.
-
-datadir=$1
-desthost=$2
-destdir=$3
-port=$4
-
-psql -p $port -c "SELECT pg_start_backup('Streaming Replication', true)" postgres
-
-rsync -C -a -c --delete -e ssh --exclude postgresql.conf --exclude postmaster.pid \
---exclude postmaster.opts --exclude pg_log --exclude pg_xlog \
---exclude recovery.conf $datadir/ $desthost:$destdir/
-
-ssh -T $desthost mv $destdir/recovery.done $destdir/recovery.conf
-
-psql -c "SELECT pg_stop_backup()" postgres
diff --git a/doc/pgpool-de.html b/doc/pgpool-de.html
deleted file mode 100644
index 92d6b5171..000000000
--- a/doc/pgpool-de.html
+++ /dev/null
@@ -1,4220 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<html>
-<head>
-<meta http-equiv="content-type" content="text/html; charset=UTF-8">
-<link rel="stylesheet" href="./pgpool.css" type="text/css">
-<title>pgpool-II Benutzerhandbuch</title>
-</head>
-
-<!-- hhmts start -->
-Last modified: Wed, 24 Aug 2011 10:38:20 +0200
-<!-- hhmts end -->
-
-
-<!-- translated from pgpool-en.html revision 1.86 -->
-
-<body bgcolor="#ffffff">
-<a name="top"></a>
-<table border="0" cellpadding="2" cellspacing="1">
-  <tr>
-
-    <td colspan="2" valign="top"><div class="header_text">Willkommen auf der pgpool-II Website</div></td>
-  </tr>
-  <tr>
-    <td valign="top" style="border-right:1px dotted #cccccc;">
-	<br />
-
-	<div id="navcontainer">
-      <ul id="navlist">
-        <li id="active"><a href="#Whatis" id="current">Was ist pgpool-II?</a></li>
-        <li><a href="#platform">Systemanforderungen</a></li>
-        <li><a href="#install">Installation von pgpool-II</a></li>
-        <li><a href="#config">Konfiguration von pgpool-II</a></li>
-        <li><a href="#common">Allgemeine Konfiguration</a></li>
-        <li><a href="#connection_pool_mode">Connection-Pool Modus</a></li>
-        <li><a href="#replication_mode">Replikations Modus</a></li>
-        <li><a href="#master_slave_mode">Master-Slave Modus</a></li>
-        <li><a href="#start">Starten und Stoppen von pgpool-II</a></li>
-        <li><a href="#reload">pgpool-II Konfiguration neu laden</a></li>
-        <li><a href="#show-commands">SHOW Kommandos</a></li>
-        <li><a href="#online-recovery">Online Recovery</a></li>
-        <li><a href="#troubleshooting">Fehlerbehebung</a></li>
-        <li><a href="#restriction">Beschränkungen</a></li>
-        <li><a href="#reference">Referenzen</a></li>
-		<li><a href="#internal">Interna</a></li>
-      </ul>
-    </div>
-	<br />
-
-		<div class="header_small" align="center">
-
-			[<a href="pgpool-ja.html">Japanese page</a>]		</div><div class="header_small" align="center">
-
-			[<a href="pgpool-en.html">English page</a>]		</div>	</td>
-    <td valign="top" style="border-left:1px dotted #cccccc;">
-	
-
-
-
-<h1>Was ist pgpool-II?<a name="whatis"></a></h1>
-
-<p>pgpool-II ist eine Middleware die sich zwischen den PostgreSQL-
-Server und deren Clients schaltet.  Es bietet folgende Funktionen:</p>
-
-<p>
-<ul>
-
-<li>Connection Pooling</li>
-    <p>pgpool-II verwaltet die Verbindungen zum PostgreSQL-Server und
-hält bestehende Verbindungen aufrecht, um diese wiederverwenden zu
-können.  Einem Client, der eine Verbindung mit den selben
-Eigenschaften (z.B. Benutzername, Datenbank, Protokollversion)
-anfordert, kann so eine bereits bestehende Verbindung zugewiesen
-werden. Dies reduziert den Overhead und verbessert den
-Gesammtdurchsatz des Systems.</p>
-
-<li>Replikation</li>
-    <p>pgpool-II kann mehrere PostgreSQL-Server Verwalten.  Die
-Replikationsfunktion erlaubt es ein Echtzeit-Backup auf 2 oder mehr
-PostgreSQL-Knoten zu erstellen, so dass auch bei einem Ausfall eines
-Knotens ein unterbrechungsfreier Betrieb gewährleistet werden
-kann.</p>
-
-<li>Lastverteilung</li>
-    <p>Bei einer replizierten Datenbank (sowohl im Replikations- wie
-auch im Master/Slave Modus) wird eine Abfrage mit SELECT auf allen
-Knoten dasselbe Resultat liefern.  pgpool-II nutzt dies und verteilt
-solche lesenden Anfragen gleichmässig auf die verfügbaren Knoten, um
-den Durchsatz des gesammten Systems zu steigern. Im Idealfall skaliert
-die Leistung für lesenden Zugriff proportional zur Anzahl der
-verwalteten PostgreSQL-Knoten. Lastverteilung funktioniert also am
-Besten mit vielen gleichzeitigen Nutzern, die meistens nur-lesende
-Transaktionen ausführen.
-</p>
-
-<li>Verwaltung vieler gleichzeitiger Verbindungen</li>
-    <p>Bei PostgreSQL wird eine Beschränkung für die maximal
-gleichzeitig möglichen Verbindungen konfiguriert.  Sobald diese Grenze
-erreicht ist, werden neue Verbindungen mit einem Fehler abgelehnt. Das
-Anheben dieser Beschränkung führt zu erhöhtem Resourcenverbrauch und
-verringert damit insgesammt die Systemleistung.  Auch Pgpool-II hat
-eine konfigurierbare Obergrenze für gleichzeitige Verbindungen,
-weitere Verbindungen werden aber in eine Warteschlange gesetzt und
-später, anstatt dass ein Fehler zurückgeliefert wird.
-
-<li>Parallele-Abfragen (Parallel Querying)</li>
-    <p>Daten können beim Parallel Querying auf mehrere Server
-aufgeteilt werden, so dass Anfragen auf mehreren Knoten parallel
-ausgeführt werden können, um kürzere Antwortzeiten zu erreichen.
-Parallele Abfragen sind gut geeignet für Suchanfragen auf grosse
-Datenmengen.
-</p>
-
-</ul>
-</p>
-
-<p>pgpool-II spricht das Front- und Backend-Protokoll von PostgreSQL
-und leitet Packete zwischen dem Backend und dem Frontend weiter.
-Deshalb kann eine Datenbankanwendung (Frontend) pgpool-II genau wie
-einen echten PostgreSQL-Server ansprechen. Umgekehrt ist pgpool-II für
-den Server (Backend) einfach einer von vielen Nutzern. Weil pgpool-II
-sowohl für den Server wie auch für den Client transparent ist, können
-bestehende Datenbankanwendungen zusammen mit pgpool-II genutzt werden,
-meist ohne Anpassungen an deren Quellcode.</p>
-
-<p>
-<strong>Es gibt einige Einschränkungen in der Verwendung von SQL via
-pgpool-II.  Siehe <a href="#restriction">Einschränkungen</a> für mehr
-Informationen.</strong>
-</p>
-
-<h1>Systemanforderungen<a name="platform"></a></h1>
-
-<p>pgpool-II läuft unter Linux, Solaris, FreeBSD sowie den
-allermeisten UNIX-artigen Betriebssystemen. Windows wird nicht
-unterstüzt. Alle Versionen von PostgreSQL ab 6.4 sind kompatibel zu
-pgpool-II, für parallele Abfragen wird allerdings mindestens
-PostgreSQL 7.4 vorausgesetzt.</p>
-
-<p>Bei der Verwendung von PostgreSQL 7.3 und älter sind weitere
-Funktionen nur eingeschränkt verfügbar, diese sollten aber sowieso
-nicht mehr genutzt werden.</p>
-
-<p>Auf allen PostgreSQL-Knoten sollte dieselbe Major-Version von
-PostgreSQL verwendet werden. Desweiteren ist zu beachten, dass auch
-die Architektur und das Betriebssystem identisch sein müssen, um
-online recovery verwenden zu können.</p>
-
-<h1>Installation von pgpool-II<a name="install"></a></h1>
-
-<p>pgpool-II ist auf folgender Website
-erhältlich: <a href="http://pgfoundry.org/projects/pgpool/">pgpool
-Development page</a>.  Installationsfertige Pakete stellen auch
-verschiedene Distributitonen durch deren Paketverwaltung zur
-Verfügung, z.B. CentOS, RedHat Enterprise Linux, Fedora und
-Debian.</p>
-
-<p>Der Quellcode von pgpool-II ist ebenfalls hier erhältlich:
-<a href="http://pgfoundry.org/projects/pgpool/">pgpool development page</a>
-</p>
-
-<p>Zur Installation von pgpool-II aus dem Quellcode ist gcc (ab 2.9)
-und GNU make erforderlich. Auch die libpq Bibliothek von PostgreSQL
-inklusive Header-Dateien wird benötigt, die entsprechenden Packete
-müssen also installiert sein, um pgpool-II kompilieren zu können. Zur
-Unterstützung von SSL Verbindungen ist zusätzlich OpenSSL und dessen
-Header Dateien nötig.</p>
-
-<dl>
-<dt>configure</dt>
-<dd>
-<p>
-Nach dem Entpacken des Quellcodes ist folgendes Skript auszuführen:
-<pre>
-./configure
-</pre>
-
-Folgende Optionen sind zusätzlich möglich:
-
-<ul>
-  <li><code>--prefix=path</code><br/> pgpool-II wird unter diesem
-      Verzeichnis installiert. Standardeinstellung
-      ist: <code>/usr/local</code></li>
-  <li><code>--with-pgsql=path</code><br/> Das Verzeichnis worunter
-      PostgreSQLs Bibliotheken installiert wurden. Standardmässig wird
-      dieses mit <code>pg_config</code> automatisch ermittelt.</li>
-  <li><code>--with-openssl</code><br/>
-      Verlinkt pgpool-II mit OpenSSL, in der Voreinstellung deaktiviert.</li>
-  <li><code>--enable-sequence-lock</code><br/>
-	Nutzt den zu pgpool-II 3.0 (bis 3.0.4) kompatiblen insert_lock.
-	Damit sperrt (LOCK) pgpool-II die Sequenzrelation.  PostgreSQL ab
-	Version 8.2 (veröffentlicht im Juni 2011) ist inkompatibel zu
-	dieser Variante.</li>
-  <li><code>--enable-table-lock</code> <br/>
-	Nutzt den zu pgpool-II 2.2 und 2.3 kompatiblen insert_lock.
-	Pgpool-II sperrt (LOCK) damit die Zieltabelle des INSERTs.  Diese
-	Variante ist veraltet, da sie Konflikte mit VACUUM
-	verursacht.</li>
-</ul>
-</p>
-</dd>
-
-<dt>make</dt>
-<dd>
-<p>
-<pre>
-make
-make install
-</pre>
-installiert pgpool-II. (Unter Solaris oder FreeBSD ist make mit gmake zu ersetzen)
-</p>
-</dd>
-
-<dt>Installation von pgpool_regclass</dt>
-<dd>
-<p>
-Bei der Nutzung von PostgreSQL 8.0 oder höher ist die Installation von
-pgpool_regclass auf allen Knoten, die von pgpool-II genutzt werden
-sollen sehr empfehlenswert.  Deren Funktionen werden von pgpool-II
-intern genutzt, um Duplikate bei Tabellennamen in verschiededen Schema
-verhindern zu können.
-</p>
-<p>
-<pre>
-cd pgpool-II-x.x.x/sql/pgpool-regclass
-make
-make install
-psql -f pgpool-regclass.sql template1
-</pre>
-</p>
-<p>
-Das Skript pgpool-regclass.sql sollte auf jeder mit pgpool-II
-verwendeten Datenbank ausgeführt werden.
-
-Bei der Installation in template1 wird pgpool-regclass beim Erstellen
-einer neuen Datenbank automatisch kopiert. Für Datenbanken, die nach
-der Ausführung von "psql -f pgpool-regclass.sql template1" generiert
-werden ist also keine weitere Aktion erforderlich.
-</p>
-
-
-<dt>Creating insert_lock table</dt>
-<dd>
-<p>
-If you use insert_lock in replication mode, creating pgpool_catalog.insert_lock
-table for mutual exclusion is strongly recommended.
-Without this, insert_lock works so far. However in that case pgpool-II locks
-against the insert target table. This behavior is same as pgpool-II 2.2 and 2.3
-series. The table lock conflicts with VACUUM. So INSERT processing may be thereby
-kept waiting for a long time.
-</p>
-<p>
-<pre>
-cd pgpool-II-x.x.x/sql
-psql -f insert_lock.sql template1
-</pre>
-</p>
-<p>
-Executing insert_lock.sql should be performed on every databases accessed
-with pgpool-II.
-You do not need to do this for a database created after the execution of
-&quot;psql -f insert_lock.sql template1&quot;, as this template database will be
-cloned to create new databases.
-</p>
-
-</dl>
-
-<p>
-Installing is done. If you are using Solaris or FreeBSD, you need to replace "make" with "gmake" in the above description because those operating systems requires GNU make.
-</p>
-
-<h1>Konfiguration von pgpool-II<a name="config"></a></h1>
-
-<p>Beispielhafte Konfigurationsdateien für pgpool-II werden
-standardmässig unter <code>/usr/local/etc/pgpool.conf</code>
-und <code>/usr/local/etc/pcp.conf</code> installiert.
-
-pgpool-II bietet mehrere Funktionsmodi. Jeder hat leicht
-unterschiedliche Funktionen, die an- oder ausgeschaltet und teils mit
-spezifischen Parametern angepasst werden können.</p>
-
-<table border>
-
-  <tr>
-    <th>Function/Mode</th>
-    <th>Basis Modus (*3)</th>
-    <th>Replikations Modus</th>
-    <th>Master-Slave Modus</th>
-    <th>Parallel Query Modus</th>
-  </tr>
-
-  <tr>
-    <td>Connection Pool</td>
-	<td align="center">X</td>
-	<td align="center">O</td>
-	<td align="center">O</td>
-	<td align="center">O</td>
-  </tr>
-
-  <tr>
-    <td>Replikation</td>
-	<td align="center">X</td>
-	<td align="center">O</td>
-	<td align="center">X</td>
-	<td align="center">(*1)</td>
-  </tr>
-
-  <tr>
-    <td>Lastverteilung</td>
-	<td align="center">X</td>
-	<td align="center">O</td>
-	<td align="center">O</td>
-	<td align="center">(*1)</td>
-  </tr>
-
-  <tr>
-    <td>Failover</td>
-	<td align="center">O</td>
-	<td align="center">O</td>
-	<td align="center">O</td>
-	<td align="center">X</td>
-  </tr>
-
-  <tr>
-    <td>Online Recovery</td>
-	<td align="center">X</td>
-	<td align="center">0</td>
-	<td align="center">(*2)</td>
-	<td align="center">X</td>
-  </tr>
-
-  <tr>
-    <td>Parallel Query</td>
-	<td align="center">X</td>
-	<td align="center">X</td>
-	<td align="center">X</td>
-	<td align="center">O</td>
-  </tr>
-
-  <tr>
-    <td>Mindestzahl Server</td>
-	<td align="center">1 oder mehr</td>
-	<td align="center">2 oder mehr</td>
-	<td align="center">2 oder mehr</td>
-	<td align="center">2 oder mehr</td>
-  </tr>
-
-  <tr>
-    <td>System DB erforderlich?</td>
-	<td align="center">no</td>
-	<td align="center">no</td>
-	<td align="center">no</td>
-	<td align="center">yes</td>
-  </tr>
-
-</table>
-
-<p>
-<ul>
- <li> O heisst verfügbar, X heisst nicht möglich
- <li>(*1) Der Parallel Query Modus erfordert eine aktivierte
- Replikation oder Lastverteilung, weder Replikation noch
- Lastverteilung können jedoch für parallele Abfragen auf verteilten
- Tabellen genutzt werden.
- <li>(*2) Online Recovery kann zusammen nur zusammen mit Streaming
- Replication genutzt werden.
- <li>(*3) Anwendungen verbinden sich via pgpool-II mit der PostgreSQL
- Datenbank. Dieser Modus ermöglicht Connection Pooling und damit mehr
- parallele Verbindungen von anwendungsseite her, oder auch einfaches
- Failover bei mehreren Servern.
-</ul>
-</p>
-
-<h2>Konfiguration mit <code>pcp.conf</code></h2>
-
-<p>pgpool-II bietet eine Schnittstelle zur Kontrolle, die es dem
-Administrator ermöglicht, den Status von pgpool-II abzufragen sowie
-ggf. einzelne pgpool-II Prozesse zu beenden. Die
-Datei <code>pcp.conf</code> enthält den Benutzernamen sowie das
-Passwort zur Authentifizierung bei dieser Schnittstelle. Alle
-Betriebsmodi erfordern entsprechenden Einstellungen in der
-Datei <code>pcp.conf</code>. Die
-Beispieldatei <code>$prefix/etc/pcp.conf.sample</code> wird während
-der Installation von pgpool-II angelegt. Bitte benennen Sie diese
-Datei in <code>pcp.conf</code> um und fügen Sie ihren Benutzername und
-ein Passwort hinzu.
-</p>
-
-<pre>
-cp $prefix/etc/pcp.conf.sample $prefix/etc/pcp.conf
-</pre>
-
-<p>
-Weitere Beispielkonfigurationen sind für jeden Modus verfügbar.
-</p>
-<p>
-<table border>
-<tr>
-<th>Modus</th>
-<th>Beispieldatei</th>
-</tr>
-
-<tr>
-<td>Replikations Modus</td>
-<td>pgpool.conf.sample-replication</td>
-</tr>
-
-<tr>
-<td>Master/Slave Modus (Slony-I)</td>
-<td>pgpool.conf.sample-master-slave</td>
-</tr>
-
-<tr>
-<td>Master/Slave Modus (Streaming replication)</td>
-<td>pgpool.conf.sample-stream</td>
-</tr>
-</table>
-
-<p>
-Leerzeilen wie auch Zeilen, die mit "<code>#</code>" beginnen werden
-als Kommentare behandelt und ignoriert. Der Benutzername und das
-zugehörige Passwort müssen auf einer Zeile stehen und folgendes Format
-befolgen:
-</p>
-<pre>
-Nutzername:[md5 hash des Passwortes]
-</pre>
-<p>
-Der <code>[md5 hash des Passwortes]</code> kann mit Hilfe des
-Programs <code>$prefix/bin/pg_md5</code> ermittelt werden.
-</p>
-
-<pre>
-pg_md5 -p
-password: &lt;your password&gt;
-</pre>
-<p>
-oder:
-</p>
-<pre>
-./pg_md5 foo
-acbd18db4cc2f85cedef654fccc4a4d8
-</pre>
-<p>
-Die Datei <code>pcp.conf</code> muss für den Nutzer der pgpool-II ausführt lesbar sein.</p>
-
-<h2>Konfiguration mit <code>pgpool.conf</code></h2>
-
-<p>Wie bereits beschrieben erfordert jeder Betriebsmodus seine eigenen
-Konfigurationsparameter in <code>pgpool.conf</code>. Auch dafür legt
-pgpool-II während der Installation eine Beispieldatei an. Kopieren Sie
-die Beispieldatei von <code>$prefix/etc/pgpool.conf.sample</code>
-in <code>pgpool.conf</code> um und bearbeiten Sie dessen Inhalt.
-
-<pre>
-cp $prefix/etc/pgpool.conf.sample $prefix/etc/pgpool.conf
-</pre>
-<p>
-Leerzeilen wie auch Zeilen, die mit "<code>#</code>" beginnen werden
-als Kommentare behandelt und ignoriert.</p>
-</p>
-<h3><a name="common"></a>Allgemeine Konfiguration</h3>
-
-<dl>
-  <dt><a name="LISTEN_ADDRESS"></a>listen_addresses</dt>
-  <dd>
-      <p>Gibt den Hostnamen oder die IP Adresse an, über welche
-      pgpool-II TCP/IP Verbindungen annehmen soll. <code>'*'</code>
-      steht für alle Interfaces. <code>''</code> blockiert TCP/IP
-      Verbindungen. Standardwert
-      ist <code>'localhost'</code>. Verbindungen via UNIX Domain
-      Sockets werde immer akzeptiert. Dieser Parameter kann nur beim
-      Serverstart gesetzt werden.</p>
-  </dd>
-      
-  <dt><a name="PORT"></a>port</dt>
-  <dd>
-      <p>Die Portnummer die pgpool-II nutzen soll, um Verbindungen zu
-      akzeptieren. Standardwert ist 9999. Dieser Parameter kann nur
-      beim Serverstart gesetzt werden.</p>
-  </dd>
-
-  <dt><a name="SOCKET_DIR"></a>socket_dir</dt>
-  <dd>
-      <p>Das Verzeichnis in welchem das UNIX Domain Socket für
-      pgpool-II angelegt werden soll. Standardwert
-      ist <code>'/tmp'</code>. Bitte bedenken Sie, dass dieses
-      Verzeichnis durch Cron Jobs regelmässig gelöscht werden
-      könnte. Es wird deshalb empfohlen, das Socket unter einem
-      anderen Verzeichnis, wie z.B. <code>'/var/run'</code>
-      anzulegen. Dieser Parameter kann nur beim Serverstart gesetzt
-      werden.</p>
-  </dd>
-
-  <dt><a name="PCP_PORT"></a>pcp_port</dt>
-  <dd>
-      <p>Die Portnummer auf welcher der PCP Prozess Verbindungen
-      annehmen soll. Standardwert ist 9998. Dieser Parameter kann nur
-      beim Serverstart gesetzt werden.</p>
-  </dd>
-
-  <dt><a name="PCP_SOCKET_DIR"></a>pcp_socket_dir</dt>
-  <dd>
-      <p>Das Verzeichnis in welchem das UNIX Domain Socket für den PCP
-      Prozess angelegt werden soll. Standardwert
-      ist <code>'/tmp'</code>. Bitte bedenken Sie, dass dieses
-      Verzeichnis durch Cron Jobs regelmässig gelöscht werden
-      könnte. Es wird deshalb empfohlen, das Socket unter einem
-      anderen Verzeichnis, wie z.B. <code>'/var/run'</code>
-      anzulegen. Dieser Parameter kann nur beim Serverstart gesetzt
-      werden.</p>
-  </dd>
-      
-  <dt><a name="BACKEND_SOCKET_DIR"></a>backend_socket_dir</dt>
-  <dd>
-      <font color="red"><em>VERALTET</em><br> Dieser Parameter ist
-      veraltet und sollte nicht mehr verwendet werden.  Nutzen Sie
-      stattdessen backend_hostname.
-      </font>
-      <p>Das Verzeichnis in welchem PostgreSQL sein UNIX Domain Socket
-      anlegt.  Standardeinstellung war <code>'/tmp'</code>.  Dieser
-      Parameter kann nur beim Serverstart gesetzt werden.</p>
-  </dd>
-
-  <dt><a name="PCP_TIMEOUT"></a>pcp_timeout</dt>
-  <dd>
-      <p>Das Timeout für PCP Verbindungen in Sekunden. Sollte ein
-      Nutzer innert dieser Frist nicht Antworten, so schliesst der PCP
-      Prozess die Verbindung. Standardwert ist 10 Sekunden. 0
-      deaktiviert diese Funktion. Kann durch erneutes Laden der
-      Konfiguration verändert werden.</p>
-  </dd>
-
-  <dt><a name="NUM_INIT_CHILDREN"></a>num_init_children</dt>
-  <dd>
-      <p>Anzahl der pgpool-II Serverprozesse, die bereit gehalten
-      werden sollen (prefork). Standardwert ist 32. num_init_children
-      ist auch die Obergrenze für die Anzahl gleichzeitiger
-      Verbindungen von Anwendungen zu pgpool-II. Sollten mehr als
-      num_init_children Anwendungen versuchen eine Verbindung zu
-      pgpool-II aufzubauen, so werden diese blockiert (nicht
-      abgewiesen), bis eine bestehende Verbindung zu einem pgpool-II
-      Prozess freigegeben wird. Maximal 2 * num_init_children
-      Verbindungsanfragen werden gepuffert.  Die Anzahl Verbindungen
-      zu jeder Instanz von PostgreSQL ist ungefähr
-      max_pool*num_init_children</p>
-      
-	  <p>Weitere Tipps zum obigen Parameter:</p>
-	   <p>
-	   <ul>
-		<li>Das Abbrechen einer Transaktion erfordert eine weitere,
-		separate Verbindung zum Backend (PostgreSQL Server).  Deshalb
-		können Transaktionen nicht abgebrochen werden, solange alle
-		Prozesse beschäftigt sind. Um sicher zu gehen, dass
-		Transaktionen abgebrochen werden können, ist dieser Parameter
-		auf den doppelten Wert der zu erwartenden Anzahl
-		gleichzeitiger Verbindungen zu setzen.</li>
-
-		<li>Bedenken Sie auch, dass PostgreSQL nur bis zu
-		(max_connections - superuser_reserved_connections)
-		gleichzeitige Verbindungen von einfachen Nutzern erlaubt
-		(nicht Superuser).</li>
-	   </ul>
-	   </p>
-	   <p>Die Parameter max_pool, num_init_children, max_connections
-	   und superuser_reserved_connections sollten folgende Bedingungen
-	   erfüllen:
-	   </p>
-	   <p>
-	   <pre>
-max_pool*num_init_children <= (max_connections - superuser_reserved_connections) (kein Abbrechen von Transaktionen)
-max_pool*num_init_children*2 <= (max_connections - superuser_reserved_connections) (Abbrechen von Transaktionen erfordert)
-	   </pre>
-	   <p>Dieser Parameter kann nur beim Serverstart gesetzt werden.</p>
-	   </dd>
-
-  <dt><a name="CHILD_LIFE_TIME"></a>child_life_time</dt>
-  <dd>
-      <p>Die Lebensdauer eines pgpool-II Prozesses in Sekunden. Ein
-      Kindprozess, der für über diese Dauer hinaus im Leerlauf bleibt,
-      wird beendet um einen neuen Kindprozess zu starten. Dieser
-      Parameter ermöglicht eine einfache Massnahme gegen Lecks im
-      Speicher (Memory Leaks) und ähnlichen Ressourcen. Der
-      Standardwert ist 300 (5 Minuten). 0 staltet diese Funktion
-      ab. Diese Funktion wird nicht auch Kindprozesse angewandt, die
-      bisher noch keine Verbindung akzeptiert haben. Kann durch
-      erneutes Laden der Konfiguration verändert werden.
-      </p>
-  </dd>
-
-  <dt><a name="CHILD_MAX_CONNECTIONS"></a>child_max_connections</dt>
-  <dd>
-      <p>Anzahl Verbindungen, nach denen ein pgpool-II Kindprozess
-      beendet wird. Dieser Parameter ist nützlich bei so grosser Last,
-      dass weder child_life_time noch connection_life_time je
-      greiffen. Diese Option kann also ebenfalls hilfreich sein um
-      Überlastung der PostgreSQL server vorzubeugen. Sie kann durch
-      erneutes Laden der Konfiguration verändert werden.
-      </p>
-  </dd>
-
-  <dt><a name="CLIENT_IDLE_LIMIT"></a>client_idle_limit
-  <dd>
-  <p>Die Verbindung zum Nutzer von pgpool-II wird nach
-  client_idle_limit Sekunden des Leerlaufes seit der letzten Anfrage
-  getrennt. Dies verhindert, dass ein Kindprozess über längere Zeit
-  blockiert wird, obwohl der Nutzer die TCP/IP Verbindung zu pgpool-II
-  schon beendet hat. Der Standardwert für diesen Parameter ist 0, was
-  diese Funktion deaktiviert. Dieser Parameter wird in der zweiten
-  Phase von Online Recovery ignoriert. Kann durch erneutes Laden der
-  Konfiguration verändert werden.</p>
-
-  <dt><a name="AUTHENTICATION_TIMEOUT"></a>authentication_timeout
-  <dd>
-  <p>Spezifiziert eine Zeitbeschränkung für die Authentifizierung. Der
-  Standardwert ist 60. Kann durch erneutes Laden der Konfiguration
-  verändert werden.</p>
-
-  <dt><a name="LOGDIR"></a>logdir</dt>
-  <dd>
-      <p>Die Datei pgpool_status wird in dieses Verzeichnis
-      geschrieben.</p>
-  </dd>
-
-  <dt><a name="LOG_DESTINATION"></a>log_destination</dt>
-  <dd>
-      <p>pgpool-II unterstützt mehrere Methoden für das Logging von
-      Servermeldungen, unter anderem stderr und syslog. Standardmässig
-      wird nach stderr geschrieben.
-       </p>
-      <p>Achtung: die Konfiguration des syslog Daemons muss angepasst
-      werden, damit das Logging via syslog funktioniert. pgpool-II
-      kann die Syslog-Prioritäten von LOCAL0 bis LOCAL7 nutzen (siehe
-      syslog_facility), mit Standardeinstellungen werden die meisten
-      Platformen solche Meldungen jedoch ignorieren. Eine Zeile wie
-      die folgende muss zur Konfiguration des Syslog-Services zugefügt
-      werden:
-	</p>
-	<pre>
-	local0.*    /var/log/pgpool.log
-	</pre>
-  </dd>
-
-  <dt><a name="SYSLOG_FACILITY"></a>syslog_facility</dt>
-  <dd>
-      <p>Ist das Logging via Syslog erwünscht, so gibt dieser
-      Parameter die von pgpool-II zu nutzende Priorität ("facility")
-      an. Mögliche Werte sind: LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4,
-      LOCAL5, LOCAL6, LOCAL7; Standardwert ist LOCAL0. Lesen Sie bitte
-      auch die Dokumentation zu ihrem Syslog-Service.
-	</p>
-  </dd>
-
-  <dt><a name="SYSLOG_IDENT"></a>syslog_ident</dt>
-  <dd>
-      <p>Ist das Logging via Syslog erwünscht, so gibt dieser
-      Parameter den Programmnamen an, den pgpool-II zur Identifikation
-      nutzen soll. Standardwert ist <code>'pgpool'</code>.
-	</p>
-  </dd>
-
-  <dt><a name="PID_FILE_NAME"></a>pid_file_name</dt>
-  <dd>
-      <p>Voller Pfad zur Datei, in welche pgpool die Prozess-Id
-      schreiben soll. Standardwert
-      ist <code>'/var/run/pgpool/pgpool.pid'</code>. Ein Neustart von
-      pgpool ist erforderlich, um diesen Parameter zu ändern.
-       </p>
-  </dd>
-
-  <dt><a name="PRINT_TIMESTAMP"></a>print_timestamp</dt>
-  <dd>
-      <p>Ob pgpool-II zu jedem Log-Eintrag einen Zeitstempel schreiben
-      soll. Standardwert ist 'true' (ja). Kann durch erneutes Laden
-      der Konfiguration verändert werden.
-      </p>
-  </dd>
-
-  <dt><a name="CONNECTION_CACHE"></a>connection_cache</dt>
-  <dd>
-      <p>Ob pgpool-II Verbindungen im Cache behalten
-      soll. Standardwert ist 'true' (ja). Ein Neustart ist
-      erforderlich, damit eine Änderung dieser Option wirksam wird.
-      </p>
-  </dd>
-
-  <dt><a name="HEALTH_CHECK_TIMEOUT"></a>health_check_timeout</dt>
-  <dd>
-      <p>pgpool-II prüft regelmässig die Verbindungen zu den
-      PostgreSQL-Backends, um Fehler auf den Datenbankservern oder im
-      Netzwerk entdecken zu können (Verbindungsprüfung). Wird ein
-      Fehler entdeckt, so versucht pgpool-II auf einen anderen Server
-      zu wechseln ("failover") oder fährt im degenerierten Modus fort.
-
-      Dieser Parameter verhindert zu lange Wartezeiten für diese
-      Prüfroutine in Fällen wie einem abgezogenen Netzkabel. Das
-      Zeitlimit wird in Sekunden angegeben. Der Standardwert ist
-      20. Der Wert 0 deaktiviert diese Funktion (wodurch pgpool-II bis
-      zum Timeout der TCP/IP Verbindung wartet).
-
-      Diese Verbindungsprüfung erfordert eine zusätzliche Verbindung
-      zu jedem PostgreSQL-Knoten, weshalb <code>max_connections</code>
-      in <code>postgresql.conf</code> entsprechend angepasst werden
-      sollte.
-
-      Kann durch erneutes Laden der Konfiguration verändert werden.
-     </p>
-  </dd>
-
-  <dt><a name="HEALTH_CHECK_PERIOD"></a>health_check_period</dt>
-  <dd>
-      <p>Gibt das Interval zwischen den Verbindungsprüfungen in
-      Sekunden an. Standardwert ist 0, was die Verbindungsprüfung
-      deaktiviert. Kann durch erneutes Laden der Konfiguration
-      verändert werden.
-       </p>
-  </dd>
-      
-  <dt><a name="HEALTH_CHECK_USER"></a>health_check_user</dt>
-  <dd>
-      <p>Der Benutzername mit welchem die Verbindungsprüfung
-      vorgenommen wird. Dieser Benutzer muss auf allen
-      PostgreSQL-Knoten existieren, anderenfalls schlägt die
-      Verbindungsprüfung fehl. Kann durch erneutes Laden der
-      Konfiguration verändert werden.
-       </p>
-  </dd>
-
-  <dt><a name="HEALTH_CHECK_PASSWORD"></a>health_check_password</dt>
-  <dd>
-      <p>Das Passwort zum Nutzer mit welchem die Verbindungsprüfung
-      vorgenommen wird. Kann durch erneutes Laden der Konfiguration
-      verändert werden.
-       </p>
-  </dd>
-
-<dt><a name="FAILOVER_COMMAND"></a>failover_command
-<dd>
-<p>
-Spezifiziert einen Befehl, der ausgeführt wird, wenn ein Knoten vom
-Cluster getrennt wird. pgpool-II ersetzt die folgenden Spezialzeichen:
-</p>
-
-<blockquote>
-<table border>
-<tr><td>Spezialzeichen</td><td>Beschreibung</td></tr>
-<tr><td>%d</td><td>Backend ID des getrennten Knotens</td></tr>
-<tr><td>%h</td><td>Hostname des getrennten Knotens</td></tr>
-<tr><td>%p</td><td>Portnummer des getrennten Knotens</td></tr>
-<tr><td>%D</td><td>Database Cluster Verzeichnis des getrennten Knotens</td></tr>
-<tr><td>%M</td><td>Id des bisherigen Master-Knotens</td></tr>
-<tr><td>%m</td><td>Id des neuen Master-Knotens</td></tr>
-<tr><td>%H</td><td>Hostname des neuen Master-Knotens</td></tr>
-<tr><td>%P</td><td>Id des bisherigen primären Knotens</td></tr>
-<tr><td>%%</td><td>'%'-Zeichen</td></tr>
-</table>
-</blockquote>
-<p>
-Kann durch erneutes Laden der Konfiguration verändert werden.
-</p>
-
-<p>
-Bei einem Failover beendet pgpool-II alle Kindprozesse, was in Folge
-auch alle aktiven Sitzungen von Nutzern von pgpool-II beendet. Danach
-startet pgpool das Kommando in <code>failover_command</code> und
-wartet auf dessen vollständige Abarbeitung. Erst dann startet
-pgpool-II wieder neue Kindprozesse und ist damit wieder bereit
-Verbindungen von Nutzern zu akzeptieren.
-</p>
-
-<dt><a name="FAILBACK_COMMAND"></a>failback_command
-<dd>
-<p>
-Spezifiziert einen Befehl, der ausgeführt wird, wenn ein Knoten zum
-Cluster hinzugefügt wird. pgpool-II ersetzt die folgenden
-Spezialzeichen:
-</p>
-<blockquote>
-<table border>
-<tr><td>Spezialzeichen</td><td>Beschreibung</td></tr>
-<tr><td>%d</td><td>Backend ID des hinzugefügten Knotens</td></tr>
-<tr><td>%h</td><td>Hostname des hinzugefügten Knotens</td></tr>
-<tr><td>%p</td><td>Portnummer des hinzugefügten Knotens</td></tr>
-<tr><td>%D</td><td>Database Cluster Verzeichnis des hinzugefügten Knotens</td></tr>
-<tr><td>%M</td><td>Id des bisherigen Master-Knotens</td></tr>
-<tr><td>%m</td><td>Id des neuen Master-Knotens</td></tr>
-<tr><td>%H</td><td>Hostname des neuen Master-Knotens</td></tr>
-<tr><td>%P</td><td>Id des bisherigen primären Knotens</td></tr>
-<tr><td>%%</td><td>'%'-Zeichen</td></tr>
-</table>
-</blockquote>
-<p>
-Kann durch erneutes Laden der Konfiguration verändert werden.
-</p>
-
-<dt><a name="FOLLOW_MASTER_COMMAND"></a>follow_master_command</dt>
-<dd>
-<p>
-Spezifiziert einen Befehl, der im Master/Slave Betrieb mit Streaming
-Replication ausgeführt wird, wenn der Master ausfällt.  Pgpool-II
-ersetzt die folgenden Spezialzeichen:
-</p>
-
-<blockquote>
-<table border>
-<tr><td>Spezialzeichen</td><td>Beschreibung</td></tr>
-<tr><td>%d</td><td>Backend ID des ausgefallenen Knotens.</td></tr>
-<tr><td>%h</td><td>Hostname des ausgefallenen Knotens.</td></tr>
-<tr><td>%p</td><td>Portnummer des ausgefallenen Knotens.</td></tr>
-<tr><td>%D</td><td>Database Cluster Verzeichnis des ausgefallenen Knotens.</td></tr>
-<tr><td>%M</td><td>Id des bisherigen Master-Knotens.</td></tr>
-<tr><td>%m</td><td>Id des neuen Master-Knotens.</td></tr>
-<tr><td>%H</td><td>Hostname des neuen Master-Knotens.</td></tr>
-<tr><td>%P</td><td>Id des bisherign primären Knotens.</td></tr>
-<tr><td>%%</td><td>'%'-Zeichen</td></tr>
-</table>
-</blockquote>
-<p>
-Kann durch erneutes Laden der Konfiguration verändert werden.
-</p>
-
-<p>
-If follow_master_command is not empty, when a master failover is
-completed in master/slave streaming replication, pgpool degenerate all
-nodes excepted the new master and starts new child processes to be
-ready again to accept connections from clients. After this, pgpool run
-the command set into the 'follow_master_command' for each degenerated
-nodes. Typically the command should be used to recover the slave from
-the new master by call the pcp_recovery_node command for example.
-</p>
-
-  <dt><a name="FAIL_OVER_ON_BACKEND_ERROR"></a>fail_over_on_backend_error</dt>
-  <dd>
-      <p>
-Wenn auf 'true' gesetzt, so wird pgpool-II bei einem Fehler beim
-Senden zu einem PostgreSQL-Knoten die Failover-Prozedur starten. Dies
-entspricht dem Verhalten von pgpool-II 2.2.x und früher. Ist dieser
-Parameter auf 'false' gesetzt, wird empfohlen die Verbindungsprüfung
-(health check) einzuschalten.
-
-Beim Dektivieren dieser Funktion ist zu bedenken, dass pgpool-II
-trotzdem bei einem Fehler während des Verbindungsaufbaus zu einem
-PostgreSQL-Knoten die Failover-Prozedur startet, z.B. auch im Falle
-eines 'Administrative Shutdown' von PostgreSQL. Kann durch erneutes
-Laden der Konfiguration verändert werden.
-</p>
-</dd>
-
-  <dt><a name="IGNORE_LEADING_WHITE_SPACE"></a>ignore_leading_white_space</dt>
-  <dd>
-      <p>Im Lastverteilungs-Modus ignoriert pgpool-II anführende
-      Leerzeichen vor einer SQL Abfrage. Dies ist speziell im
-      Zusammenhang mit APIs wie DBI/DBD:Pg nützlich, welche
-      Leerzeichen hinzufügen. Kann durch erneutes Laden der
-      Konfiguration verändert werden.
-       </p>
-  </dd>
-
-  <dt><a name="LOG_STATEMENT"></a>log_statement</dt>
-  <dd>
-      <p>Wenn auf 'true' gesetzt, so schreibt pgpool-II Log-Einträge
-      für SQL Abfragen, sehr ähnlich zum log_statement Parameter in
-      PostgreSQL selbst. Log-Einträge werden auch geschrieben, wenn
-      die debug Option von pgpool-II nicht aktiviert wurde. Kann durch
-      erneutes Laden der Konfiguration verändert werden.
-       </p>
-  </dd>
-
-  <dt><a name="LOG_PER_NODE_STATEMENT"></a>log_per_node_statement</dt>
-  <dd>
-      <p>Ähnlich wie der obige log_statement Parameter, schreibt aber
-      Log-Einträge für jeden Datenbank-Knoten separat. Dies kann
-      z.B. verwendet werden, um zu prüfen, ob die Daten korrekt
-      repliziert werden. Kann durch erneutes Laden der Konfiguration
-      verändert werden.</p>
-  </dd>
-
-  <dt><a name="LOG_HOSTNAME"></a>log_hostname</dt>
-  <dd>
-      <p>Ist dieser Parameter auf 'true' gesetzt, so zeigt das 'ps'
-      Kommando im Status den Hostnamen des aktuellen Clients, statt
-      dessen IP Adresse. Ist log_connections aktiviert, so schreibt
-      pgpool-II auch dort den Hostnamen. Kann durch erneutes Laden der
-      Konfiguration verändert werden.</p>
-  </dd>
-    
-  <dt><a name="LOG_CONNECTIONS"></a>log_connections</dt>
-  <dd>
-      <p>Ist dieser Parameter auf 'true' gesetzt, so werden alle
-      einkommenden Verbindungen im Log registriert. Kann durch
-      erneutes Laden der Konfiguration verändert werden.
-    </p>
-  </dd>
-    
-  <dt><a name="ENABLE_POOL_HBA"></a>enable_pool_hba</dt>
-  <dd>
-      <p>Gibt an, ob <code>pool_hba.conf</code> zur Authentifizierung
-      genutzt werden soll. Siehe <a href="#hba">Aufsetzen von
-      pool_hba.conf zur Authentifizierung</a>. Kann durch erneutes
-      Laden der Konfiguration verändert werden.</p>
-    </p>
-  </dd>
-
-  <dt><a name="BACKEND_HOSTNAME"></a>backend_hostname</dt>
-  <dd>
-      <p>Spezifiziert wie pgpool-II zum PostgreSQL-Server verbinden
-      soll. Dieser Parameter kann nur beim Start von pgpool-II gesetzt
-      werden.
-      </p>
-      <p>
-      Bei der Kommunikation via TCP/IP ist ein Hostnamen oder eine IP
-      Adresse anzugeben. Für die Verwendung von UNIX Domain Sockets
-      ist der Pfad des Verzeichnisses zur Socket-Datei anzugeben,
-      welcher zwingend mit einem Schrägstrich ('<code>/</code>')
-      beginnen muss. Der Standardwert ist leer (<code>''</code>) und
-      veranlasst pgpool-II ein UNIX Domain Socket
-      in </code>/tmp</code> zu verwenden.
-      </p>
-      <p>
-      Mehrere PostgreSQL-Server können durch eine zusätzliche Nummer
-      am Ende des Parameternamens spezifiziert werden
-      (z.B. <code>backend_hostname0</code>). Diese Nummer wird
-      "Knoten-Id" genannt und beginnt bei 0. Der Knoten mit der Id 0
-      heisst "Master-Db". Sind mehrere Datenbank-Server definiert,
-      dann kann pgpool-II in einigen Modi auch weiterarbeiten, falls
-      die Master-Db nicht erreichbar ist. In solchen Fällen wird der
-      Knoten mit der nachstgrösseren Id zur neuen Master-Db.</p>
-
-	  <p>Achtung: die Id 0 hat keine spezielle Bedeutung im Modus mit
-	  Streaming Replication.  Stattdessen ist darauf zu achten,
-	  welcher Knoten der primäre ist.  Siehe
-	  <a href="#stream">Streaming Replication</a> für weitere
-	  Details.</p>
-
-      <p>Soll nur ein PostgreSQL-Server verwendet werden, dann sollte
-      <code>backend_hostname0</code> verwendet werden.</p>
-
-      <p>Zusätzliche Knoten können mit diesem Parameter durch ein
-      erneutes Laden der Konfiguration hinzugefügt werden. Bestehende
-      Knoten-Ids können aber nicht geändert werden, dies erfordert
-      einen Neustart von pgpool-II.
-      </p>
-  </dd>
-
-  <dt><a name="BACKEND_PORT"></a>backend_port</dt>
-  <dd>
-      <p>Gibt die Portnummer des PosgreSQL-Servers an. Mehrere Ports
-      können durch eine zusätzliche Nummer am Ende des Parameternamens
-      definiert werden (z.B. <code>backend_port0</code>). Um nur ein
-      Backend zu verwenden, ist <code>backend_port0</code> zu
-      verwenden.</p>
-
-      <p>Portnummern für zusätzliche Knoten können mit diesem
-      Parameter durch ein erneutes Laden der Konfiguration hinzugefügt
-      werden. Jene von bestehenden Knoten können aber nicht während
-      der Laufzeit verändert werden, dies erfordert einen Neustart von
-      pgpool-II.</p>
-  </dd>
-
-  <dt><a name="BACKEND_WEIGHT"></a>backend_weight</dt>
-  <dd>
-      <p>Gibt das Verhältnis der Lastverteilung an die Backends
-      an. Einzelne Gewichtungen für mehrere Backends können durch eine
-      Nummer am Ende des Parameters angegeben werden
-      (z.B. <code>backend_weight0</code>). Bei nur einem Knoten
-      (z.B. im Basis Modus) empfiehlt sich die Verwendung
-      von <code>backend_weight0</code> mit einem Wert von 1.0.</p>
-
-      <p>Gewichtungen für zusätzliche Knoten können mit diesem
-      Parameter durch ein erneutes Laden der Konfiguration hinzugefügt
-      werden. Das Ändern bestehender Werte erfordert einen
-      Neustart.</p>
-
-	  <p>Seit pgpool-II 2.2.6/2.3 und neuer wird auch das Ändern
-	  bestehender Werte unterstützt. Ein erneutes Laden der
-	  Konfiguration beeinflusst alle neuen Verbindungen. Dies ist
-	  speziell im Master/Slave Modus hilfreich, um zu verhindern, dass
-	  ein Slave Anfragen kriegt, während auf diesem administrative
-	  Arbeiten getätigt werden.</p>
-  </dd>
-
-  <dt><a name="BACKEND_DATA_DIRECTORY"></a>backend_data_directory</dt>
-  <dd>
-      <p>Gibt das PGDATA Verzeichnis der PostgreSQL Server an.
-      Mehrere Verzeichnisse können durch eine Nummer hinter dem
-      Parameter angegeben werden
-      (z.B. <code>backend_data_directory0</code>).  Dieser Parameter
-      ist nur dann erforderlich, wenn Online Recovery genutzt werden
-      soll.</p>
-
-	  <p>Dieser Parameter kann für neu hinzugefügte Knoten durch ein
-	  erneutes Laden der Konfiguration angegeben werden.  Um den Wert
-	  für bestehende Knoten zu aktualisieren ist allerdings ein
-	  Neustart von pgpool-II erforderlich.</p>
-  </dd>
-
-  <dt><a name="BACKEND_FLAG"></a>backend_flag</dt>
-  <dd>
-      <p>Controls various backend behavior.
-      Multiple backends can be specified by adding a number
-      at the end of the parameter name
-      (e.g. <code>backend_flag0</code>).
-      </p>
-	   <p>
-	   Currently followings are allowed.
-	   Multiple falgs can be specified by using "|".
-	   </p>
-	   <dl>
-		<dt>ALLOW_TO_FAILOVER</dt>
-			 <dd>
-			 Allow to failover or detaching backend.
-			 This is the default.
-			 You cannot specify with DISALLOW_TO_FAILOVER at a same time.
-			 </dd>
-		<dt>DISALLOW_TO_FAILOVER</dt>
-			 <dd>
-			 Disallow to failover or detaching backend.
-			 This is usefull when you protect backend by using HA(High Availability) softwares
-			 such as Heartbeat or Pacemaker.
-			 You cannot specify with ALLOW_TO_FAILOVER at a same time.
-			 </dd>
-	   </dl>
-  </dt>
-
-  <dt><a name="SSL">ssl</a></dt>
-  <dd>
-      <p>Wird ssl auf true gesetzt, so nutzt pgpool sowohl für die
-      Front- wie auch die Backend-Verbindung SSL-Verschlüsselung.
-      Auch <code>ssl_key</code> und und <code>ssl_cert</code> müssen
-      gesetzt sein, damit SSL korrekt funktioniert.</p>
-
-      <p>SSL ist per Voreinstellung nicht aktiviert.  Unterstützung
-      für OpenSSL muss vor dem Kompilieren gewählt werden, wie im
-      Abschnit zur <a href="#install">Installation</a>
-      beschrieben.</p>
-
-      <p>Der pgpool-II service muss neu gestartet werden, um SSL
-      Einstellungen zu verändern.</p>
-  </dd>
-
-  <dt><a name="SSL_KEY"></a>ssl_key</dt>
-  <dd>
-      <p>Vollständiger Pfad zum privaten Schlüssel (private key) der
-      für eingehende Verbindungen von den Frontends zu nutzen ist.</p>
-
-      <p>Diese Option hat keinen Standardwert.  Falls nicht gesetzt
-      wird SSL für eingehende Verbindungen deaktiviert.</p>
-  </dd>
-
-  <dt><a name="SSL_CERT"></a>ssl_cert</dt>
-  <dd>
-      <p>Vollständiger Pfad zum öffentlichen x509 Zertifikat, das für
-      eingehende Verbindungen von den Frontends zu nutzen ist.</p>
-
-	  <p>Auch diese Option hat keinen Standardwert.  Falls nicht
-	  gesetzt, wird SSL für eingehende Verbindungen deaktiviert.</p>
-  </dd>
-
-  <dt><a name="DEBUG_LEVEL"></a>debug_level</dt>
-  <dd>
-      <p>
-
-
-	   Debug message verbosity level. 0 means no message, greater than 1
-	   means more verbose message. Default value is 0.
-      </p>
-  </dd>
-
-  <dt><a name="RELCACHE_EXPIRE"></a>relcache_expire</dt>
-  <dd>
-      <p>
-	   Life time of relation cache in seconds. 0 means no cache
-	   expiration(the default).
-	   The relation cache is used for cache the query result against PostgreSQL
-	   system catalog to obtain various information including table structures
-	   or if it's a temporary table or not. The cache is maintained in a pgpool
-	   child local memory and being kept as long as it survives.
-	   If someone modify the table by using ALTER TABLE or some such, the relcache
-	   is not consistent anymore.
-	   For this purpose, relcache_expiration controls the life time of the cache.
-      </p>
-  </dd>
-  </dl>
-</dl>
-
-<h4>Generating SSL certificates</h4>
-<p>
-Certificate handling is outside the scope of this document.  The
-<a href="http://developer.postgresql.org/pgdocs/postgres/ssl-tcp.html">
-Secure TCP/IP Connections with SSL</a> page at postgresql.org has pointers
-with sample commands for how to generate self-signed certificates.
-</p>
-
-<h4>Failover in the raw Mode</h4>
-
-<p>Failover can be performed in raw mode if multiple servers are
-defined. pgpool-II usually accesses the backend specified by
-<code>backend_hostname0</code> during normal operation. If the
-backend_hostname0 fails for some reason, pgpool-II tries to access the
-backend specified by backend_hostname1. If that fails, pgpool-II tries
-the backend_hostname2, 3 and so on.</p>
-
-<h3><a name="connection_pool_mode"></a>Connection Pool Mode</h3>
-
-<p>In connection pool mode, all functions in raw mode and the
-connection pool function can be used.
-To enable this mode, you need to turn on "connection_cache".
-Following parameters take effect to connection pool.</p>
-
-<dl>
-  <dt><a name="MAX_POOL"></a>max_pool</dt>
-  <dd>
-      <p>The maximum number of cached connections in pgpool-II
-      children processes. pgpool-II reuses the cached connection if an
-      incoming connection is connecting to the same database with the
-      same username. If not, pgpool-II creates a new connection to the
-      backend. If the number of cached connections exceeds max_pool,
-      the oldest connection will be discarded, and uses that slot for
-      the new connection.
-
-      Default value is 4. Please be aware that the number of
-      connections from pgpool-II processes to the backends may reach
-      <code>num_init_children</code> * <code>max_pool</code>.
-      This parameter can only be set at server start. </p>
-  </dd>
-
-  <dt><a name="CONNECTION_LIFE_TIME"></a>connection_life_time</dt>
-  <dd>
-      <p>Cached connections expiration time in seconds. An expired
-      cached connection will be disconnected. Default is 0, which
-      means the cached connections will not be disconnected.</p>
-  </dd>
-
-  <dt><a name="RESET_QUERY_LIST"></a>reset_query_list</dt>
-  <dd>
-      <p>Specifies the SQL commands sent to reset the connection
-      to the backend when exiting a session. Multiple commands can be
-      specified by delimiting each by ";". Default is
-      the following, but can be changed to suit your system.
-
-      <pre>
-      reset_query_list = 'ABORT; DISCARD ALL'
-      </pre>
-
-<p>
-      Commands differ in each PostgreSQL versions. Here are the recommended settings.
-</p>
-<p>
-<table border>
-<tr><th>PostgreSQL version</th><th>reset_query_list value</th></tr>
-<tr><td>7.1 or before</td><td>ABORT</td></tr>
-<tr><td>7.2 to 8.2</td><td>ABORT; RESET ALL; SET SESSION AUTHORIZATION DEFAULT</td></tr>
-<tr><td>8.3 or later</td><td>ABORT; DISCARD ALL</td></tr>
-</table>
-</p>
-<ul>
-<li>"ABORT" is not issued when not in a transaction block for 7.4 or later.
-</ul>
-
-<p>
-You need to reload pgpool.conf upon modification of this directive.
-</p>
-</dd>
-</dl>
-
-<h4><p>Failover in the Connection Pool Mode</p></h4>
-
-<p>Failover in the connection pool mode is the same as in the raw mode.</p>
-
-<h3><a name="replication_mode"></a>Replication Mode</h3>
-
-<p>This mode enables data replication between the backends. The
-configuration parameters below must be set in addition to everything above.</p>
-
-<dl>
-  <dt><a name="REPLICATION_MODE"></a>replication_mode</dt>
-  <dd>
-      <p>Setting to true enables replication mode. Default
-      is false.</p>
-  </dd>
-
-  <dt><a name="LOAD_BALANCE_MODE"></a>load_balance_mode</dt>
-  <dd>
-      <p>When set to true, SELECT queries will be
-      distributed to each backend for load balancing. Default is
-      false.</p>
-      <p>This parameter can only be set at server start. </p>
-  </dd>
-
-  <dt><a name="FAILOVER_IF_AFFECTED_TUPLES_MISMATCH"></a>failover_if_affected_tuples_mismatch</dt>
-  <dd>
-	  <p>When set to true, if backends don't return the same number of affected
-    tuples during an INSERT/UPDATE/DELETE, 
-		the backends that differ from most frequent result set are degenerated.
-		If the frequencies are same, the group which includes master DB node(a DB node having the youngest node id) is remained and other groups are degenerated.
-		</p>
-	   <p>
-	  If set to false, the session is terminated and the backends are not
-	  degenerated. Default is false.</p>
-  </dd>
-
-  <dt><a name="REPLICATION_STOP_ON_MISMATCH"></a>replication_stop_on_mismatch</dt>
-  <dd>
-	  <p>When set to true, if all backends don't return the same packet kind,
-		the backends that differ from most
-	  frequent result set are degenerated. A typical use case is a SELECT
-	  statement being part of a transaction, replicate_select set to
-	  true, and SELECT returning a different number of rows among backends.
-	  Non-SELECT statements might trigger this though.
-	  For example, a backend succeeded in an UPDATE, while others
-	  failed.
-	  Note that pgpool does NOT examine the content of records
-	  returned by SELECT.
-	  If set to false, the session is terminated and the backends are not
-	  degenerated. Default is false.</p>
-  </dd>
-
-<dt><a name="WHITE_FUNCTION_LIST"></a>white_function_list</dt>
-<dd>
-<p>
-Specify a comma separated list of function names that <strong>do not</strong> 
-update the database. SELECTs using functions not specified in this list are 
-neither load balanced, nor replicated if in replication mode.
-In master slave mode, such SELECTs are sent to master (primary) only.
-</p>
-<p>You can use regular expression into the list to match function name, for example if you have prefixed all your read only function with 'get_' or 'select_'
-</p>
-<pre>
-white_function_list = 'get_.*,select_.*'
-</pre>
-</dd>
-
-<dt><a name="BLACK_FUNCTION_LIST"></a>black_function_list
-<dd>
-<p>
-Specify a comma separated list of function names that <strong>do</strong>
-update the database. SELECTs using functions specified in this list are neither 
-load balanced, nor replicated if in replication mode.
-In master slave mode, such SELECTs are sent to master(primary) only.
-</p>
-<p>You can use regular expression into the list to match function name, for example if you have prefixed all your updating functions with 'set_', 'update_', 'delete_' or 'insert_':
-</p>
-<pre>
-black_function_list = 'nextval,setval,set_.*,update_.*,delete_.*,insert_.*'
-</pre>
-<p>
-Only one of these two lists can be filled in a configuration.
-</p>
-<p>
-Prior to pgpool-II 3.0, nextval() and setval() were known to do
-writes to the database. You can emulate this by using white_function_list and
-black_function_list:
-</p>
-<p>
-<pre>
-white_function_list = ''
-black_function_list = 'nextval,setval,lastval,currval'
-</pre>
-</p>
-<p>
-Please note that we have lastval and currval in addition to nextval and setval.
-Though lastval() and currval() are not writing functions, it is wise to add lastval() and currval() to avoid errors in the case when these functions are accidentaly load balanced to other DB node.
-Because adding to black_function_list will prevent load balancing.
-</p>
-</dd>
-
-<dt><a name="REPLICATE_SELECT"></a>replicate_select</dt>
-<dd>
-<p>When set to true, pgpool-II replicates SELECTs in replication mode. If false,
-pgpool-II only sends them to the Master DB. Default is false.
-</p>
-<p>
-If a SELECT query is inside an explicit transaction block, replicate_select and 
-load_balance_mode will have an effect on how replication works.
-Details are shown below.
-</p>
-
-<p>
-<table border>
-
-<tr>
-<td>SELECT is inside a transaction block</td>
-<td>Y</td>
-<td>Y</td>
-<td>Y</td>
-<td>N</td>
-<td>N</td>
-<td>N</td>
-<td>Y</td>
-<td>N</td>
-</tr>
-
-<tr>
-<td>replicate_select is true</td>
-<td>Y</td>
-<td>Y</td>
-<td>N</td>
-<td>N</td>
-<td>Y</td>
-<td>Y</td>
-<td>N</td>
-<td>N</td>
-</tr>
-
-<tr>
-<td>load_balance_mode is true</td>
-<td>Y</td>
-<td>N</td>
-<td>N</td>
-<td>N</td>
-<td>Y</td>
-<td>N</td>
-<td>Y</td>
-<td>Y</td>
-</tr>
-
-<tr>
-<td>results(R:replication, M: send only to master, L: load balance)</td>
-<td>R</td>
-<td>R</td>
-<td>M</td>
-<td>M</td>
-<td>R</td>
-<td>R</td>
-<td>M</td>
-<td>L</td>
-</tr>
-</table>
-</p>
-  </dd>
-
-  <dt><a name="INSERT_LOCK"></a>insert_lock</dt>
-  <dd>
-      <p>If replicating a table with SERIAL data type, the SERIAL column
-value may differ between the backends. This problem is avoidable by
-locking the table explicitly (although, transactions' parallelism will
-be severely degraded). To achieve this, however, the following change must be 
-made:
-
-      <pre>
-      INSERT INTO ...
-      </pre>
-      <p>
-      to
-      </p>
-      <pre>
-      BEGIN;
-      LOCK TABLE ...
-      INSERT INTO ...
-      COMMIT;
-      </pre>
-
-      <p>When <code>insert_lock</code> is true, pgpool-II
-      automatically adds the above queries each time an INSERT is
-      executed (if already in transaction, it simply adds LOCK TABLE
-      ....).
-	</p>
-      <p>pgpool-II 2.2 or later, it automatically detects whether the table
-      has a SERIAL columns or not, so it will never lock the table if it does
-      not use SERIAL columns.
-	</p>
-	   <p>
-       pgpool-II 3.0 series until 3.0.4 uses a row lock against the sequence
-       relation, rather than table lock. This is intended to minimize lock
-       conflict with VACUUM (including autovacuum). However this will lead to
-       another problem. After transaction wraparound happens, row locking
-       against the sequence relation causes PostgreSQL internal error (more
-       precisely, access error on pg_clog, which keeps transaction status).
-       To prevent this, PostgreSQL core developers decided to disallow row
-       locking against sequences and this will break pgpool-II of course (the
-       &quot;fixed&quot; version of PostgreSQL will be released as 9.0.5,
-       8.4.9, 8.3.16 and 8.2.22).
-	   </p>
-       <p>
-       pgpool-II 3.0.5 or later uses a row lock against pgpool_catalog.insert_lock
-       table because new PostgreSQL disallows a row lock against the sequence
-       relation. So creating insert_lock table in all databases which are
-       accessed via pgpool-II beforehand is required. See <a href="#install">
-       Creating insert_lock table</a> for more details. If does not
-       exist insert_lock table, pgpool-II locks the insert target
-       table. This behavior is same as pgpool-II 2.2 and 2.3 series.
-       If you want to use insert_lock which is compatible with older
-       releases, you can specify lock method by configure script. See
-       <a href="#install">configure</a> for more details.
-       </p>
-	   <p>
-      You might want to have a finer (per statement) control:
-      </p>
-
-      <ol>
-	<li>set <code>insert_lock</code> to true, and add <code>/*NO
-	    INSERT LOCK*/</code> at the beginning of an INSERT
-	    statement for which you do not want to acquire the table
-	    lock.</li>
-
-	<li>set <code>insert_lock</code> to false, and add
-	    <code>/*INSERT LOCK*/</code> at the beginning of an INSERT
-	    statement for which you want to acquire the table lock.</li>
-      </ol>
-
-      <p>
-      Default value is false. If <code>insert_lock</code> is enabled,
-      the regression tests for PostgreSQL 8.0 will fail in transactions,
-      privileges, rules, and alter_table. The reason for this is that
-      pgpool-II tries to LOCK the VIEW for the rule test, and will
-      produce the following error message:</p>
-
-      <pre>
-      ! ERROR: current transaction is aborted, commands ignored until
-      end of transaction block
-      </pre>
-
-      <p>For example, the transactions test tries an INSERT into a table
-which does not exist, and pgpool-II causes PostgreSQL to acquire the
-lock before that. The transaction will be aborted, and the following
-INSERT statement produces the above error message.</p>
-
-
-<dt><a name="RECOVERY_USER"></a>recovery_user</dt>
-<dd>
-<p>
-This parameter specifies a PostgreSQL username for online recovery.
-It can be changed without restarting.
-</p>
-
-<dt><a name="RECOVERY_PASSWORD"></a>recovery_password</dt>
-<dd>
-<p>
-This parameter specifies a PostgreSQL password for online recovery.
-It can be changed without restarting.
-</p>
-
-<dt><a name="RECOVERY_1ST_STAGE_COMMAND"></a>recovery_1st_stage_command</dt>
-<dd>
-<p>
-This parameter specifies a command to be run by master(primary) PostgreSQL server at the first stage of online
-recovery. The command file must be put in the database cluster directory
-for security reasons.
-For example, if recovery_1st_stage_command = 'sync-command', then
-pgpool-II executes $PGDATA/sync-command.
-</p>
-<p>
-recovery_1st_stage_command will receive 3 parameters as follows:
-</p>
-<ol>
-<li>path to master(primary) database cluster</li>
-<li>PostgreSQL host name to be recovered</li>
-<li>path to database cluster to be recovered</li>
-</ol>
-</p>
-<p>
-Note that pgpool-II <b>accepts</b> connections and queries while
-recovery_1st_stage command is executed. You can retrieve and update
-data during this stage.
-</p>
-<p>
-This parameter can be changed without restarting.
-</p>
-
-<dt><a name="RECOVERY_2ND_STAGE_COMMAND"></a>recovery_2nd_stage_command</dt>
-<dd>
-<p>
-This parameter specifies a command to be run by master(primary) PostgreSQL server at the second stage of online
-recovery. The command file must be put in the database cluster directory
-for security reasons.
-
-For example, if recovery_2nd_stage_command = 'sync-command', then
-pgpool-II executes $PGDATA/sync-command.
-</p>
-<p>
-recovery_2nd_stage_command will receive 3 parameters as follows:
-</p>
-<ol>
-<li>path to master(primary) database cluster</li>
-<li>PostgreSQL host name to be recovered</li>
-<li>path to database cluster to be recovered</li>
-</ol>
-</p>
-<p>
-Note that pgpool-II <b>does not accept</b> connections and queries while
-recovery_2nd_stage_command is running. Thus if a client stays connected for a
-long time, the recovery command won't be executed. pgpool-II waits until all 
-clients have closed their connections. The command is only executed when no 
-client is connected to pgpool-II anymore.
-</p>
-<p>
-This parameter can be changed without restarting.
-</p>
-
-<dt><a name="RECOVERY_TIMEOUT"></a>recovery_timeout</dt>
-<dd>
-<p>
-pgpool does not accept new connections during the second stage. If a client
-connects to pgpool during recovery processing, it will have to wait for the end 
-of the recovery.
-</p>
-<p>
-This parameter specifies recovery timeout in sec. If this timeout is reached, 
-pgpool cancels online recovery and accepts connections. 0 means no wait.
-</p>
-<p>
-This parameter can be changed without restarting.
-</p>
-
-  <dt><a name="CLIENT_IDLE_LIMIT_IN_RECOVERY"></a>client_idle_limit_in_recovery</dt>
-  <dd>
-  <p> Similar to client_idle_limit but only takes effect in the second
-	   stage of recovery. A client being idle for client_idle_limit_in_recovery
-	   seconds since its last query will get disconnected.
-	   This is useful for preventing the pgpool recovery from being
-	   disturbed by a lazy client or if the TCP/IP connection between the client 
-	   and pgpool is accidentally down (a cut cable for instance).
-	   If set to -1, disconnect the client immediately.
-	   The default value for client_idle_limit_in_recovery is 0,
-	   which means the feature is turned off.
-  </p>
-  <p>
-	   If your clients are very busy, pgpool-II cannot enter the second stage of
-	   recovery whatever value of client_idle_limit_in_recovery you may choose. In 
-	   this case, you can set client_idle_limit_in_recovery to -1 so that pgpool-II 
-	   immediately disconnects such busy clients before entering the second stage.
-  </p>
-  <p>
-   You need to reload pgpool.conf if you change client_idle_limit_in_recovery.</p>
-
-<dt><a name="LOBJ_LOCK_TABLE"></a>lobj_lock_table</dt>
-<dd>
-<p>
-This parameter specifies a table name used for large object replication control. 
-If it is specified, pgpool will lock the table specified by
-lobj_lock_table and generate a large object id by looking into
-pg_largeobject system catalog and then call lo_create to create the large object.
-This procedure guarantees that pgpool will get the same large object id in all DB 
-nodes in replication mode. Please note that PostgreSQL 8.0 or older does not
-have lo_create, thus this feature will not work.
-</p>
-<p>
-A call to the libpq function lo_creat() will trigger this feature. Also
-large object creation through Java API (JDBC driver), PHP
-API (pg_lo_create, or similar API in PHP library such as PDO), and this same
-API in various programming languages are known to use a similar protocol,
-and thus should work.
-</p>
-<p>
-The following large object create operation will not work:
-<p>
-<ul>
-<li>lo_create of libpq
-<li>Any API of any language using lo_create
-<li>lo_import function in backend
-<li>SELECT lo_creat
-</ul>
-</p>
-<p>
-It does not matter what schema lobj_lock_table is stored in, but this table
-should be writable by any user. Here is an example showing how to create such 
-a table:
-</p>
-<p>
-<pre>
-CREATE TABLE public.my_lock_table ();
-GRANT ALL ON public.my_lock_table TO PUBLIC;
-</pre>
-</p>
-<p>
-The table specified by lobj_lock_table must be created beforehand. If
-you create the table in template1, any database created afterward will
-have it.
-</p>
-<p>
-If lobj_lock_table has empty string(''), the feature is disabled
-(thus large object replication will not work). The default value for
-lobj_lock_table is ''.
-</p>
-
-</dl>
-
-<h4><p>condition for load balancing</p></h4>
-<p>
-For a query to be load balanced, all the following requirements
-      must be met:
-<ul>
-	<li>PostgreSQL version 7.4 or later</li>
-	<li>the query must not be in an explicitly declared
-	    transaction (i.e. not in a BEGIN ~ END block)</li>
-    <li>it's not SELECT nextval or SELECT setval
-    <li>it's not SELECT INTO
-    <li>it's not SELECT FOR UPDATE nor FOR SHARE
-    <li>it starts with "SELECT" or one of COPY TO STDOUT, EXPLAIN, EXPLAIN ANALYZE SELECT...
-     ignore_leading_white_space = true will ignore leading white space.
-</ul>
-</p>
-<p>
-Note that you could suppress load balancing by inserting arbitrary
-comments just in front of the SELECT query:
-<pre>
-  /*REPLICATION*/ SELECT ...
-</pre>
-</p>
-
-<p>
-Please refer to <a href="#replicate_select">replicate_select</a> as well.
-See also a <a href="where_to_send_queries.pdf">flow chart</a>.
-</p>
-
-<p>
-<font color="red">
-Note: the JDBC driver has an autocommit option. If autocommit is false, the JDBC 
-driver sends "BEGIN" and "COMMIT" by itself. So pgpool cannot do any load 
-balancing. You need to call setAutoCommit(true) to enable autocommit.
-</font>
-</p>
-
-<h4><p>Failover in Replication Mode</p></h4>
-
-<p> pgpool-II degenerates a dead backend and continues the
-service. The service can be continued if there is at least one backend
-alive.</p>
-
-<h4><p>Specific errors in replication mode</p></h2>
-<p>
-In replication mode, if pgpool finds that the number of affected tuples by INSERT, UPDATE, DELETE are not same, it sends erroneous SQL statement to all DB nodes to abort the transaction if failover_if_affected_tuples_mismatch is set to false
-(degeneration occurs if it is set to true).
-In this case you will see following error messages on client terminal:
-<pre>
-   =# UPDATE t SET a = a + 1;
-   ERROR: pgpool detected difference of the number of update tuples Possible last query was: "update t1 set i = 1;"
-   HINT: check data consistency between master and other db node
-</pre>
-You will see number of updated rows in PostgreSQL log(in this case DB node 0 has 0 updated row and DB node 1 has 1 updated row)
-<pre>
-2010-07-22 13:23:25 LOG:   pid 5490: SimpleForwardToFrontend: Number of affected tuples are: 0 1
-2010-07-22 13:23:25 LOG:   pid 5490: ReadyForQuery: Degenerate backends: 1
-2010-07-22 13:23:25 LOG:   pid 5490: ReadyForQuery: Number of affected tuples are: 0 1
-</pre>
-</p>
-
-<h3><a name="master_slave_mode"></a>Master/Slave Mode</h3>
-
-<p>This mode is used to couple pgpool-II with another master/slave
-replication software (like Slony-I and Streaming replication), which is responsible
-for doing the actual data replication.
-DB nodes' information (backend_hostname, backend_port,
-backend_weight, backend_flag and backend_data_directory if you need the
-online recovery fonctionality) must be set, in the same way as in the replication mode.
-In addition to that, set
-<code>master_slave_mode</code> and <code>load_balance_mode</code> to
-true. pgpool-II will then send queries that need to be replicated to the
-Master DB, and other queries will be load balanced if possible. Queries sent to
-Master DB because they cannot be balanced are of course accounted for in the
-load balancing algorithm.</p>
-
-
-<p>In master/slave mode, DDL and DML for temporary table can be executed on the 
-master node only.
-SELECT can be forced to be executed on the master as well, but for this you 
-need to put a /*NO LOAD BALANCE*/ comment before the SELECT statement.</p>
-
-<p>In the master/slave mode, <code>replication_mode</code> must be set
-to false, and <code>master_slave_mode</code> to true.</p>
-
-<p>The master/slave mode has a 'master_slave_sub mode'.
-The default is 'slony' which is
-suitable for Slony-I. You can also set it to 'stream', which should be
-set if you want to work with PostgreSQL's built-in replication system
-(Streaming Replication).
-The sample configuration file for the Slony-I sub-mode is
-pgpool.conf.sample-master-slave and the sample for the streaming replication
-sub-module is pgpool.conf.sample-stream.
-</p>
-<p>
-Please restart pgpool-II if you change any of the above parameters.
-</p>
-<p>
-You can set white_function_list and black_function_list to control load
-balancing in master/slave mode.
-See <a href="#white_function_list">white_function_list</a> for more details.
-</p>
-
-<h4><a name="stream">Streaming Replication</h4>
-<p>
-As stated above, pgpool-II can work together with Streaming Replication, which
-is available since PostgreSQL 9.0. To use it, enable 'master_slave' and
-set 'master_slave_sub_mode' to 'stream'. pgpool-II assumes that Streaming 
-Replication is used with Hot Standby at present, which means that the standby
-database is open read-only.
-The following directives can be used with this mode:
-</p>
-<p>
-<ul>
-<li>delay_threshold
-<p>
-Specifies the maximum tolerated replication delay of the standby against the
-primary server in WAL bytes.
-If the delay exceeds delay_threshold, pgpool-II does not send SELECT queries to
-the standby server anymore. Everything is sent to the primary server
-even if load balance mode is enabled, until the standby has caught-up.
-If delay_threshold is 0 or sr checking is disabled, the delay
-checking is not performed. This check is performed every 'sr_check_period'.
-The default value for delay_threshold is 0.
-You need to reload pgpool.conf if you change this directive.
-</p>
-
-<li>sr_check_period
-<p>
-This parameter specifies the interval between the streaming replication
-delay checks in seconds. Default is 0, which means the check is disabled.
-You need to reload pgpool.conf if you change sr_check_period.
-</p>
-
-<li>sr_check_user</dt>
-<p>
-The user name to perform streaming replication check. This user must
-exist in all the PostgreSQL backends.  Otherwise, the check causes
-an error.  Note that sr_check_user and sr_check_password are used
-even sr_check_period is 0.  To identify the primary server,
-pgpool-II sends function call request to each backend.
-sr_check_user and sr_check_password are used for this session.  You
-need to reload pgpool.conf if you change sr_check_user.
-</p>
-
-<li>sr_check_password</dt>
-<p>
-The password of the user to perform streaming replication check.
-If no password is required, specify empty string('').
-You need to reload pgpool.conf if you change sr_check_password.
-</p>
-
-<li>log_standby_delay
-<p>
-Specifies how to log the replication delay.
-If 'none' is specified, no log is written.
-If 'always', log the delay every time health checking is performed.
-If 'if_over_threshold' is specified, the log is written when the delay
-exceeds delay_threshold.
-The default value for log_standby_delay is 'none'.
-You need to reload pgpool.conf if you change this directive.
-</p>
-<p>
-You could monitor the replication delay by using the "show pool_status"
-command as well.
-The column name is "standby_delay#"(where '#' should be replaced by DB node id).
-</p>
-</ul>
-</p>
-
-<h4>Failover with Streaming Replication</h4>
-<p>
-In master/slave mode with streaming replication, if the primary or standby
-node goes down, pgpool-II can be set up to trigger a failover.
-Nodes can be detached automatically without further setup.
-While doing streaming replication, the standby node checks for the presence of a 
-"trigger file" and on finding it, the standby stops continuous recovery and goes
-into read-write mode. By using this, you can have the standby database take over 
-when the primary goes down.
-</p>
-<p>
-<strong>Caution: If you plan to use multiple standby nodes, we recommend
-to set a delay_threshold to prevent any query directed to other standby
-nodes from retrieving older data.
-</p>
-<p>
-If a second standby took over primary when the first standby has already
-taken over too, you would get bogus data from the second standby.
-We recommend not to plan this kind of configuration.
-</strong>
-</p>
-<p>
-How to setup a failover configuration is as follows.
-</p>
-<p>
-<ol>
- <li>Put a failover script somewhere (for example
-	  /usr/local/pgsql/bin) and give it execute permission.
-<pre>
-$ cd /usr/loca/pgsql/bin
-$ cat failover_stream.sh
-#! /bin/sh
-# Failover command for streaming replication.
-# This script assumes that DB node 0 is primary, and 1 is standby.
-# 
-# If standby goes down, do nothing. If primary goes down, create a
-# trigger file so that standby takes over primary node.
-#
-# Arguments: $1: failed node id. $2: new master hostname. $3: path to
-# trigger file.
-
-failed_node=$1
-new_master=$2
-trigger_file=$3
-
-# Do nothing if standby goes down.
-if [ $failed_node = 1 ]; then
-	exit 0;
-fi
-
-# Create the trigger file.
-/usr/bin/ssh -T $new_master /bin/touch $trigger_file
-
-exit 0;
-
-chmod 755 failover_stream.sh
-</pre>
-<li>Set failover_commmand in pgpool.conf.
-<pre>
-failover_command = '/usr/local/src/pgsql/9.0-beta/bin/failover_stream.sh %d %H /tmp/trigger_file0'
-</pre>
-
-<li>Set recovery.conf on the standby node.
-<a href="recovery.conf.sample">A sample recovery.conf</a> can be found
-	  under the PostgreSQL installation directory. Its name is
-	  "share/recovery.conf.sample".
-Copy recovery.conf.sample as recovery.conf inside the database cluster
-	  directory and edit it.
-<pre>
-standby_mode = 'on'
-primary_conninfo = 'host=name of primary_host user=postgres'
-trigger_file = '/tmp/trigger_file0'
-</pre>
-
-<li>Set postgresql.conf on the primary node.
-Below is just an example. You will need to tweak it for your environment.
-<pre>
-wal_level = hot_standby
-max_wal_senders = 1
-</pre>
-
-<li>Set pg_hba.conf on the primary node.
-Below is just an example. You will need to tweak it for your environment.
-<pre>
-host	replication	postgres		192.168.0.10/32		trust
-</pre>
-
-</ol>
-
-<p>
-Start primary and secondary PostgreSQL nodes to initiate Streaming replication.
-If the primary node goes down, the standby node will automatically start as a
-normal PostgreSQL and will be ready to accept write queries.
-</p>
-
-<h4>Streaming Replication</h4>
-<p>
-While using Streaming replication and Hot Standby, it is important to
-determine which query can be sent to the primary or the standby,
-and which one should not be sent to the standby.
-pgpool-II's Streaming Replication mode carefully takes care of this.
-In this chapter we'll explain how pgpool-II accomplishes this.
-</p>
-<p>
-We distinguish which query should be sent to which node by looking
-at the query itself.
-</p>
-<p>
-<ul>
- <li>These queries should be sent to the primary node only
-	  <ul>
-	   <li>INSERT, UPDATE, DELETE, COPY FROM, TRUNCATE, CREATE, DROP, ALTER, COMMENT
-	   <li>SELECT ... FOR SHARE | UPDATE
-	   <li>SELECT in transaction isolation level SERIALIZABLE
-	   <li>LOCK command more strict than ROW EXCLUSIVE MODE
-	   <li>Some transactional commands:
-			<ul>
-			 <li>BEGIN READ WRITE, START TRANSACTION READ WRITE
-			 <li>SET TRANSACTION READ WRITE, SET SESSION CHARACTERISTICS AS TRANSACTION READ WRITE
-			 <li>SET transaction_read_only = off
-			</ul>
-	   <li>Two phase commit commands: PREPARE TRANSACTION, COMMIT PREPARED, ROLLBACK PREPARED
-	   <li>LISTEN, UNLISTEN, NOTIFY
-	   <li>VACUUM
-	   <li>Some sequence functions (nextval and setval)
-	   <li>Large objects creation commands
-	  </ul>
- <li>These queries can be sent to both the primary node and the standby node.
-If load balancing is enabled, these types of queries can be sent to the
-standby node.
-However, if delay_threshold is set and the replication delay is higher than
-delay_threshold, queries are sent to the primary node.
-	  <ul>
-	   <li>SELECT not listed above
-	   <li>COPY TO
-	   <li>DECLARE, FETCH, CLOSE
-	   <li>SHOW
-	  </ul>
- <li>These queries are sent to both the primary node and the standby node
-	  <ul>
-	   <li>SET
-	   <li>DISCARD
-	   <li>DEALLOCATE ALL
-	  </ul>
-</ul>
-</p>
-
-<p>
-In an explicit transaction:
-<ul>
- <li>Transaction starting commands such as BEGIN are sent to the primary node.
- <li>Following SELECT and some other queries that can be sent to both
-	  primary or standby are executed in the transaction or on
-	  the standby node.
- <li><p>
-Commands which cannot be executed on the standby such as INSERT are sent
-to the primary.
-After one of these commands, even SELECTs are sent to the primary node,
-This is because these SELECTs might want to see the result of an INSERT
-immediately. This behavior continues until the transaction closes or aborts.
-</p>
-</ul>
-</p>
-
-<p>
-In the extended protocol, it is possible to determine if the query can
-be sent to standby or not in load balance mode while parsing the query.
-The rules are the same as for the non extended protocol.
-For example, INSERTs are sent to the primary node.
-Following bind, describe and execute will be sent to the primary node as well.
-</p>
-
-<p>
-[Note: If the parse of a SELECT statement is sent to the standby node due to load
-balancing, and then a DML statement, such as an INSERT, is sent to pgpool-II, 
-then the parsed SELECT will have to be executed on the primary node. Therefore,
-we re-parse the SELECT on the primary node.]
-<p>
-Lastly, queries that pgpool-II's parser thinks to be an error are sent to the
-primary node.
-</p>
-
-<h4>Online recovery with Streaming Replication</h4>
-<p>
-In master/slave mode with streaming replication, online recovery can be 
-performed.
-In the online recovery procedure, primary server acts as a master server and recoveres specified standby server.
-Thus the recovery procedure requires that the primary server is up and running.
-If the primary server goes down, and no standby server is promoted, you need to stop
-pgpool-II and all PostgreSQL servers and recover them manually.
-</p>
-
-<p>
-<ol>
- <li>Set recovery_user. Usually it's "postgres".
-<pre>
-recovery_user = 'postgres'
-</pre>
-<li>Set recovery_password for recovery_user to login database.
-<pre>
-recovery_password = 't-ishii'
-</pre>
-
-<li> Set recovery_1st_stage_command.
-The script for this stage should perform a base backup of the primary and
-restore it on the standby node.
-Place this script inside the primary database cluster directory and give it
-execute permission.
-Here is the sample script <a href="basebackup.sh">(basebackup.sh)</a> for
-a configuration of one primary and one standby.
-You need to setup ssh so that recovery_user can login from the primary to
-the standby without being asked for a password.
-<pre>
-recovery_1st_stage_command = 'basebackup.sh'
-</pre>
-<li>Leave recovery_2nd_stage_command be empty.
-<pre>
-recovery_2nd_stage_command = ''
-</pre>
-
-<li>Install required C and SQL functions to perform online recovery
-	  into each DB nodes.
-</p>
-
-<pre>
-# cd pgpool-II-x.x.x/sql/pgpool-recovery
-# make
-# make install
-# psql -f pgpool-recovery.sql template1
-</pre>
-
-<li>After completing online recovery, pgpool-II will start PostgreSQL on
-the standby node.
-Install the script for this purpose on each DB nodes.
-<a href="pgpool_remote_start">Sample script</a> is included in "sample"
-	  directory of the source code.
-This script uses ssh. You need to allow recovery_user to login from the
-primary node to the standby node without being asked password.
-</ol>
-</p>
-
-<p>
-That's it.
-Now you should be able to use pcp_recovery_node (as long as the standby
-node stops) or push "recovery" button of pgpoolAdmin to perform online recovery.
-If something goes wrong, please examin pgpool-II log, primary server log and standby server log(s).
-</p>
-<p>
-For your reference, here are the steps taken in the recovery procedure.
-<ol>
-<li>Pgpool-II connects to primary server's template1 database as user = recovery_user, password = recovery_password.
-<li>Primary server executes pgpool_recovery function.
-<li>pgpool_recovery function executes recovery_1st_stage_command.
-Note that PostgreSQL executes functions with database cluster as the current directory.
-Thus recovery_1st_stage_command is executed in the database cluster directory.
-<li>Primary server executes pgpool_remote_start function.
-This function executes a script named "pgpool_remote_start" in the database cluster directory, and it executes pg_ctl command on the standby server to be recovered via ssh.
-pg_ctl will start postmaster in background.
-So we need to make sure that postmaster on the standby actually starts.
-<li>pgpool-II tries to connect to the standby PostgreSQL as user = recovery_user and password = recovery_password.
-The database to be connected is "postgres" if possible. Otherwise "template1" is used.
-pgpool-II retries for <a href="#RECOVERY_TIMEOUT">recovery_timeout</a> seconds.
-If success, go to next step.
-<li>If <a href="#FAILBACK_COMMAND">failback_command</a> is not empty, pgpool-II parent process executes the script.
-<li>After failback_command finishes, pgpool-II restart all child processes.
-</ol>
-</p>
-
-<h3>Parallel Mode</h3>
-
-<p>This mode activates parallel execution of queries. Tables can be split, and 
-data distributed to each node. Moreover, the replication and the load balancing
-features can be used at the same time. In parallel mode, replication_mode and 
-load_balance_mode are set to true in pgpool.conf, master_slave is set to false, 
-and parallel_mode is set to true. When you change this parameter, restart pgpool-II. 
-</p>
-
-<h4><p>Configuring the System DB</p></h4>
-
-<p>To use the parallel mode, the System DB must be configured
-properly. The System DB contains rules, stored in a table, to choose an 
-appropriate backend to send partitioned
-data to. The System DB does not need to be created on the same host as
-pgpool-II. The System DB's configuration is done in
-<code>pgpool.conf</code>.</p>
-
-<dl>
-  <dt><a name="SYSTEM_DB_HOSTNAME"></a>system_db_hostname</dt>
-  <dd>
-      <p>The hostname where the System DB is. Specifying the
-      empty string ('') means the System DB is on the same host as
-      pgpool-II, and will be accessed via a UNIX domain socket.</p>
-  </dd>
-
-  <dt><a name="SYSTEM_DB_PORT"></a>system_db_port</dt>
-  <dd>
-      <p>The port number for the System DB</p>
-  </dd>
-
-  <dt><a name="SYSTEM_DBNAME"></a>system_dbname</dt>
-  <dd>
-      <p>The partitioning rules and other information will be defined
-      in the database specified here. Default value is:
-      <code>'pgpool'</code>.</p>
-  </dd>
-
-  <dt><a name="SYSTEM_DB_SCHEMA"></a>system_db_schema</dt>
-  <dd>
-      <p>The partitioning rules and other information will be defined
-      in the schema specified here. Default value is:
-      <code>'pgpool_catalog'</code>.</p>
-  </dd>
-
-  <dt><a name="SYSTEM_DB_USER"></a>system_db_user</dt>
-  <dd>
-      <p>The username to connect to the System DB.</p>
-  </dd>
-
-  <dt><a name="SYSTEM_DB_PASSWORD"></a>system_db_password</dt>
-  <dd>
-      <p>The password for the System DB. If no password is necessary,
-      set the empty string ('').</p>
-  </dd>
-
-  <dt><a name="SSL_CA_CERT"></a>ssl_ca_cert</dt>
-  <dd>
-      <p>
-      The path to a PEM format file containing one or more CA root
-      certificates, which can be used to verify the backend server
-      certificate.  This is analogous to the <code>-CAfile</code> option 
-      of the OpenSSL <code>verify(1)</code> command.
-      </p>
-
-      <p>
-      The default value for this option is unset, so no
-      verification takes place.  Verification will still occur if
-      this option is not set but a value has been given for 
-      <code>ssl_ca_cert_dir</code>.
-      </p>
-  </dd>
-
-  <dt><a name="SSL_CA_CERT_DIR"></a>ssl_ca_cert_dir</dt>
-  <dd>
-      <p>
-      The path to a directory containing PEM format CA certficate
-      files, which can be used to verify the backend server
-      certificate.  This is analogous to the <code>-CApath</code> option 
-      of the OpenSSL <code>verify(1)</code> command.
-      </p>
-
-      <p>
-      The default value for this option is unset, so no
-      verification takes place.  Verification will still occur if
-      this option is not set but a value has been given for 
-      <code>ssl_ca_cert</code>.
-      </p>
-  </dd>
-
-</dl>
-
-<h4><p>Initial Configuration of the System DB</p></h4>
-
-<p>First, create the database and schema specified in the
-<code>pgpool.conf</code> file. A sample script can be found in
-<code>$prefix/share/system_db.sql</code>. If you have specified a
-different database name or schema, change them accordingly in the script.
-
-<pre>
-psql -f $prefix/share/system_db.sql pgpool
-</pre>
-
-</p>
-
-<h4><p>Registering a Partitioning Rule</p></h4>
-
-<p>The rules for data partitioning must be registered into the
-<code>pgpool_catalog.dist_def</code> table.</p>
-
-<pre>
-CREATE TABLE pgpool_catalog.dist_def(
-dbname TEXT,                                              -- database name
-schema_name TEXT,                                         -- schema name
-table_name TEXT,                                          -- table name
-col_name TEXT NOT NULL CHECK (col_name = ANY (col_list)), -- partitioning key column name
-col_list TEXT[] NOT NULL,                                 -- names of table attributes
-type_list TEXT[] NOT NULL,                                -- types of table attributes
-dist_def_func TEXT NOT NULL,                              -- name of the partitioning rule function
-PRIMARY KEY (dbname,schema_name,table_name)
-);
-</pre>
-
-
-<h4><p>Registering a Replication Rule</p></h4>
-<p>
-Tables that are not distributed have to be replicated. When a query joins a
-distributed table with another table, pgpool gets the replication information
-from the pgpool_catalog.replicate_def table. A table has to be either replicated
-or distributed.
-</p>
-
-<pre>
-CREATE TABLE pgpool_catalog.replicate_def(
-	dbname TEXT,	    --database name
-	schema_name TEXT,	--schema name 
-	table_name TEXT,	--table name
-	col_list TEXT[] NOT NULL,	-- names of table attributes
-	type_list TEXT[] NOT NULL,	-- types of table attributes
-	PRIMARY KEY (dbname,schema_name,table_name)
-);
-</pre>
-
-<h4><p>Example for partitioning the pgbench tables</p></h4>
-
-<p>
-In this example, the accounts table is partitioned, and the branches and tellers 
-table are replicated.
-The accounts table and the branches table are joined by bid.
-The branches table is registered into the replication table.
-If the three tables (accounts, branches, and tellers)
-are to be joined, it is necessary to register a replication rule for 
-the tellers table too.
-</p>
-<pre>
-INSERT INTO pgpool_catalog.dist_def VALUES (
-	'pgpool',
-	'public',
-	'accounts',
-	'aid',
-	ARRAY['aid','bid','abalance','filler'],
-	ARRAY['integer','integer','integer','character(84)'],
-	'pgpool_catalog.dist_def_accounts'
-);
-
-INSERT INTO pgpool_catalog.replicate_def VALUES (
-	'pgpool',
-	'public',
-	'branches',
-	ARRAY['bid','bbalance','filler'],
-	ARRAY['integer','integer','character(84)']
-);
-</pre>
-
-<p>The partitioning rule function (here,
-pgpool_catalog.dist_def_accounts) takes a value for the partitioning
-key column, and returns the corresponding DB node ID. Note that the node ID
-must start from 0. Below is an example of this function for pgbench.
-</p>
-<pre>
-CREATE OR REPLACE FUNCTION pgpool_catalog.dist_def_accounts (val ANYELEMENT) RETURNS INTEGER AS '
-SELECT CASE WHEN $1 >= 1 and $1 <= 30000 THEN 0
-WHEN $1 > 30000 and $1 <= 60000 THEN 1
-ELSE 2
-</pre>
-
-<h2><a name="hba"></a>Aufsetzen von pool_hba.conf zur Authentifizierung (HBA)</h2>
-<p>
-  Just like the pg_hba.conf file for PostgreSQL, pgpool supports a similar
-  client authentication function using a configuration file called 
-  "pool_hba.conf".
-</p>
-<p>
-  When you install pgpool, pool_hba.conf.sample will be installed in
-  "/usr/local/etc", which is the default directory for configuration
-  files. Copy pool_hba.conf.sample as pool_hba.conf and edit it if necessary.
-  By default, pool_hba authentication is enabled. See "6. Setting up
-  pgpool.conf" for more detail.
-</p>
-<p>
-  The format of the pool_hba.conf file follows very closely PostgreSQL's 
-  pg_hba.conf format.
-</p>
-<pre>
-    local      DATABASE  USER  METHOD  [OPTION]
-    host       DATABASE  USER  CIDR-ADDRESS  METHOD  [OPTION]
-</pre>
-<p>
-  See "pool_hba.conf.sample" for a detailed explanation of each field.
-</p>
-<p>
-  Here are the limitations of pool_hba.
-<ul>
-<li>"hostssl" connection type is not supported</li>
-<p>
-    Though "hostssl" is invalid, pgpool-II 2.3 or later supports SSL.
-	See <a href="#ssl">SSL</a> for more details.
-</p>
-<li>"samegroup" for DATABASE field is not supported</li>
-<p>
-    Since pgpool does not know anything about users in the backend server,
-    the database name is simply checked against entries in the DATABASE
-    field of pool_hba.conf.
-</p>
-<li>group names following "+" for USER field is not supported</li>
-<p>
-    This is for the same reason as for the "samegroup" described above. A
-    user name is simply checked against the entries in the USER field
-    of pool_hba.conf.
-</p>
-<li>IPv6 for IP address/mask is not supported</li>
-<p>
-    pgpool currently does not support IPv6.
-</p>
-<li>Only "trust", "reject", "md5" and "pam" for METHOD field are supported</li>
-<p>
-    Again, this is for the same reason as for the "samegroup" described above.
-    pgpool does not have access to user/password information.
-</p>
-<p>
-To use md5 authentication, you need to register your name and password in
-"pool_passwd".
-See <a href="#md5">Authentication / Access Controls</a> for more details.
-</ul>
-<p>
-  Note that everything described in this section is about the authentication 
-  taking place between a client and pgpool; a client still has to go through
-  the PostgreSQL's authentication process. As far as pool_hba is concerned,
-  it does not matter if a user name and/or database name given by a client
-  (i.e. psql -U testuser testdb) really exists in the backend. pool_hba only
-  cares if a match in the pool_hba.conf is found or not.
-</p>
-
-<p>
-  PAM authentication is supported using user information on the host where
-  pgpool is executed. To enable PAM support in pgpool, specify "--with-pam"
-  option to configure:
-</p>
-<pre>
-    configure --with-pam
-</pre>
-<p>
-  To enable PAM authentication, you need to create a
-  service-configuration file for pgpool in the system's PAM
-  configuration directory (which is usually at "/etc/pam.d"). A sample
-  service-configuration file is installed as "share/pgpool.pam" under
-  the install directory.
-</p>
-
-<h2>Setting Query cache method</h2>
-<p>The Query cache can be used in all modes in pgpool-II.
-The query cache allow to reuse the SELECT result to boost the performance.
-Activating it in  
-pgpool.conf is done as follows:</p>
-<pre>
-enable_query_cache = true
-</pre>
-
-<p>
-You'll have to create the following table in the System DB too:
-</p>
-<pre>
-CREATE TABLE pgpool_catalog.query_cache (
-  hash TEXT,
-  query TEXT,
-  value bytea,
-  dbname TEXT,
-  create_time TIMESTAMP WITH TIME ZONE,
-  PRIMARY KEY(hash, dbname)
-);
-</pre>
-<p>
-However, you may have to modify the schema in this statement, if you don't use
-"pgpool_catalog".
-</p>
-<p>
-<strong>Caution: Current query cache implementation creates cache data on database.
-Thus enabling query cache may not contribute to boost performance.
-Contents of query cache is not updated even if the underlying table is get updated.
-You need to delete the cache data from the cache table or restart pgpool-II with -c (delete cache) option.
-</strong>
-</p>
-
-<h1>Starting/Stopping pgpool-II<a name="start"></a></h1>
-
-<p>All the backends and the System DB (if necessary) must be started
-before starting pgpool-II.
-</p>
-
-<pre>
-pgpool [-c][-f config_file][-a hba_file][-F pcp_config_file][-n][-D][-d]
-</pre>
-<p>
-<table>
-  <tr><td>-c<br/>--clear-cache</td><td>deletes query cache</tr>
-  <tr><td>-f config_file<br/>--config-file config-file</td><td>specifies pgpool.conf</tr>
-  <tr><td>-a hba_file<br/>--hba-file hba_file</td><td>specifies pool_hba.conf</tr>
-  <tr><td>-F pcp_config_file<br/>--pcp-password-file</td><td>specifies pcp.conf</tr>
-  <tr><td>-n<br/>--no-daemon</td><td>no daemon mode (terminal is not detached)</tr>
-  <tr><td>-D<br/>--discard-status</td><td>Discard pgpool_status file and do not restore previous status</tr>
-  <tr><td>-d<br/>--debug</td><td>debug mode</tr>
-</table>
-There are two ways to stop pgpool-II. One is using a PCP command
-(described later), the other using a pgpool-II command. Below is an example of the
-pgpool-II command.
-</p>
-
-<pre>
-pgpool [-f config_file][-F pcp_config_file] [-m {s[mart]|f[ast]|i[mmediate]}] stop
-</pre>
-<p>
-<table>
-  <tr><td><code>-m s[mart]</code><br/><code>--mode s[mart]</code></td>
-      <td>waits for clients to disconnect, and shutdown (default)</td></tr>
-  <tr><td><code>-m f[ast]</code><br/><code>--mode f[ast]</code></td>
-      <td>does not wait for clients; shutdown immediately</td></tr>
-  <tr><td><code>-m i[mmediate]</code><br/><code>--mode i[mmediate]</code></td>
-      <td>the same as <code>'-m f'</code></td></tr> </table>
-</p>
-<p>
-pgpool records backend status into the [logdir]/pgpool_status file. When pgpool 
-restarts, it reads this file and restores the backend status. This will prevent 
-a difference in data among DB nodes which might be caused by following scenario:
-<ol>
-<li>A backend suddenly stops and pgpool executes the fail over procedure
-<li>An update occurs on one of the active DBs through pgpool
-<li>The administrator decides to stop pgpool
-<li>Someone decides to restart the stopping DB without notifying the admin
-<li>The administrator restarts pgpool
-</ol>
-</p>
-<p>
-If for some reason, for example, the stopped DB has been synced with the 
-active DB by another means, pgpool_status can be removed safely before 
-starting pgpool.
-</p>
-
-<h1>Reloading pgpool-II configuration files<a name="reload"></a></h1>
-<p>pgpool-II can reload configuration files without restarting.
-</p>
-
-<pre>
-pgpool [-c][-f config_file][-a hba_file][-F pcp_config_file] reload
-</pre>
-<p>
-<table>
-  <tr><td>-f config_file<br/>--config-file config-file</td><td>specifies pgpool.conf</tr>
-  <tr><td>-a hba_file<br/>--hba-file hba_file</td><td>specifies pool_hba.conf</tr>
-  <tr><td>-F pcp_config_file<br/>--pcp-password-file</td><td>specifies pcp.conf</tr>
-</table>
-
-<p>
-Please note that some configuration items cannot be changed by
-reloading. New configuration takes effect after a change for new sessions.
-</p>
-
-<h1><a name="show-commands"></a>SHOW commands</h1>
-<h2>Overview</h2>
-<p>
-pgpool-II provides some information via the SHOW command. SHOW is a real SQL
-statement, but pgPool-II intercepts this command if it asks for specific
-pgPool-II information. Available options are:
-<ul>
-  <li>pool_status, to get the configuration</li>
-  <li>pool_nodes, to get the nodes information</li>
-  <li>pool_processes, to get information on pgPool-II processes</li>
-  <li>pool_pools, to get information on pgPool-II pools</li>
-  <li>pool_version, to get the pgPool_II release version</li>
-</ul>
-</p>
-<p>Other than "pool_status" are added since pgpool-II 3.0.
-<p>
-<u>Note</u> : The term 'pool' refers to the pool of PostgreSQL sessions owned by one pgpool process,
-not the whole sessions owned by pgpool.
-</p> 
-</p>
-<p>the "pool_status" SQL statement was already available in previous releases,
-but the other ones have appeared in release 3.0.</p>
-<h2>pool_status</h2>
-<p>"SHOW pool_status" sends back the list of configuration parameters with
-their name, value, and description. Here is an excerpt of the result:
-<pre>
-benchs2=# show pool_status;
-             item              |              value              |                           description                            
--------------------------------+---------------------------------+------------------------------------------------------------------
- listen_addresses              | 127.0.0.1                       | host name(s) or IP address(es) to listen to
- port                          | 9999                            | pgpool accepting port number
- socket_dir                    | /tmp                            | pgpool socket directory
- num_init_children             | 5                               | # of children initially pre-forked
- child_life_time               | 300                             | if idle for this seconds, child exits
-</pre>
-</p>
-<h2>pool_nodes</h2>
-<p>"SHOW pool_nodes" sends back a list of all configured nodes. It
-displays the node id, the hostname, the port, the status, and the weight (only meaningful
-if you use the load balancing mode). The possible values in the status column
-are explained in the <a href="#pcp_node_info">pcp_node_info reference</a>.
-<pre>
-benchs2=# show pool_nodes;
-  id  |  hostname   | port | status | lb_weight     
-------+-------------+------+--------+-----------
-   0  | 127.0.0.1   | 5432 | 2      | 0.5
-   1  | 192.168.1.7 | 5432 | 3      | 0.5
-(2 lignes)
-</pre>
-</p>
-<h2>pool_processes</h2>
-<p>"SHOW pool_processes" sends back a list of all pgPool-II processes waiting
-for connections and dealing with a connection.
-</p>
-<p>
-It has 6 columns:
-<ul>
-<li>pool_pid is the PID of the displayed pgPool-II process</li>
-<li>start_time is the timestamp of when this process was launched</li>
-<li>database is the database name of the currently active backend for this process</li>
-<li>username is the user name used in the connection of the currently active backend for this process</li>
-<li>create_time is the creation time and date of the connection</li>
-<li>pool_counter counts the number of times this pool of connections (process) has been used by clients</li>
-</ul>
-</p>
-<p>This view will always return num_init_children lines.</p>
-<pre>
-benchs2=# show pool_processes;
-   pool_pid |     start_time      | database | username  |     create_time     | pool_counter 
-----------+---------------------+----------+-----------+---------------------+--------------
- 8465     | 2010-08-14 08:35:40 |          |           |                     | 
- 8466     | 2010-08-14 08:35:40 | benchs   | guillaume | 2010-08-14 08:35:43 | 1
- 8467     | 2010-08-14 08:35:40 |          |           |                     | 
- 8468     | 2010-08-14 08:35:40 |          |           |                     | 
- 8469     | 2010-08-14 08:35:40 |          |           |                     | 
-(5 lines)
-</pre>
-<h2>pool_pools</h2>
-<p>"SHOW pool_pools" sends back a list of pools handled by pgPool-II.
-their name, value, and description. Here is an excerpt of the result:
-</p>
-<p>
-It has 11 columns:
-<ul>
-<li>pool_pid is the PID of the pgPool-II process</li>
-<li>start_time is the time and date when this process was launched</li>
-<li>pool_id is the pool identifier (should be between 0 and max_pool-1)</li>
-<li>backend_id is the backend identifier (should be between 0 and the number of configured backends minus one)</li>
-<li>database is the database name for this process's pool id connection</li>
-<li>username is the user name for this process's pool id connection</li>
-<li>create_time is the creation time and date of this connection</li>
-<li>majorversion and minorversion are the version of the protocol used in this connection</li>
-<li>pool_counter counts the number of times this connection has been used by clients</li>
-<li>pool_backendpid is the PID of the PostgreSQL process</li>
-<li>pool_connected is a true (1) if a frontend is currently using this backend.</li>
-</ul>
-</p>
-<p>It'll always return num_init_children*max_pool lines.</p>
-<pre>
-  pool_pid |     start_time      | pool_id | backend_id | database | username  |     create_time     | majorversion | minorversion | pool_counter | pool_backendpid | pool_connected 
-----------+---------------------+---------+------------+----------+-----------+---------------------+--------------+--------------+--------------+-----------------+----------------
- 8465     | 2010-08-14 08:35:40 | 0       | 0          |          |           |                     |              |              |              |                 | 
- 8465     | 2010-08-14 08:35:40 | 1       | 0          |          |           |                     |              |              |              |                 | 
- 8465     | 2010-08-14 08:35:40 | 2       | 0          |          |           |                     |              |              |              |                 | 
- 8465     | 2010-08-14 08:35:40 | 3       | 0          |          |           |                     |              |              |              |                 | 
- 8466     | 2010-08-14 08:35:40 | 0       | 0          | benchs   | guillaume | 2010-08-14 08:35:43 | 3            | 0            | 1            | 8473            | 1
- 8466     | 2010-08-14 08:35:40 | 1       | 0          |          |           |                     |              |              |              |                 | 
- 8466     | 2010-08-14 08:35:40 | 2       | 0          |          |           |                     |              |              |              |                 | 
- 8466     | 2010-08-14 08:35:40 | 3       | 0          |          |           |                     |              |              |              |                 | 
- 8467     | 2010-08-14 08:35:40 | 0       | 0          |          |           |                     |              |              |              |                 | 
- 8467     | 2010-08-14 08:35:40 | 1       | 0          |          |           |                     |              |              |              |                 | 
- 8467     | 2010-08-14 08:35:40 | 2       | 0          |          |           |                     |              |              |              |                 | 
- 8467     | 2010-08-14 08:35:40 | 3       | 0          |          |           |                     |              |              |              |                 | 
- 8468     | 2010-08-14 08:35:40 | 0       | 0          |          |           |                     |              |              |              |                 | 
- 8468     | 2010-08-14 08:35:40 | 1       | 0          |          |           |                     |              |              |              |                 | 
- 8468     | 2010-08-14 08:35:40 | 2       | 0          |          |           |                     |              |              |              |                 | 
- 8468     | 2010-08-14 08:35:40 | 3       | 0          |          |           |                     |              |              |              |                 | 
- 8469     | 2010-08-14 08:35:40 | 0       | 0          |          |           |                     |              |              |              |                 | 
- 8469     | 2010-08-14 08:35:40 | 1       | 0          |          |           |                     |              |              |              |                 | 
- 8469     | 2010-08-14 08:35:40 | 2       | 0          |          |           |                     |              |              |              |                 | 
- 8469     | 2010-08-14 08:35:40 | 3       | 0          |          |           |                     |              |              |              |                 | 
-(20 lines)
-</pre>
-</p>
-<h2>pool_version</h2>
-<p>"SHOW pool_version" displays a string containing the pgPool-II release
-number. Here is an example of it:
-<pre>
-benchs2=# show pool_version;
-      pool_version      
-------------------------
- 3.0-dev (umiyameboshi)
-(1 line)
-</pre>
-</p>
-<h1><a name="online-recovery"></a>Online Recovery</h1>
-<h2>Overview</h2>
-<p>
-pgpool-II, while in replication mode, can sync a database and attach a node
-while still servicing clients. We call this feature "online recovery".
-</p>
-
-<p>
-A recovery target node must be in the detached state before doing online 
-recovery.
-
-If you wish to add a PostgreSQL server dynamically, add 'backend_hostname' and
-its associated parameters and reload pgpool.conf. pgpool-II registers this new
-node as a detached node.
-</p>
-
-<p>
-<font color="red">caution: Stop autovacuum on the master node (the
-first node which is up and running). Autovacuum may change the contents
-of the database and might cause inconsistency after online recovery if
-it's running. This applies only if you're recovering with a simple copy mecanism, such
-as the rsync one explained below. This doesn't apply if you're using PostgreSQL's
-PITR mechanism.</font>
-</p>
-
-<p>
-   If the target PostgreSQL server has already started, you need to shut it down.
-</p>
-
-<p>
-pgpool-II performs online recovery in two separated phases. There are a few 
-seconds or minutes when client will be waiting to connect to pgpool-II while a 
-recovery node synchronizes database. It follows these steps:
-
-  <ol>
-    <li> CHECKPOINT
-    <li> First stage of online recovery
-    <li> Wait until all clients have disconnected
-    <li> CHECKPOINT
-    <li> Second stage of online recovery
-    <li> Start up postmaster (perform pgpool_remote_start)
-    <li> Node attach
-  </ol>
-</p>
-
-<p>
-   The first step of data synchronization is called "first stage". Data is
-   synchronized during the first stage. In the first stage, data <b>can</b> be 
-   updated or retrieved from any table concurrently.
-</p>
-
-<p>
-  You can specify a script executed during the first stage. pgpool-II
-  passes three arguments to the script.
-
-  <ol>
-    <li> The database cluster path of a master node.
-    <li> The hostname of a recovery target node.
-    <li> The database cluster path of a recovery target node.
-  </ol>
-</p>
-
-<p>
-  Data synchronization is finalized during what is called "second
-  stage". Before entering the second stage, pgpool-II waits until all
-  clients have disconnected. It blocks any new incoming connection until
-  the second stage is over.
-
-  After all connections have terminated, pgpool-II merges updated data between 
-  the first stage and the second stage. This is the final data
-  synchronization step.
-</p>
-
-<p>
- <font color="red">
-  Note that there is a restriction about online recovery. If pgpool-II itself
-  is installed on multiple hosts, online recovery does not work
-  correctly, because pgpool-II has to stop all clients during the 2nd stage of 
-  online recovery. If there are several pgpool hosts, only one will have 
-  received the online recovery command and will block connections.
-</font>
-</p>
-
-<h2> Configuration for online recovery</h2>
-<p>
-Set the following parameters for online recovery in pgpool.conf.
-
-   <ul>
-    <li> backend_data_directory
-    <li> recovery_user
-    <li> recovery_password
-    <li> recovery_1st_stage_command
-    <li> recovery_2nd_stage_command
-   </ul>
-</p>
-
-
-<h2><a name="installing-c-functions"></a>Installing C language functions</h2>
-<p>
-You need to install the following C language function for online recovery into 
-the "template1" database of all backend nodes.
-
-Its source code is in pgpool-II tarball.
-</p>
-
-<pre>
-  pgpool-II-x.x.x/sql/pgpool-recovery/
-</pre>
-
-<p>
-Change directory there and do "make install".
-</p>
-
-<pre>
-  % cd pgpool-II-x.x.x/sql/pgpool-recovery/
-  % make install
-</pre>
-
-<p>
-Then, install the SQL function.
-</p>
-
-<pre>
-  % cd pgpool-II-x.x.x/sql/pgpool-recovery/
-  % psql -f pgpool-recovery.sql template1
-</pre>
-
-
-<h2> Recovery script deployment </h2>
-<p>
-We must deploy some data sync scripts and a remote start script into
-the database cluster directory ($PGDATA). Sample script files are available in
-pgpool-II-x.x.x/sample directory. 
-</p>
-
-<h3>Online recovery by PITR</h3>
-<p>
-Here is how to do online recovery by Point In Time Recovery (PITR), which is 
-available in PostgreSQL 8.2 and later versions.
-Note that all PostgreSQL servers involved need to have PITR enabled.
-</p>
-
-<p>
-A script to get a base backup on a master node and copy it to a
-recovery target node on the first stage is needed. The script can be named
-"copy-base-backup" for example. Here is the sample script.
-
-</p>
-
-<pre>
-  #! /bin/sh
-  DATA=$1
-  RECOVERY_TARGET=$2
-  RECOVERY_DATA=$3
-
-  psql -c "select pg_start_backup('pgpool-recovery')" postgres
-  echo "restore_command = 'scp $HOSTNAME:/data/archive_log/%f %p'" > /data/recovery.conf
-  tar -C /data -zcf pgsql.tar.gz pgsql
-  psql -c 'select pg_stop_backup()' postgres
-  scp pgsql.tar.gz $RECOVERY_TARGET:$RECOVERY_DATA
-</pre>
-
-<p>
-This script puts the master database in backup mode, generates the following 
-recovery.conf:
-</p>
-<pre>
-restore_command = 'scp master:/data/archive_log/%f %p'
-</pre>
-performs the backup, then puts the master database out of backup mode and copies
-the backup on the chosen target node.
-</p>
-
-<p>
-The second stage of the procedure is a script to force an XLOG file switch.
-This script is named "pgpool_recovery_pitr" here.
-It enforces a switch of the transaction log.
-For this purpose, pg_switch_xlog could be used.
-However it may return <b>before</b> the switch is done and this might lead to 
-failure of the online recovery procedure.
-Pgpool-II provides a safer function called "pgpool_switch_xlog" which will wait 
-until the transaction log switching is actually finished.
-pgpool_switch_xlog is installed during the procedure performed in the 
-<a href="#installing-c-functions">Installing C functions</a> section.
-</p>
-<p>
-Here is the sample script.
-</p>
-<p>
-<pre>
-#! /bin/sh
-# Online recovery 2nd stage script
-#
-datadir=$1		# master dabatase cluster
-DEST=$2			# hostname of the DB node to be recovered
-DESTDIR=$3		# database cluster of the DB node to be recovered
-port=5432		# PostgreSQL port number
-archdir=/data/archive_log	# archive log directory
-
-# Force to flush current value of sequences to xlog 
-psql -p $port -t -c 'SELECT datname FROM pg_database WHERE NOT datistemplate AND datallowconn' template1|
-while read i
-do
-  if [ "$i" != "" ];then
-    psql -p $port -c "SELECT setval(oid, nextval(oid)) FROM pg_class WHERE relkind = 'S'" $i
-  fi
-done
-
-psql -p $port -c "SELECT pgpool_switch_xlog('$archdir')" template1
-</pre>
-</p>
-
-<p>
-This flushing of sequences is only useful in replication mode: in this case, sequences have to have the
-same starting point on all nodes. It's not useful in master-slave mode. 
-
-The loop in the script forces PostgreSQL to emit current value of all sequences
-in all databases in the master node to the transaction log so that it is 
-propagated to the recovery target node.
-</p>
-
-<p>
-We deploy these scripts into the $PGDATA directory.
-</p>
-<p>
-Finally, we edit pgpool.conf.
-
-<pre>
-recovery_1st_stage_command = 'copy-base-backup'
-recovery_2nd_stage_command = 'pgpool_recovery_pitr'
-</pre>
-
-</p>
-
-<p>
-We have finished preparing online recovery by PITR.
-</p>
-
-<h4><p>pgpool_remote_start</p></h4>
-<p>
-This script starts up the remote host's postmaster process.
-pgpool-II executes it the following way.
-</p>
-
-<pre>
-  % pgpool_remote_start remote_host remote_datadir
-  remote_host:    Hostname of a recovery target.
-  remote_datadir: Database cluster path of a recovery target.
-</pre>
-
-<p>
-In this sample script, we start up the postmaster process over ssh.
-So you need to be able to connect over ssh without a password for it to work.
-</p>
-
-<p>
-If you recover with PITR, you need to deploy a base backup. PostgreSQL will 
-automatically start up doing a PITR recovery. Then it will accept
-connections.
-</p>
-
-<pre>
-#! /bin/sh
-DEST=$1
-DESTDIR=$2
-PGCTL=/usr/local/pgsql/bin/pg_ctl
-
-# Deploy a base backup
-ssh -T $DEST 'cd /data/; tar zxf pgsql.tar.gz' 2>/dev/null 1>/dev/null < /dev/null
-# Startup PostgreSQL server
-ssh -T $DEST $PGCTL -w -D $DESTDIR start 2>/dev/null 1>/dev/null < /dev/null &
-</pre>
-
-<h3>Online recovery with rsync.</h3>
-<p>
-PostgreSQL 7.4 does not have PITR.
-PostgreSQL 8.0 and 8.1 cannot force to switch transaction log.
-So rsync can be used to do online recovery.
-In the "sample" directory of pgpool-II's tarball,
-there is a recovery script named "pgpool_recovery". It uses the rsync
-command. pgpool-II calls the script with three arguments.
-</p>
-
-<pre>
-  % pgpool_recovery datadir remote_host remote_datadir
-  datadir:        Database cluster path of a master node.
-  remote_host:    Hostname of a recovery target node.
-  remote_datadir: Database cluster path of a recovery target node.
-</pre>
-
-<p>
-This script copies physical files with rsync over ssh. So you need to
-be able to connect over ssh without a password.
-</p>
-
-<p>
-Note about rsync:
-<ul>
- <li>-c (or --checksum) option is required to enable reliable file tranmitting
-
- <li>-z (or --compress) option does compression before transmitting
-	  data. This will be great for slower connection, but it might add too much
-	  CPU overhead for a 100Mbit or faster connections. In this case you
-	  might want not to use this option.
-
- <li>rsync 3.0.5 has great speed performance
-	  improvements (50% faster according to a report from pgpool-general
-	  mailing list.
-</ul>
-
-</p>
-
-<p>
-If you use pgpool_recovery, add the following lines into pgpool.conf.
-
-<pre>
-recovery_1st_stage_command = 'pgpool_recovery'
-recovery_2nd_stage_command = 'pgpool_recovery'
-</pre>
-</p>
-
-<h2>How to perform online recovery</h2>
-<p>
-In order to do online recovery, use the pcp_recovery_node command or
-pgpoolAdmin.
-</p>
-
-<p>
-Note that you need to pass a large number to the first argument of
-pcp_recovery_node. It is the timeout parameter in seconds. If you use 
-pgpoolAdmin, set "_PGPOOL2_PCP_TIMEOUT " parameter to a large number in
-pgmgt.conf.php.
-</p>
-
-<h1>PostgreSQL version up using online recovery</h1>
-<h2>replication mode case</h2>
-<p>
-You can update PostgreSQL on each node without stopping pgpool-II if pgpool-II operated in replication mode.
-Please note that active sessions from clients to pgpool-II will be disconnected while disconnecting and attaching DB nodes.
-Also please note that you cannot do major version up in the method described below
-(i.e. the version up should not require dump/restore).
-</p>
-
-<p>
-<ol>
-<li><p>
-Prepare online recovery.</p>
-<li><p>Version up should perform nodes which are not master node first.
-Stop PostgreSQL on a non-master node.
-Pgpool-II will detect PostgreSQL termination and degenerate emitting logs below.
-At this point all sessions connected to pgpool-II disconnected.
-<pre>
-2010-07-27 16:32:29 LOG:   pid 10215: set 1 th backend down status
-2010-07-27 16:32:29 LOG:   pid 10215: starting degeneration. shutdown host localhost(5433)
-2010-07-27 16:32:29 LOG:   pid 10215: failover_handler: set new master node: 0
-2010-07-27 16:32:29 LOG:   pid 10215: failover done. shutdown host localhost(5433)
-</pre>
-</p>
-
-<li><p>
-Version up PostgreSQL on the stopping node.
-You can overwrite old PostgreSQL, we recommend move old PostgreSQL somewhere so that you could recover it just in case however.
-</p>
-
-<li><p>
-If you install new PostgreSQL in different location from the old one and do not want to update your recovery script, you need to match the path by using tools including symbolic link.
-If you choose to overwrite, you can skip following steps till installation of C function step.
-You can execute online recovery immediately.
-</p>
-
-<li><p>
-Change installation directory of old PostgreSQL.
-Installting directory of PostgreSQL is supposed to be /usr/local/pgsql in following description.
-<pre>
-$ mv /usr/local/pgsql /usr/local/pgsql-old
-</pre>
-</p>
-
-<li><p>
-Create a symblic link to the localtion where newer version of PostgreSQL installed.
-This allow you to continue to use command search path you currently use.
-Installting directory of newer PostgreSQL is supposed to be /usr/local/pgsql-new in following description.
-<pre>
-$ ln -s /usr/local/pgsql-new /usr/local/pgsql
-</pre>
-</p>
-
-<li><p>
-If database directory is located under older PostgreSQL installation directory, you should create or copy so that newer PostgreSQL can access it.
-We use symbolic link in the following example.
-<pre>
-$ ln -s /usr/local/pgsql-old/data /usr/local/pgsql/data
-</pre>
-</p>
-
-<li><p>
-Install C functions into PostgreSQL. "Installing C functions" section may help you.
-Because online recovery copies database cluster, the last step installing functions using psql is not neccessary.
-Do make install.
-</p>
-
-<li><p>
-Do online recovery. You are done with one node version up.
-To execute online recovery, you can use pcp_recovery_node or pgpoolAdmin.
-</p>
-
-<li><p>
-Repeat steps above on each node. In the very last master node should be updated.
-You are done.
-</p>
-</ol>
-
-<h2>If you are using streaming replication</h2>
-<p>
-You can update standby PostgreSQL server without stopping pgpool-II.
-</p>
-
-<p>
-The procedure to update standby PostgreSQL servers are same as the one of replication mode.
-Please refer to "Online recovery with Streaming Replication" to set up recovery_1st_stage_command and recovery_2nd_stage_command.
-</p>
-
-<p>
-You cannot version up primary server without stopping pgpool-II.
-You need to stop pgpool-II while updating primary server.
-The procedure to update primary PostgreSQL server is same as the one standby server.
-The procedure to update primary PostgreSQL server is as follows:
-<ol>
-<li>Stop pgpool-II
-<li>Stop primary PostgreSQL
-<li>Update primary PostgreSQl
-<li>Start primary PostgreSQL
-<li>Start pgpool-II
-</ol>
-</p>
-
-<h1><a name="backup"></a>Backup</h1>
-<p>
-To back up backend PostgreSQL servers and system DB, you can physical
-backup, logical backup (pg_dump, pg_dumpall) and PITR in the same manner as PostgreSQL.
-Please note that using logical backup and PITR should be performed directory PostgreSQL,
-rather than via pgpool-II to avoid errors caused by load_balance_mode and replicate_select.
-</p>
-
-<h2>replication mode and master/slave mode</h2>
-<p>
-If pgpool-II is operated in replication mode or master/slave mode, take a backup on one DB nodes in the cluster.
-</p>
-
-<p>
-If you are using master/slave mode and asynchronous replication
-systems(Slony-I and streaming replication) and need the latest backup, you should take a backup on the master node.
-</p>
-
-<p>
-pg_dump takes ACCESS SHARE lock on database. Commands taking ACCESS
-EXECUTE lock, such as ALTER TABLE, DROP TABLE, TRUNCATE, REINDEX,
-CLUSTER and VACUUM FULL will wait for the completion of pg_dump because
-of lock conflict. Also this may affect the primary node even if you are
-doing pg_dump on standby.
-</p>
-
-<h2>Parallel mode</h2>
-<p>
-If you are using parallel mode and need to take a consistent backup, you need to stop pgpool-II.
-</p>
-
-<p>
-To use logical backup, stop applications and pgpool-II then perform pg_dump or pg_dumpall on all nodes.
-After finishing backup, start pgpool-II then start applications.
-</p>
-
-<p>
-To use PITR, please make sure that system times are identical on all
-nodes.  Prepare archive logging and take base backup.  After finishing
-backup, stop and restart applications or pgpool-II.  Record the time of
-stop and start.  This temporary stop will make consistent state among
-all over cluster.  If you need to restore form the base backup and
-archive log, set recovery_target_time of recovery.conf in the middle of
-the start/stop time.
-</p>
-
-<h2>Backuping of system DB</h2>
-<p>
-You need to backup system DB if pgpool-II is operated in parallel query
-mode or if you are using query cache.
-Backup database specified by system_db_dbname in pgpool.conf.
-
-<h1><a name="deploy"></a>Deploying pgpool-II</a></h1>
-<p>
-pgpool-II can run on a dedicated server, on the server where application
-server is running on or other servers.  In this section we discuss how
-to make those deployments and pros and cons.
-</p>
-
-<p>
-<ul>
-<dt>Dedicated server
-<dd>
-<p>
-Pgpool-II is running on a dedicated server.
-It's simple and pgpool-II is not affected by other server softwares.
-Obvious cons is you need to by more hardware.
-Also pgpool-II can be a single point of failure with this configuration
-(you can avoid this by using pgpool-HA described somewhere below).
-</p>
-
-<dt>Deploying on a web server or application server
-<dd>
-<p>
-Deploying pgpool-II on a server where Apache, JBoss, Tomcat or other web
-server and application servers.
-Since communication between pgpool-II and web servers and application servers
-is within a local machine, socket communication can be faster than inter sever communication.
-Also if you are using multiple web serves or application servers, you can avoid
-the single point of failure problem
-(in this case you must have identical pgpool.conf on each pgpool-II instanace).
-There are seveal things you should care about in this configuration:
-</p>
-<ul>
-<li>If the communication between pgpool-II and DB servers is not stable, it is possible
-that DB node #1 is down from a point of a pgpool-II instance, while it is up from other pgpool-II instance's point of view.
-To avoid this, you can multiplex the network connection.
-<li>While executing online recovery in replication mode, you need to stop all pgpool-II instances except the one which is doing online recovery.
-Othewise DB can be running into inconsistent state.
-In master slave mode+streaming replication mode, you do not need to stop other pgpool-II instances.
-You should not execute online recovery at the same time on multiple pgpool-II instances however.
-</ul>
-</p>
-
-<dt>Running pgpool-II on DB server
-<dd>
-<p>
-Running pgpool-II on the server as PostgreSQL is running on.
-You can avoid the single point of failure problem of pgpool-II with configuration.
-And obviously you do need to buy additional dedicated server.
-Problem with this configuration is, application need to aware that which DB server they should connect to.
-To solve the problem you can use virtual IP with pgpool-HA.
-</ul>
-</p>
-
-<h2>About pgpool-HA</h2>
-<p>
-Pgpool-HA is a high availability software for pgpool-II using hearbeat.
-Pgpool-HA is a sub probject of pgpool project as well as pgpool-II.
-Pgpool-HA can be available from pgpool development site as an open source softeware.
-</p>
-
-<h1><a name="troubleshooting"></a>Troubleshooting</h1>
-<p>
-This section describes problems and their workarounds while you are using
-pgpool-II.
-</p>
-<p>
-<ul>
-
-<dt>Health check failed
-<dd>
-<p>
-Pgpool-II's health checking feature detects DB nodes failure.
-</p>
-<p>
-<pre>
-2010-07-23 16:42:57 ERROR: pid 20031: health check failed. 1 th host foo at port 5432 is down
-2010-07-23 16:42:57 LOG:   pid 20031: set 1 th backend down status
-2010-07-23 16:42:57 LOG:   pid 20031: starting degeneration. shutdown host foo(5432)
-2010-07-23 16:42:58 LOG:   pid 20031: failover_handler: set new master node: 0
-2010-07-23 16:42:58 LOG:   pid 20031: failover done. shutdown host foo(5432)
-</pre>
-</p>
-<p>
-The log shows that the DB node 1 (host foo) goes down and disconnected (shutdown)
-from pgpool, and then that DB node 0 becomes new master.
-Check DB node 1 and remove the cause of failure. After that perform an online
-recovery against DB node 1 if possible.
-</p>
-
-<dt>Failed to read kind from frontend
-<dd>
-<p>
-<pre>
-2010-07-26 18:43:24 LOG:   pid 24161: ProcessFrontendResponse: failed to read kind from frontend. frontend abnormally exited
-</pre>
-<p>
-This log indicates that the frontend program didn't disconnect properly from 
-pgpool-II.
-The possible causes are: bugs of client applications, forced termination (kill) 
-of a client application, or temporary network failure.
-This kind of events don't lead to a DB destruction or data consistency problem.
-It's only a warning about a protocol violation.
-It is advised that you check the applications and networks if the
-message keeps on occurring.
-</p>
-
-<dt>Kind mismatch errors
-<dd>
-<p>
-It is possible that you get this error when pgpool-II operates in
-replication mode.
-</p>
-<pre>
-2010-07-22 14:18:32 ERROR: pid 9966: kind mismatch among backends. Possible last query was: "FETCH ALL FROM c;" kind details are: 0[T] 1[E: cursor "c" does not exist]
-</pre>
-<p>
-Pgpool-II waits for responses from the DB nodes after sending an SQL command 
-to them.
-This message indicates that not all DB nodes returned the same kind of response.
-You'll get the SQL statement which possibly caused the error after "Possible last query
-was:".
-Then the kind of response follows. If the response indicates an error, the
-error message from PostgreSQL is shown.
-Here you see "0[T]" displaying the DB node responses: "0[T]"(starting
-to send row description), and "1[E" indicates that DB node 1 returns an
-error with message "cursor "c" does not exist", while DB node 0 sends a row 
-description.
-<p>
-Caution: You will see this error when operating in master/slave mode as
-well.
-For example, even in the master/slave mode, SET command will be basically sent 
-to all DB nodes to keep all the DB nodes in the same state.
-</p>
-<p>
-Check the databases and resync them using online recovery if you find
-that they are out of sync.
-</p>
-
-<p>
-<dt>Pgpool detected difference of the number of inserted, updated or deleted tuples
-<dd>
-<p>
-In replication mode, pgpool-II detects a different number of
-INSERT/UPDATE/DELETE rows on affected nodes.
-</p>
-<p>
-<pre>
-2010-07-22 11:49:28 ERROR: pid 30710: pgpool detected difference of the number of inserted, updated or deleted tuples. Possible last query was: "update t1 set i = 1;"
-2010-07-22 11:49:28 LOG:   pid 30710: ReadyForQuery: Degenerate backends: 1
-2010-07-22 11:49:28 LOG:   pid 30710: ReadyForQuery: Affected tuples are: 0 1
-</pre>
-<p>
-In the example above, the returned number of updated rows by "update t1 set i = 1"
-was different among DB nodes.
-The next line indicates that DB 1 got degenerated (disconnected) as a 
-consequence, and that the number of affected rows for DB node 0 was 0, while 
-for DB node 1 that was 1.
-</p>
-<p>
-Stop the DB node which is suspected of having wrong data and do an online
-recovery.
-</ul>
-
-
-<h1>Restrictions<a name="restriction"></a></h1>
-
-<p>
-<h2>Functionalities of PostgreSQL</h2>
-<p>
-<ul>
-<li>If you use pg_terminate_backend() to stop a backend, this will trigger
-	 a failover.
-	 The reason why this happens is that PostgreSQL sends exactly the same
-	 message for a terminated backend as for a full postmaster shutdown.
-	 There is no workaround as of today. Please do not use this function.
-</ul>
-
-<p>
-<h2><a name="md5"></a>Authentication / Access Controls</h2>
-
-<p>
-<ul>
-  <li>In the replication mode or master/slave mode, trust, clear text
-      password, and pam methods are supported. md5 in also supported since pgpool-II 3.0.
-	   
-	   md5 is supported by using "pool_passwd". Here are the steps to enable
-	   md5 authentication:
-	   <ol>
-		<li>Login as the database's operating system user and type 
-		   "pg_md5 --md5auth --username=<your_username> <your_passwd>"
-			 user name and md5 encrypted password are registered into
-			 pool_passwd.
-			 If pool_passwd does not exist yet, pg_md5 command will
-			 automatically create it for you.</li>
-		<li> The format of pool_passwd is "username:encrypted_passwd".</li>
-		<li>You also need to add an appropriate md5 entry to pool_hba.conf.
-			 See <a href="#hba">Setting up pool_hba.conf for client
-			 authentication (HBA)</a> for more details.</li>
-		<li>Please note that the user name and password must be
-			 identical to those registered in PostgreSQL.</li>
-	   </ol>
-
-	   </li>
-  <li>In all the other modes, trust, clear text password, crypt, md5,
-      and pam methods are supported.</li>
-  <li>pgpool-II does not support pg_hba.conf-like access controls. If
-      TCP/IP connections are enabled, pgpool-II accepts all the
-      connections from any host. If needed, use iptables and such to
-      control access from other hosts. (PostgreSQL server accepting
-      pgpool-II connections can use pg_hba.conf, of course).</li>
-	   </ul>
-</p>
-
-<h2>Large objects</h2>
-<p>
-pgpool-II 2.3.2 or later supports large object replication if the backend is 
-PostgreSQL 8.1 or later.
-For this, you need to
-enable <a href="#lobj_lock_table">lobj_lock_table</a> directive in pgpool.conf.
-Large object replication using backend function lo_import is not supported, however.
-</p>
-
-<h2>Temporary tables in master/slave mode</h2>
-<p>
-Creating/inserting/updating/deleting temporary tables are always executed on the
-master(primary).
-With pgpool-II 3.0 or later, SELECT on these tables is executed on master as well.
-However if the temporary table name is used as a literal in SELECT, there's no 
-way to detect it, and the SELECT will be load balanced.
-That will trigger a "not found the table" error or will find another table 
-having same name.
-To avoid the problem, use /*NO LOAD BALANCE*/ SQL comment.
-</p>
-<p>
-<pre>
-Sample SELECT which causes a problem:
-SELECT 't1'::regclass::oid;
-</pre>
-</p>
-<p>
-psql's \d command uses literal table names.
-pgpool-II 3.0 or later checks if the SELECT includes any access to system 
-catalogs and always send these queries to the master.
-Thus we avoid the problem.
-</p>
-
-<h2>Functions, etc. In Replication Mode</h2>
-
-<p>There is no guarantee that any data provided using a context-dependent 
-mechanism (e.g. random number, transaction ID, OID, SERIAL, sequence), will be
-replicated correctly on multiple backends.</p>
-<p>For SERIAL, enabling insert_lock will help replicating data.
-insert_lock also helps SELECT setval() and SELECT nextval().</p>
-
-<p>In pgpool-II 2.3 or later, INSERT/UPDATE using CURRENT_TIMESTAMP,
-CURRENT_DATE, now() will be replicated correctly. INSERT/UPDATE for tables
-using CURRENT_TIMESTAMP, CURRENT_DATE, now() as their DEFAULT values will also
-be replicated correctly.
-This is done by replacing those functions by constants fetched from master at 
-query execution time.
-There are a few limitations however:
-<ul>
-<li>In pgpool-II 3.0 or before, the calculation of temporal data in table default value is not accurate in 
-some cases. For example, the following table definition:
-<pre>
-CREATE TABLE rel1(
-  d1 date DEFAULT CURRENT_DATE + 1
-)
-</pre>
-is treated the same as:
-<pre>
-CREATE TABLE rel1(
-  d1 date DEFAULT CURRENT_DATE
-)
-</pre>
-<p>
-pgpool-II 3.1 or later handles these cases correctly.
-Thus the column "d1" will have tomorrow as the default value.
-However this enhancement does not apply if extended protocols(used in JDBC, PHP PDO for example) or PREPARE are used.
-</p>
-<p>
-Please note that if the column type is not a temporal one, rewriting is
-not performed. Such example:
-<pre>
-foo bigint default (date_part('epoch'::text,('now'::text)::timestamp(3) with time zone) * (1000)::double precision)
-</pre>
-</p>
-<li>Suppose we have the following table:
-<pre>
-CREATE TABLE rel1(
-  c1 int,
-  c2 timestamp default now()
-)
-</pre>
-We can replicate
-<pre>
-INSERT INTO rel1(c1) VALUES(1) 
-</pre>
-since this turn into
-<pre>
-INSERT INTO rel1(c1, c2) VALUES(1, '2009-01-01 23:59:59.123456+09')
-</pre>
-However,
-<pre>
-INSERT INTO rel1(c1) SELECT 1
-</pre>
-cannot to be transformed, thus cannot be properly replicated in the current implementation.
-Values will still be inserted, with no transformation at all.
-</ul>
-</p>
-<p>Tables created by <code>CREATE TEMP TABLE</code> will be deleted at the end of
-the session by specifying DISCARD ALL in reset_query_list if you are using 
-PostgreSQL 8.3 or later.
-</p>
-<p>
-For 8.2.x or earlier, <code>CREATE TEMP TABLE</code> will not be
-deleted after exiting a session. It is because of the connection
-pooling which, from PostgreSQL's backend point of view, keeps the
-session alive. To avoid this, you must explicitly drop the
-temporary tables by issuing <code>DROP TABLE</code>, or use <code>CREATE TEMP
-TABLE ... ON COMMIT DROP</code> inside the transaction block.</p>
-
-<h2>Queries</h2>
-
-<p>Here are the queries which cannot be processed by pgpool-II</p>
-
-<h3>INSERT (for parallel mode)</h3>
-
-<p>You cannot use <code>DEFAULT</code> with the
-partitioning key column. For example, if the column x in the table t
-was the partitioning key column,
-
-<pre>
-INSERT INTO t(x) VALUES (DEFAULT);
-</pre>
-<p>
-is invalid. Also, functions cannot be used for this value either.
-</p>
-
-<pre>
-INSERT INTO t(x) VALUES (func());
-</pre>
-<p>
-Constant values must be used to INSERT with the partitioning
-key. <code>SELECT INTO</code> and <code>INSERT INTO ... SELECT</code>
-are also not supported.
-</p>
-
-<h3>UPDATE (for parallel mode)</h3>
-
-<p>Data consistency between the backends may be lost if the
-partitioning key column values are updated. pgpool-II does not
-re-partition the updated data.</p>
-
-<p>A transaction cannot be rolled back if a query has caused an error
-on some backends due to a constraint violation.</p>
-
-<p>If a function is called in the <code>WHERE</code> clause, that
-query might not be executed correctly, for example:
-<pre>
-UPDATE branches set bid = 100 where bid = (select max(bid) from beances);
-</pre>
-</p>
-
-<h3>SELECT ... FOR UPDATE (for parallel mode)</h3>
-
-<p>If a function is called in the <code>WHERE</code> clause, that
-query might not be executed correctly. For example:
-<pre>
-SELECT * FROM  branches where bid = (select max(bid) from beances) FOR UPDATE;
-</pre>
-</p>
-
-<h3>COPY (for parallel mode)</h3>
-
-<p><code>COPY BINARY</code> is not supported. Copying from files is
-also not supported. Only <code>COPY FROM STDIN</code> and <code>COPY
-TO STDOUT</code> are supported.</p>
-
-<h3>ALTER/CREATE TABLE (for parallel mode)</h3>
-
-<p>To update the partitioning rule, pgpool-II must be restarted in
-order to read them from the System DB.</p>
-
-<h3>Transaction (for parallel mode)</h3>
-
-<p><code>SELECT</code> statements executed inside a transaction block
-will be executed in a separate transaction. Here is an example:
-
-<pre>
-BEGIN;
-INSERT INTO t(a) VALUES (1);
-SELECT * FROM t ORDER BY a; <-- INSERT above is not visible from this SELECT statement
-END;
-</pre>
-
-<h3>Views / Rules (for parallel mode)</h3>
-
-<p>
-The same definition will be created on all the backends for views and rules.
-</p>
-
-<pre>
-SELECT * FROM a, b where a.i = b.i
-</pre>
-<p>
-<code>JOIN</code>s like above will be executed on each backend, and
-then merged with the results returned by each backend. Views and Rules
-that join across the nodes cannot be created.
-However, to JOIN tables that access data only in the same node, a VIEW can be made.
-This VIEW has to be registered in the pgpool_catalog.dist_def table. A col_name and 
-a dist_def_func will have to be registered too. These are used when an insert is
-performed on the view.
-</p>
-
-<h3>Functions / Triggers (for parallel mode)</h3>
-
-<p>The same definition will be created on all the backends for
-functions. Joining across the nodes, and accessing data on the other nodes cannot
-be performed inside the functions.</p>
-
-<h3>Extended Query Protocol (for parallel mode)</h3>
-
-<p>The extended query protocol used by JDBC drivers, etc. is not
-supported. The simple query protocol must be used. This means you can't use
-prepared statements.</p>
-
-<h3>Natural Join (for parallel mode)</h3>
-
-<p>The Natural Join is not supported.
-"ON join condition" or "USING (join_column)" must be used.</p>
-
-<h3>USING CLAUSE (for parallel mode)</h3>
-
-<p>The USING CLAUSE is converted to an ON CLAUSE by the query rewrite process.
-Therefore, when "*" is used at target list, the joined column(s) appear twice.</p>
-<p>
-Here is an example:
-</p>
-<p><pre>
-  =# SELECT * FROM t1 JOIN t2 USING(id);
-   id |  t  |   t
-  ----+-----+-------
-    1 | 1st | first
-  (1 row)
-</pre></p>
-<p>
-In the rewrite process "USING" is translated into "ON". So the
-effective result is as follows:
-</p><p><pre>
-  =# SELECT * FROM t1 JOIN t2 ON t1.id = t2.id;
-   id |  t  | id |   t
-  ----+-----+----+-------
-    1 | 1st |  1 | first
-  (1 row)
-</pre>
-</p>
-<p>
-Notice that column "t" is duplicated.
-</p>
-
-<h3>Multi-byte Characters (for all modes)</h3>
-
-<p>pgpool-II does not translate between different multi-byte
-characters. The encoding for the client, backend and System DB must be
-the same.</p>
-
-<h3>Multi-statement Query (for all modes)</h3>
-<p>
-pgpool-II cannot process multi-statement queries.
-</p>
-
-<h3>Deadlocks (for parallel mode)</h3>
-
-<p>Deadlocks across the backends cannot be detected. For example:
-</p>
-<pre>
-(tellers table is partitioned using the following rule)
-  tid <= 10  --> node 0
-  tid >= 10  --> node 1
-
-A) BEGIN;
-B) BEGIN;
-A) SELECT * FROM tellers WHERE tid = 11 FOR UPDATE;
-B) SELECT * FROM tellers WHERE tid = 1 FOR UPDATE;
-A) SELECT * FROM tellers WHERE tid = 1 FOR UPDATE;
-B) SELECT * FROM tellers WHERE tid = 11 FOR UPDATE;
-</pre>
-<p>
-In the case above, a single node cannot detect the deadlock, so
-pgpool-II will wait for the response indefinitely. This phenomenon
-can occur with any query that acquires row level locks.
-</p>
-<p>Also, if a deadlock occurs in one node, transaction states in each
-node will not be consistent. Therefore, pgpool-II terminates the
-process if a deadlock is detected.
-</p>
-<pre>
-pool_read_kind: kind does not match between master(84) slot[1] (69)
-</pre>
-
-<h3>Schemas (for parallel mode)</h3>
-
-<p>Objects in a schema other than public must be fully qualified like:
-</p>
-<pre>
-schema.object
-</pre>
-<p>
-pgpool-II cannot resolve the correct schema when the path is set as
-follows:
-</p>
-<pre>
-set search_path = xxx
-</pre>
-<p>
-and the schema name is omitted in a query.
-</p>
-<h3>table name - column name(for parallel mode)</h3>
-<p>
-Limitation object:Parallel mode
-</p>
-<p>
-A table or a column name cannot start by pool_.
-When rewriting queries, these names are used by internal processing. 
-</p>
-
-</p>
-<h2>System DB</h2>
-
-<h3>Partitioning Rules</h3>
-
-<p>Only one partitioning key column can be defined in one
-partitioning rule. Conditions like 'x or y' are not supported.</p>
-
-<h2>Environment Requirements</h2>
-
-<h3>libpq</h3>
-
-<p><code>libpq</code> is linked while building pgpool-II. libpq
-version must be 3.0. Building pgpool-II with libpq version 2.0 will
-fail. Also, the System DB must be PostgreSQL 7.4 or later.</p>
-
-<h2>Query Cache</h2>
-
-<p>Currently, the query cache must be deleted manually. pgpool-II does not
-invalidate old query cache automatically when the data is updated.</p>
-
-<h2>Compatibility with pgpool</h2>
-
-<h1>References<a name="reference"></a></h1>
-<h2>PCP Command Reference</h2>
-
-<h3>PCP Command List</h3>
-
-<p>PCP commands are UNIX commands which manipulate pgpool-II via the network.
-
-<pre>
-* pcp_node_count        - retrieves the number of nodes
-* pcp_node_info         - retrieves the node information
-* pcp_proc_count        - retrieves the process list
-* pcp_proc_info         - retrieves the process information
-* pcp_systemdb_info     - retrieves the System DB information
-* pcp_detach_node       - detaches a node from pgpool-II
-* pcp_attach_node       - attaches a node to pgpool-II
-* pcp_promote_node      - promote a new master node to pgpool-II
-* pcp_stop_pgpool       - stops pgpool-II
-</pre>
-</p>
-
-
-<h2>Common Command-line Arguments</h2>
-
-<p>There are five arguments common to all of the PCP commands. They
-give information about pgpool-II and authentication. Extra
-arguments may be needed for some commands.
-
-<pre>
-e.g.)  $ pcp_node_count 10 localhost 9898 postgres hogehoge
-
-First argument    - timeout value in seconds. PCP disconnects if
-                    pgpool-II does not respond in this many seconds.
-Second argument   - pgpool-II's hostname
-Third argument    - PCP port number
-Fourth argument   - PCP username
-Fifth argument    - PCP password
-</pre>
-
-<p>PCP usernames and passwords must be declared in
-<code>pcp.conf</code> in <code>$prefix/etc</code>
-directory. <code>-F</code> option can be used when starting pgpool-II
-if <code>pcp.conf</code> is placed somewhere else. The password does
-not need to be in md5 format when passing it to the PCP commands.</p>
-
-
-<h2>PCP Commands</h2>
-
-<p>All PCP commands display the results to the standard output.</p>
-
-
-<h3>pcp_node_count</h3>
-
-<pre>
-Format:
-pcp_node_count  _timeout_  _host_  _port_  _userid_  _passwd_
-</pre>
-
-<p>
-Displays the total number of nodes defined in <code>pgpool.conf</code>. It does 
-not distinguish between nodes status, ie attached/detached. ALL nodes are counted.
-</p>
-
-
-<h3><a name="pcp_node_info"/>pcp_node_info</h3>
-
-<pre>
-Format:
-pcp_node_info  _timeout_  _host_  _port_  _userid_  _passwd_  _nodeid_
-</pre>
-
-<p>
-Displays the information on the given node ID. Here is an output example:
-</p>
-
-<pre>
-$ pcp_node_info 10 localhost 9898 postgres hogehoge 0
-host1 5432 1 1073741823.500000
-
-The result is in the following order:
-1. hostname
-2. port number
-3. status
-4. load balance weight
-
-Status is represented by a digit from [0 to 3].
-0 - This state is only used during the initialization. PCP will never display it.
-1 - Node is up. No connections yet.
-2 - Node is up. Connections are pooled.
-3 - Node is down.
-</pre>
-<p>
-The load balance weight is displayed in normalized format.
-</p>
-
-<p>
-The --verbose option can help understand the output. For example:
-</p>
-
-<pre>
-$ pcp_node_info --verbose 10 localhost 9898 postgres hogehoge 0
-Hostname: host1
-Port    : 5432
-Status  : 1
-Weight  : 0.5
-</pre>
-
-<p>Specifying an invalid node ID will result in an error with exit
-status 12, and BackendError will be displayed.</p>
-
-<h3>pcp_proc_count</h3>
-<p>
-<pre>
-Format:
-pcp_proc_count  _timeout_  _host_  _port_  _userid_  _passwd_
-</pre>
-<p>
-Displays the list of pgpool-II children process IDs. If there is more than
-one process, IDs will be delimited by a white space.
-</p>
-<h3>pcp_proc_info</h3>
-<p>
-<pre>
-Format:
-pcp_proc_info  _timeout_  _host_  _port_  _userid_  _passwd_  _processid_
-</pre>
-<p>
-Displays the information on the given pgpool-II child process ID. The
-output example is as follows:
-</p>
-<pre>
-$ pcp_proc_info 10 localhost 9898 postgres hogehoge 3815
-postgres_db postgres 1150769932 1150767351 3 0 1 1467 1
-postgres_db postgres 1150769932 1150767351 3 0 1 1468 1
-
-The result is in the following order:
-1. connected database name
-2. connected username
-3. process start-up timestamp
-4. connection created timestamp
-5. protocol major version
-6. protocol minor version
-7. connection-reuse counter
-8. PostgreSQL backend process id
-9. 1 if frontend conncted 0 if not
-</pre>
-<p>
-If there is no connection to the backends, nothing will be
-displayed. If there are multiple connections, one connection's
-information will be displayed on each line multiple
-times. Timestamps are displayed in EPOCH format.
-</p>
-
-<p>
-The --verbose option can help understand the output. For example:
-</p>
-
-<pre>
-$ pcp_proc_info --verbose 10 localhost 9898 postgres hogehoge 3815
-Database     : postgres_db
-Username     : postgres
-Start time   : 1150769932
-Creation time: 1150767351
-Major        : 3
-Minor        : 0
-Counter      : 1
-PID          : 1467
-Connected    : 1
-Database     : postgres_db
-Username     : postgres
-Start time   : 1150769932
-Creation time: 1150767351
-Major        : 3
-Minor        : 0
-Counter      : 1
-PID          : 1468
-Connected    : 1
-</pre>
-
-<p>Specifying an invalid node ID will result in an error with exit
-status 12, and BackendError will be displayed.</p>
-
-<h3>pcp_systemdb_info</h3>
-<p>
-<pre>
-Format:
-pcp_systemdb_info  _timeout_  _host_  _port_  _userid_  _passwd_
-</pre>
-<p>
-Displays the System DB information. The output example is as follows:
-</p>
-<pre>
-$ pcp_systemdb_info 10 localhost 9898 postgres hogehoge
-localhost 5432 yamaguti '' pgpool_catalog pgpool 3
-yamaguti public accounts aid 4 aid bid abalance filler integer integer integer character(84) dist_def_accounts
-yamaguti public branches bid 3 bid bbalance filler integer integer character(84) dist_def_branches
-yamaguti public tellers bid 4 tid bid tbalance filler integer integer integer character(84) dist_def_tellers
-
-First, the System DB information will be displayed on the first
-line. The result is in the following order:
-1. hostname
-2. port number
-3. username
-4. password. '' for no password.
-5. schema name
-6. database name
-7. number of partioning rules defined
-</pre>
-<p>
-Second, partitioning rules will be displayed on the following lines. If
-there are multiple definitions, one definition will be displayed on
-each line multiple times. The result is in the following order:
-</p>
-<pre>
-1. targeted partitioning database name
-2. targeted partitioning schema name
-3. targeted partitioning table name
-4. partitioning key column name
-5. number of columns in the targeted table
-6. column names (displayed as many as said in 5.)
-7. column types (displayed as many as said in 5.)
-8. partitioning rule function name
-</pre>
-<p>
-If the System DB is not defined (i.e. not in pgpool-II mode, and query
-cache is disabled), it results in error with exit status 12, and
-BackendError will be displayed.</p>
-
-
-<h3>pcp_detach_node</h3>
-<pre>
-Format:
-pcp_detach_node  [-g] _timeout_  _host_  _port_  _userid_  _passwd_  _nodeid_
-</pre>
-<p>
-Detaches the given node from pgpool-II.
-If -g is given, wait until all clients are disconnected (unless
-client_idle_limit_in_recovery is -1 or recovery_timeout is expired).
-</p>
-
-
-<h3>pcp_attach_node</h3>
-<p>
-<pre>
-Format:
-pcp_attach_node  _timeout_  _host_  _port_  _userid_  _passwd_  _nodeid_
-
-Attaches the given node to pgpool-II.
-</pre>
-</p>
-
-<h3>pcp_promote_node</h3>
-<p>
-<pre>
-Format:
-pcp_promote_node  [-g] _timeout_  _host_  _port_  _userid_  _passwd_  _nodeid_
-
-Promotes the given node as new master to pgpool-II. In master/slave streaming replication only.
-If -g is given, wait until all clients are disconnected (unless
-client_idle_limit_in_recovery is -1 or recovery_timeout is expired).
-</pre>
-</p>
-
-<h3>pcp_stop_pgpool</h3>
-<pre>
-Format:
-pcp_stop_pgpool  _timeout_  _host_  _port_  _userid_  _passwd_  _mode_
-</pre>
-
-<p>
-Terminate the pgpool-II process with the given shutdown mode. The available
-modes are as follows:
-</p>
-
-<pre>
-s	- smart mode
-f	- fast mode
-i	- immediate mode
-</pre>
-<p>
-If the pgpool-II process does not exist, it results in error with exit
-status 8, and ConnectionError will be displayed.
-</p>
-<p>
-* Currently, there is no difference between the fast and immediate
-mode. pgpool-II terminates all the processes whether there are clients
-connected to the backends or not.</p>
-
-
-<h2>Exit Status</h2>
-
-<p>PCP commands exits with status 0 when everything goes well. If any
-error had occurred, it will exit with the following error status.
-
-<pre>
-UNKNOWNERR      1      Unknown Error (should not occur)
-EOFERR          2      EOF Error
-NOMEMERR        3      Memory shortage
-READERR         4      Error while reading from the server
-WRITEERR        5      Error while writing to the server
-TIMEOUTERR      6      Timeout
-INVALERR        7      Argument(s) to the PCP command was invalid
-CONNERR         8      Server connection error
-NOCONNERR       9      No connection exists
-SOCKERR         10     Socket error
-HOSTERR         11     Hostname resolution error
-BACKENDERR      12     PCP process error on the server (specifying an invalid ID, etc.)
-AUTHERR         13     Authorization failure
-</pre>
-</p>
-
-<h1>Inside information<a name="internal"></a></h1>
-<p>
-pgpool-II version 2.0.x brings extensive modifications, compared with the version 1.x 
-Please note that what follows doesn't apply to version 1.x.
-</p>
-
-<h2>Parallel execution engine</h2>
-<p>
-The parallel execution engine is built into pgpool-II. 
-This engine performs the same Query on each node, and drives the engine that
-transmits the result to the front end, depending on the nodes' answers.
-</p>
-
-<h2>Query Rewriting</h2>
-<p>
-This explains the Query rewriting that pgpool-II does in parallel mode. 
-</p>
-<p>
-In parallel mode, a query transmitted by the client goes through two stages of
-processing:
-</p>
-<ul>
-<li>Analysis of Query
-<li>Rewriting of Query
-</ul>
-<p>
-What follows explains these two processing steps:
-</p>
-<h3>Analysis of Query</h3>
-<h4><p>Introduction</p></h4>
-<p>
-The retrieval query submitted by the client goes through the SQL parser. It is then analyzed
-using information stored in the system DB. Execution status of each part
-of this query is updated using this information. This execution status stores
-where this node can be treated. For instance, if a table's data is distributed
-on several nodes (as declared in the catalog's pgpool_catalog.dist_def table),
-it has to be retrieved from all nodes. On the other hand, data from a table
-registered in pgpool_catalog.replicate_def is replicated, and can therefore
-be retrieved from any node. These states are 'P' when data has to be processed by
-all nodes, 'L' when it should be processed by one node. The 'S' status is a special
-case: it means that there is another step to be performed on the data after
-retrieving it from all nodes. For example, sorting data coming from a table 
-registered in the pgpool_catalog.dist_def table.
-</p>
-
-<p>
-The retrieval query is analyzed in the following order, and its execution status
-changes during this processing. Where the query will be processed depends on the
-final status of the main select.
-</p>
-
-<ol>
-  <li>Are UNION, EXTRACT, and INTERSECT used or not?
-  <li>What is the Execution status of FROM clause ?
-  <li>Change the execution status by TARGETLIST
-  <li>Change in execution status according to WHERE clause
-  <li>Change in execution status according to GROUP BY clause
-  <li>Change in execution status according to HAVING clause
-  <li>Change in execution status according to ORDER BY clause
-  <li>Changes into the LIMIT OFFSET predicate in the execution status. 
-  <li>Acquisition of the final execution status of SELECT
-</ol>
-
-<p>
-The relation between the final execution status of SELECT and the processing 
-place is as follows. 
-</p>
-
-<p>
-<table border>
-		<tr><td>Execution status</td><td>Processed place</td></tr>
-		<tr><td align=center>L</td><td>Query issued on either node. </td></tr>
-		<tr><td align=center>P</td><td>Returns data to the client by running the
-		same query on all nodes and using the parallel execution engine.</td></tr>
-		<tr><td align=center>S</td><td>After processing using the system DB, data
-		is returned to the client. </td></tr>
-</table>
-</p>
-
-<p>
-The above-mentioned rule also applies to Sub-Query. In the simple following 
-Query, if p1-table is registered in pgpool_catalog.dist_def table of the system 
-DB (p1-table is distributed), the final execution status of the subquery 
-becomes P, and as a result, the parent of the subquery, SELECT, also becomes P.
-</p>
-
-<pre>
-SELECT * FROM (SELECT * FROM P1-table) as P2-table;
-</pre>
-
-<p>
-Next, let's explain how the execution status changes concretely.
-Let's start with an example, to explain the FROM status.
-</p>
-
-<h4><p>Execution status of FROM clause</p></h4>
-<p>
-This is a retrieval Query (SELECT). The data set and its status (P,L and S) is 
-defined according to the FROM clause
-
-The execution status of the table is as follows: when there is only one table in
-the from clause, the execution status of the entire dataset is this table's
-execution status. When there are two or more tables or sub-queries in the FROM
-clause, the execution is decided according to the join method and the execution
-statuses, as show in the following table. 
-</p>
-
-<p>
-<table border>
-<tr><td>JOIN type</td><td align = center colspan = 3> LEFT OUTER JOIN </td><td align = center colspan = 3> RIGHT OUTER JOIN </td><td align = center colspan = 3>FULL OUTER JOIN</td><td align = center colspan = 3>Other</td></tr>
-		<tr><td align = center>left/right</td><td> P </td><td> L </td><td> S </td><td> P </td><td> L </td><td> S </td><td> P </td><td> L </td><td> S </td><td> P </td><td> L </td><td> S </td></tr>
-
-<tr><td align = center> P </td><td> S </td><td> P </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> P </td><td> S </td></tr>
-
-<tr><td align = center> L </td><td> S </td><td> L </td><td> S </td><td> P </td><td> L </td><td> S </td><td> S </td><td> L </td><td> S </td><td> P </td><td> L </td><td> S </td></tr>
-
-<tr><td align = center> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td></tr>
-
-</td></tr>
-</table>
-</p>
-
-<p>
-In the following examples, P1-table is in the P status.
-L1-table and L2-table are in the  L status.
-
-<pre>
-SELECT * FROM P1-table,L1-table,L2-table;
-</pre>
-
-
-P1-table (left) and L1-table (right) are joined, and according to the table they
-get the P status. With this P status, they are joined with the L2-table, in the L
-status, which is now in the P status too.
-</p>
-
-
-<h4><p>Changes in execution status because of TARGETLIST and WHERE clause</p></h4>
-<p>
-In a basic Query, the execution status is the one from the FROM clause.
-However, if there is a TARGETLIST, the execution status of the WHERE clause can
-change in the following cases.
-</p>
-<ol>
-	<li>When there is a subquery
-	<li>When there is an aggregate function or DISTINCT in TARGETLIST marked as 'P'
-	<li>When a column that does not exist in a table (data set) 
-	    in the FROM clause is used
-</ol>
-<p>
-In these cases, the final execution status of the subquery, the execution status of 
-TARGETLIST and the WHERE clause get the S status if the initial status was
-P or S.
-<p>
-In the following example, when the table used by the subquery is P, the final 
-execution status of the subquery gets the P status. Therefore, The execution 
-status of the WHERE clause gets the S status, whatever the execution status of 
-L1 is, and this query is run in the system DB. 
-<pre>
-	SELECT * FROM L1-table where L1-table.column IN (SELECT * FROM P1-table);
-</pre>
-<p>
-The FROM clause changes to the S status when there is an aggregate function in 
-a 'P' TARGETLIST, in order to perform the aggregate after all data has been
-acquired.
-Some optimization on the aggregate function is done under specific conditions. 
-</p>
-<p>
-A column that does not exist in a table can be used in a query. For instance, in
-the following correlated subquery:
-</p>
-<pre>
-	SELECT * FROM L1-table WHERE L1-table.col1 IN (SELECT * FROM P1-table WHERE P1-table.col = L1-table.col1);
-</pre>
-<p>
-This subquery refers to L1-table.col1, from the L1-table. The execution status 
-of the WHERE clause of the subquery is 'S'. 
-</p>
-<h4><p>Change in execution status because of GROUP BY, HAVING, ORDER BY and LIMIT/OFFSET</p></h4>
-
-<p>
-The execution status of the WHERE clause is changed to 'S' when there is any GROUP 
-BY, HAVING, or ORDER BY clause, or LIMIT/OFFSET predicate and status is 'P'. A
-query with no GROUP BY clause gets the execution status of the WHERE clause.
-In the same way, the execution status of the GROUP BY clause is 
-used when there is no HAVING clause. The ORDER BY clause and the LIMIT/OFFSET
-predicate are also similar in this behavior.
-</p>
-
-<h4><p>When UNION, EXTRACT, and INTERSECT are used</p></h4>
-<p>
-UNION, EXTRACT, and INTERSECT queries' status depends on the final execution 
-status of both the left and right SELECT statements. If both statements are L, the
-combined statement is L. If both statements are P, and the query is a UNION ALL
-the combined statement is P. For any other combination, the resulting status is
-S.
-</p>
-<h4><p>Acquisition of the final execution status of SELECT</p></h4>
-<p>
-If everything in the SELECT has a status of L, then the final execution status
-is L. The same rule applies for P. For any other combination, the final status is S.
-If the status is L, the load is distributed among nodes when loadbalance_mode is
-true and sent to the MASTER if false. For P, parallel processing is done with
-the parallel execution engine. For S, the query rewriting presented below is done.
-</p>
-
-<h3>Query rewriting</h3>
-<p>
-The Query is rewritten by using the execution status acquired while analyzing
-the query.
-Here is an example. The P1-table has the P status, the L1-table has the L status.
-
-</p>
-<pre>
-SELECT P1-table.col, L1-table.col 
-FROM P1-table,L1-table 
-where P1-table.col = L1-table.col 
-order by P1-table.col;
-</pre>
-
-<p>
-In this query, because there is an ORDER BY clause, the status is S.
-The FROM clause, the WHERE clause, and TARGETLIST are in the P status.
-The query is rewritten into something like this :
-</p>
-
-<pre>
-SELECT P1-table.col, L1-table.col FROM
-	dblink(select pool_parallel(SELECT P1-table.col, L1-table.col FROM P1-table,L1-table where P1-table.col = L1-table.col)) 
-  	order by P1-table.col;
-</pre>
-<p>
-dblink transmits the query to pgpool-II here.
-the pool_parallel function is responsible for sending the query to the
-parallel execution engine.
-</p>
-<p>In this example, the FROM and WHERE clause, and the TARGETLIST are run in
-parallel mode. This isn't the real rewritten query, just something for the sake
-of providing an example.
-</p>
-<p>
-Here is another case:
-</p>
-
-<pre>
-SELECT L1-table.col FROM L1-table WHERE L1-table.col % 2 = 0 AND L1-table.col IN (SELECT P1-table FROM P1-table) ;
-</pre>
-
-<p>
-In this example, the FROM and WHERE clause and the TARGETLIST are in the L 
-status. Because the subquery is in the P status, the query itself is in the S status.
-The rewriting is, as a consequence, performed as follows.
-</p>
-<pre>
-	SELECT L1-table.col 
-	  FROM dblink(SELECT loadbalance(SELECT L1-table.col 
-	              FROM L1-table 
-	              WHERE L1-table.col % 2 = 0 
-	                AND TRUE))
-		WHERE
-			L1-table.col %2 = 0 AND 
-		  L1-table.col IN 
-		  (
-		  	SELECT P1-Table FROM 
-		  	dblink(select pool_parallel(SELECT P1-table FROM P1-table))
-		  ) ;
-</pre>
-<p>
-pool_loadbalance is a function responsible for dispatching queries to either node. 
-</p>
-
-<h3>Query rewriting for aggregate functions</h3>
-<p>
-For grouping queries (aggregate functions and GROUP BY), rewriting tries to 
-reduce the load on the system DB by performing a first aggregate on each node.
-</p>
-<p>
-First, let's see what pgpool-II does for rewriting.
-</p>
-<p>
-This query has the P status in the FROM clause and count(*) in TARGETLIST.
-So the rewriting is done as follows.
-</p>
-<pre>
-  select count(*) from P1-table;
-
-	-> rewrite
-
-    SELECT
-        sum(pool_c$1) as count
-    FROM
-        dblink(select pool_parallel('select count(*) from  P1-table'))
-					AS pool_$1g (pool_c$1 bigint);
-</pre>
-<p>
-Query rewriting like above is done in these conditions.
-</p>
-<ol>
-		<li>The FROM clause is in the P status. 
-		<li>The column specified in the aggregate function (only count, sum, min,
-		    max, and avg) and GROUP BY is used in the target list. 
-		<li>The WHERE clause is in the P status. 
-		<li>Only the columns defined by the aggregate function (only count, sum,
-				min, max, and avg), used in the HAVING clause and the FROM clause, and 
-				the column specified for GROUP BY are used. 
-</ol>
-<h3>Notes on the parallel mode</h3>
-<p>
-The column names and types are needed when a query is analyzed in parallel mode.
-Therefore, when an expression or a function is used in the TARGETLIST of
-a subquery, the alias and type (through a cast) are needed. Please note that
-if no cast is provided in an expression or a function, the text type will be
-chosen as a default. For count(), bigint type is assumed, and for sum(),
-numeric. For min()/max(), if the argument is a date type, returned datatype is date,
-else, it is assumed numeric. avg() is processed as sum()/count() (sum divided by count).
-
-<h3>About the performance of a parallel mode</h3>
-<p>Here is a rough estimate of the query performance versus execution status:
-</p>
-<p>
-<table border>
-		<tr><td>Execution status</td><td>Performance</td></tr>
-<tr><td align = center>L</td><td>There is no performance deterioration with a
-single node, excluding the overhead of pgpool-II, because there is no parallel
-querying done at all.</td></tr>
-<tr><td align = center>P</td><td>Parallel processing is fast, especially the
-sequential scans. It's easy to get speedups because the scan of a big table
-becomes the parallel scan of much smaller ones by being distributed on several
-nodes.
-<tr><td align = center>S</td><td>When aggregate functions can be rewritten in a
-parallel fashion, they are fast.</td></tr>
-</td></tr>
-</table>
-</p>
-
-<h1>Tutorial</h1>
-<p>
-<a href="tutorial-en.html">A tutorial for pgpool-II</a> is available.
-</p>
-
-<div class="copyright">
-<hr>
-<copyright>
-Copyright &copy; 2003 &ndash; 2011 pgpool Global Development Group
-</copyright>
-</div>
-</body>
-</html>
diff --git a/doc/pgpool-en.html b/doc/pgpool-en.html
deleted file mode 100644
index a5cdc8beb..000000000
--- a/doc/pgpool-en.html
+++ /dev/null
@@ -1,6195 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<html>
-<head>
-<meta http-equiv="content-type" content="text/html">
-<link rel="stylesheet" href="./pgpool.css" type="text/css">
-<title>pgpool-II user manual</title>
-</head>
-
-<!-- hhmts start -->
-Last modified: Mon Aug 24 18:19:17 JST 2015
-<!-- hhmts end -->
-
-<body bgcolor="#ffffff">
-<div id="top" class="header_text">Welcome to pgpool -II page</div>
-
-<div id="menu">
-    <div id="navcontainer">
-      <ul id="navlist">
-        <li id="active"><a href="#Whatis" id="current">What is pgpool</a></li>
-        <li><a href="#license">License</a></li>
-        <li><a href="#platform">Supported Platforms</a></li>
-        <li><a href="#install">pgpool-II Installation</a></li>
-        <li><a href="#config">Configuring pgpool-II</a></li>
-        <li><a href="#common">Configuring common part</a></li>
-        <li><a href="#connection_pool_mode">Connection pool mode</a></li>
-        <li><a href="#replication_mode">Replication mode</a></li>
-        <li><a href="#master_slave_mode">Master slave mode</a></li>
-        <li><a href="#stream">Streaming Replication</a></li>
-        <li><a href="#hba">Client authentication</a></li>
-        <li><a href="#query_cache">Setting Query cache method</a></li>
-        <li><a href="#memqcache">In memory query Cache</a></li>
-        <li><a href="#start">Starting/Stopping pgpool-II</a></li>
-        <li><a href="#reload">Reloading pgpool-II configuration files</a></li>
-		<li><a href="#pgpool-show-commands">PGPOOL SHOW commands</a></li>
-        <li><a href="#show-commands">SHOW commands</a></li>
-        <li><a href="#online-recovery">Online recovery</a></li>
-        <li><a href="#backup">Backup</a></li>
-        <li><a href="#deploy">Deploying pgpool-II</a></li>
-        <li><a href="#watchdog">Watchdog</a></li>
-        <li><a href="#pcp_command">PCP commands</a></li>
-        <li><a href="#pgpool_adm">pgpool_adm</a></li>
-        <li><a href="#troubleshooting">Troubleshooting</a></li>
-        <li><a href="#restriction">Restrictions</a></li>
-      </ul>
-    </div>
-    <br />
-
-    <div class="header_small" align="center">
-    [<a href="pgpool-ja.html">Japanese page</a>]
-    [<a href="pgpool-zh_cn.html">Chinese page</a>]
-    </div>
-</div>
-
-
-<div id="manual">
-
-<!-- ================================================================================ -->
-
-<h1 style="margin-top: 20px">What is pgpool-II?<a name="whatis"></a></h1>
-
-<p> pgpool-II is a middle ware that sits between PostgreSQL servers
-and a PostgreSQL database client. It provides the following features:</p>
-
-<p>
-<ul>
-
-<li>Connection Pooling</li>
-    <p>pgpool-II maintains established connections to the PostgreSQL servers, and
-    reuses them whenever a new connection with the same properties
-    (i.e. user name, database, protocol version) comes in. It reduces the
-    connection overhead, and improves system's overall throughput.</p>
-
-<li>Replication</li>
-    <p>pgpool-II can manage multiple PostgreSQL servers. Activating the
-    replication feature makes it possible to create a real time backup on 2 or
-    more PostgreSQL clusters, so that the service can continue without interruption
-    if one of those clusters fails.</p>
-
-<li>Load Balance</li>
-    <p>If a database is replicated(because running in either replication mode or master/slave mode),
-    performing a SELECT query on any
-    server will return the same result. pgpool-II takes advantage of
-    the replication feature in order to reduce the load on each PostgreSQL server.
-    It does that by distributing SELECT queries among available servers, improving
-    the system's overall throughput. In an ideal scenario, read performance could
-    improve proportionally to the number of PostgreSQL servers. Load balancing works
-    best in a scenario where there are a lot of users executing many read-only
-    queries at the same time.</p>
-
-<li>Limiting Exceeding Connections</li>
-    <p>There is a limit on the maximum number of concurrent
-    connections with PostgreSQL, and new connections are rejected when this
-    number is reached. Raising this maximum number of connections, however,
-    increases resource consumption and has a negative impact on overall system
-    performance. pgpool-II also has a limit on the maximum number of
-    connections, but extra connections will be queued instead of returning
-    an error immediately.</p>
-
-</ul>
-</p>
-
-<p>pgpool-II speaks PostgreSQL's backend and frontend protocol, and
-relays messages between a backend and a frontend. Therefore, a database application
-(frontend) thinks that pgpool-II is the actual PostgreSQL server, and
-the server (backend) sees pgpool-II as one of its clients. Because
-pgpool-II is transparent to both the server and the client, an
-existing database application can be used with pgpool-II almost
-without a change to its source code.</p>
-
-<p>
-<strong>There are some restrictions to using SQL via pgpool-II.
-See <a href="#restriction">Restrictions</a> for more details.</strong>
-</p>
-
-<p class="top_link"><a href="#Top">back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1>License<a name="license"></a></h1>
-
-<p>Copyright (c) 2003-2015        PgPool Global Development Group</p>
-<p><br></p>
-<p>
-Permission to use, copy, modify, and distribute this software and
-its documentation for any purpose and without fee is hereby
-granted, provided that the above copyright notice appear in all
-copies and that both that copyright notice and this permission
-notice appear in supporting documentation, and that the name of the
-author not be used in advertising or publicity pertaining to
-distribution of the software without specific, written prior
-permission. The author makes no representations about the
-suitability of this software for any purpose.  It is provided "as
-is" without express or implied warranty.
-</p>
-
-<p class="top_link"><a href="#Top">back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1>Supported Platforms<a name="platform"></a></h1>
-
-<p>pgpool-II works on Linux, Solaris, FreeBSD, and most of the
-UNIX-like architectures. Windows is not supported. Supported
-PostgreSQL server's versions are 6.4 and higher. </p>
-
-<p>If you are using PostgreSQL 7.3 or older, some features of pgpool-II
-won't be available. But you shouldn't use such an old release anyway.</p>
-
-<p>You must also make sure that all of your PostgreSQL servers are using the same
-major PostgreSQL version.
-In addition to this, we do not recommend mixing different PostgreSQL installation with different build options: including supporting SSL or not, to use --disable-integer-datetimes or not, different block size.
-These might affect part of functionality of pgpool-II.
-The difference of PostgreSQL minor versions is not usually a problem. However we do not test every occurrence of minor versions and we recommend to use exact same minor version of PostgreSQL.
-</p>
-
-<p class="top_link"><a href="#Top">back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1>pgpool-II Installation<a name="install"></a></h1>
-
-<p>
-pgpool-II can be downloaded from the <a href="http://pgpool.net/">pgpool Development page</a>.
-Packages are also provided for various platforms including CentOS, RedHat Enterprise Linux, Fedora and Debian.
-Check appropriate repository.
-</p>
-
-<p>
-pgpool-II's source code can be downloaded from:
-<a href="http://pgpool.net/mediawiki/index.php/Downloads">pgpool development page</a>
-</p>
-
-<p>Installing pgpool-II from source code requires gcc 2.9 or higher, and GNU
-make. Also, pgpool-II links with the libpq library, so the libpq library and its development
-headers must be installed on the machine used to build pgpool-II.  Additionally
-the OpenSSL library and its development headers must be present in order to
-enable OpenSSL support in pgpool-II.</p>
-
-
-<h2 id="install_pgpool">Installing pgpool-II</h2>
-<dl>
-<dt>configure</dt>
-    <dd>
-    <p>After extracting the source tarball, execute the configure script.</p>
-<pre>
-./configure
-</pre>
-
-    <p>If you want non-default values, some options can be set:</p>
-    <table border>
-      <tr><th class="nodec"><code>--prefix=path</code></th>
-      <td>pgpool-II binaries and docs will be installed in this
-          directory. Default value is <code>/usr/local</code></td></tr>
-      <tr><th class="nodec"><code>--with-pgsql=path</code></th>
-      <td>The top directory where PostgreSQL's client libraries are
-          installed. Default value is provided by <code>pg_config</code></td></tr>
-      <tr><th class="nodec"><code>--with-openssl</code></th>
-      <td>pgpool-II binaries will be built with OpenSSL support.  OpenSSL support
-          is disabled by default. <span class="version">V2.3 -</span></td></tr>
-      <tr><th class="nodec"><code>--enable-sequence-lock</code></th>
-      <td>Use insert_lock compatible with pgpool-II 3.0 series(until 3.0.4).
-          pgpool-II locks against a row in the sequence table.
-          PostgreSQL 8.2 or later which was released after June 2011 cannot use this lock method.
-          <span class="version">V3.1 -</span></td></tr>
-      <tr><th class="nodec"><code>--enable-table-lock</code></th>
-      <td>Use insert_lock compatible with pgpool-II 2.2 and 2.3 series.
-          pgpool-II locks against the insert target table.
-          This lock method is deprecated because it causes a lock conflict with VACUUM.
-          <span class="version">V3.1 -</span></td></tr>
-      <tr><th class="nodec"><code>--with-memcached=path</code></th>
-      <td>pgpool-II binaries will use <a href="#memcached_params">memcached</a>
-          for <a href="#memqcache">in memory query cache</a>.
-          You have to install <a href="http://libmemcached.org/libMemcached.html">libmemcached</a>.
-          <span class="version">V3.2 -</span></td>
-      </tr>
-      </table>
-    </dd>
-
-<dt>make</dt>
-    <dd>
-<pre>
-make
-make install
-</pre>
-    <p>
-    will install pgpool-II. (If you use Solaris or FreeBSD, replace make with gmake)
-    </p>
-    </dd>
-</dl>
-
-<h2 id="install_functions">Installing functions</h2>
-
-<h3>Installing pgpool_regclass (optional) <span class="version">V3.0 - </span></h3>
-<p>
-If you are using PostgreSQL 8.0 to PostgreSQL 9.3, installing pgpool_regclass function on all PostgreSQL
-to be accessed by pgpool-II is strongly recommended, as it is used internally by pgpool-II.
-Without this, handling of duplicate table names in different schema
-might cause trouble (temporary tables aren't a problem).
-If you are using PostgreSQL 9.4 or later, installing pgpool_regclass
-is not necessary since an equivalent (to_regclass) is included in the PostgreSQL core.
-</p>
-
-<pre>
-$ cd pgpool-II-x.x.x/sql/pgpool-regclass
-$ make
-$ make install
-</pre>
-
-<p>After this:<p>
-<pre>
-$ psql -f pgpool-regclass.sql template1
-</pre>
-
-<p>or<p>
-
-<pre>
-$ psql template1
-=# CREATE EXTENSION pgpool_regclass;
-</pre>
-</p>
-<p>
-Executing pgpool-regclass.sql or <code>CREATE EXTENSION</code> should be performed on every databases accessed
-with pgpool-II.
-You do not need to do this for a database created after the
-execution of "<code>psql -f pgpool-regclass.sql template1</code>" or <code>CREATE EXTENSION</code>,
-as this template database will be cloned to create new databases.
-</p>
-
-<h3>Creating insert_lock table <span class="version">V3.0 -</span></h3>
-<p>
-If you use insert_lock in replication mode, creating pgpool_catalog.insert_lock
-table for mutual exclusion is strongly recommended.
-Without this, insert_lock works so far. However in that case pgpool-II locks
-against the insert target table. This behavior is same as pgpool-II 2.2 and 2.3
-series. The table lock conflicts with VACUUM. So INSERT processing may be thereby
-kept waiting for a long time.
-</p>
-
-<pre>
-$ cd pgpool-II-x.x.x/sql
-$ psql -f insert_lock.sql template1
-</pre>
-
-<p>
-Executing insert_lock.sql should be performed on every databases accessed
-with pgpool-II.
-You do not need to do this for a database created after the execution of
-"<code>psql -f insert_lock.sql template1</code>", as this template database will be
-cloned to create new databases.
-</p>
-
-<h3>Installing pgpool_recovery</h3>
-
-<p>If you use <a href="#online_recovery_in_stream_mode">online recovery</a>, some functions are needed:
-pgpool_recovery, pgpool_remote_start, pgpool_switch_xlog.</p>
-<p>And, pgpoolAdmin of the tool to control pgpool-II can stop, restart and reload the backend PostgreSQL nodes,
-and it needs the function named pgpool_pgctl.</p>
-<p>
-Also pgpoolAdmin needs function pgpool_pgctl to stop/restart/reload config PostgreSQL.
-</p>
-<p>
-You can install those 4 functions in a same manner as pgpool_regclass.
-However, unlike pgpool_regclass, you only need to install those functions to template1 database.
-</p>
-
-<p>Here is the way to install those functions.</p>
-<p>
-<pre>
-$ cd pgpool-II-x.x.x/sql/pgpool-recovery
-$ make
-$ make install
-</pre>
-
-<p>After this:<p>
-<pre>
-$ psql -f pgpool-recovery.sql template1
-</pre>
-
-<p>or<p>
-
-<pre>
-$ psql template1
-=# CREATE EXTENSION pgpool_recovery;
-</pre>
-</p>
-
-<h4>Configuring pgpool.pg_ctl <span class="version">V3.3 -</span></h4>
-
-<p>The function pgpool_pgctl executes the command whose path is specified by "pgpool.pg_ctl" in postgresql.conf.
-To use this function, you have to specify this parameter.</p>
-<pre>
-ex)
-$ cat &gt;&gt; /usr/local/pgsql/postgresql.conf
-pgpool.pg_ctl = '/usr/local/pgsql/bin/pg_ctl'
-
-$ pg_ctl reload -D /usr/local/pgsql/data
-</pre>
-
-<p class="top_link"><a href="#Top">back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1>Configuring pgpool-II<a name="config"></a></h1>
-
-<p>Default configuration files for pgpool-II are
-<code>/usr/local/etc/pgpool.conf</code> and
-<code>/usr/local/etc/pcp.conf</code>. Several operation modes are available
-in pgpool-II. Each mode has associated features which
-can be enabled or disabled, and specific configuration parameters to
-control their behaviors.</p>
-
-<table border>
-
-  <tr class="header">
-    <th>Function/Mode</th>
-    <th>Raw Mode (*2)</th>
-    <th>Replication Mode</th>
-    <th>Master/Slave Mode</th>
-  </tr>
-
-  <tr>
-    <th>Connection Pool</th>
-    <td align="center">O</td>
-    <td align="center">O</td>
-    <td align="center">O</td>
-  </tr>
-
-  <tr>
-    <th>Replication</th>
-    <td align="center">X</td>
-    <td align="center">O</td>
-    <td align="center">X</td>
-  </tr>
-
-  <tr>
-    <th>Load Balance</th>
-    <td align="center">X</td>
-    <td align="center">O</td>
-    <td align="center">O</td>
-  </tr>
-
-  <tr>
-    <th>Failover</th>
-    <td align="center">O</td>
-    <td align="center">O</td>
-    <td align="center">O</td>
-  </tr>
-
-  <tr>
-    <th>Online recovery</th>
-    <td align="center">X</td>
-    <td align="center">0</td>
-    <td align="center">(*1)</td>
-  </tr>
-
-  <tr>
-    <th>Required # of Servers</th>
-    <td align="center">1 or higher</td>
-    <td align="center">2 or higher</td>
-    <td align="center">2 or higher</td>
-  </tr>
-
-</table>
-
-<ul>
-    <li> O means 'available', X means 'unavailable'</li>
-    <li>(*1) Online recovery can be used with Master slave+Streaming replication.</li>
-    <li>(*2) Clients simply connect to the PostgreSQL servers
-        via pgpool-II. This mode is useful for simply limiting excess
-        connections to the servers, or enabling failover with multiple servers.
-    </li>
-    </ul>
-
-<h2 id="pcp_conf">Configuring <code>pcp.conf</code></h2>
-
-<p>pgpool-II provides a control interface where an administrator
-can collect pgpool-II status, and terminate pgpool-II processes remotely.
-<code>pcp.conf</code> is the user/password file used for
-authentication by this interface. All operation modes require the
-<code>pcp.conf</code> file to be set. A <code>$prefix/etc/pcp.conf.sample</code>
-file is created during the installation of pgpool-II. Rename the file to
-<code>pcp.conf</code> and add your user name and password to it.
-</p>
-
-<pre>
-cp $prefix/etc/pcp.conf.sample $prefix/etc/pcp.conf
-</pre>
-<p>
-An empty line or a line starting with "<code>#</code>" is treated as a
-comment and will be ignored. A user name and its associated password must be
-written as one line using the following format:
-</p>
-<pre>
-username:[password encrypted in md5]
-</pre>
-<p>
-<code>[password encrypted in md5]</code> can be produced with the
-<code>$prefix/bin/pg_md5</code> command.
-</p>
-
-<pre>
-pg_md5 -p
-password: &lt;your password&gt;
-</pre>
-<p>
-or
-</p>
-<pre>
-./pg_md5 foo
-acbd18db4cc2f85cedef654fccc4a4d8
-</pre>
-<p>
-The <code>pcp.conf</code> file must be readable by the user who
-executes pgpool-II.</p>
-
-<h2 id="pgpool_conf">Configuring <code>pgpool.conf</code></h2>
-
-<p>As already explained, each operation mode has its specific
-configuration parameters in <code>pgpool.conf</code>. A
-<code>$prefix/etc/pgpool.conf.sample</code> file is created during the
-installation of pgpool-II. Rename the file to
-<code>pgpool.conf</code> and edit its contents.
-
-<pre>
-cp $prefix/etc/pgpool.conf.sample $prefix/etc/pgpool.conf
-</pre>
-
-<p>
-There are additional sample pgpool.conf for each mode.  <span class="version">V2.3 -</span>
-</p>
-
-<table border>
-<tr class="header">
-<th>Mode</th>
-<th>sample file</th>
-</tr>
-
-<tr>
-<td>replication mode</td>
-<td>pgpool.conf.sample-replication</td>
-</tr>
-
-<tr>
-<td>master/slave mode(Slony-I)</td>
-<td>pgpool.conf.sample-master-slave</td>
-</tr>
-
-<tr>
-<td>master/slave mode(Streaming replication)</td>
-<td>pgpool.conf.sample-stream</td>
-</tr>
-</table>
-
-<p>
-An empty line or a line starting with "#" is treated as a
-comment and will be ignored.</p>
-</p>
-
-<h3>Connections</h3>
-
-<dl>
-<dt><a name="LISTEN_ADDRESS"></a>listen_addresses</dt>
-    <dd>
-    <p>Specifies the hostname or IP address, on which pgpool-II will accept
-    TCP/IP connections. <code>'*'</code> accepts
-    all incoming connections. <code>''</code> disables TCP/IP
-    connections. Default is <code>'localhost'</code>. Connections via UNIX
-    domain socket are always accepted.
-    </p>
-    <p>
-    This parameter can only be set at server start.</p>
-    </dd>
-
-<dt><a name="PORT"></a>port</dt>
-    <dd>
-     <p>The port number used by pgpool-II to listen for connections. Default is 9999.
-    </p>
-    <p>
-     This parameter can only be set at server start.</p>
-    </dd>
-
-<dt><a name="SOCKET_DIR"></a>socket_dir</dt>
-    <dd>
-    <p>The directory where the UNIX domain socket accepting connections for
-    pgpool-II will be created. Default is <code>'/tmp'</code>. Be
-    aware that this socket might be deleted by a cron job. We recommend to
-    set this value to <code>'/var/run'</code> or such directory.
-    </p>
-    <p>
-    This parameter can only be set at server start.</p>
-    </dd>
-
-<dt><a name="PCP_LISTEN_ADDRESS"></a>pcp_listen_addresses</dt>
-    <dd>
-    <p>Specifies the hostname or IP address, on which pcp process will accept
-    TCP/IP connections. <code>'*'</code> accepts
-    all incoming connections. <code>''</code> disables TCP/IP
-    connections. Default is <code>'*'</code>. Connections via UNIX
-    domain socket are always accepted.
-    </p>
-    <p>
-    This parameter can only be set at server start.</p>
-    </dd>
-
-<dt><a name="PCP_PORT"></a>pcp_port</dt>
-    <dd>
-    <p>The port number where PCP process accepts connections. Default is 9898.
-    </p>
-    <p>
-    This parameter can only be set at server start.</p>
-    </dd>
-
-  <dt><a name="PCP_SOCKET_DIR"></a>pcp_socket_dir</dt>
-    <dd>
-    <p>The directory path of the UNIX domain socket accepting
-    connections for the PCP process. Default is <code>'/tmp'</code>.
-    Be aware that the socket might be deleted by cron.
-    We recommend to set this value to <code>'/var/run'</code> or such directory.
-    </p>
-    <p>
-    This parameter can only be set at server start.</p>
-    </dd>
-
-<h3>Pools</h3>
-
-<dl>
-<dt><a name="NUM_INIT_CHILDREN"></a>num_init_children</dt>
-    <dd>
-    <p>The number of preforked pgpool-II server processes. Default is 32.
-    num_init_children is also the concurrent connections limit to pgpool-II from clients.
-    If more than num_init_children clients try to connect to pgpool-II,
-    they are blocked (not rejected) until a connection to any pgpool-II process is closed.
-    Up to listen_backlog_multiplier*num_init_children can be queued.
-		</p>
-		<p>
-		The queued is inside the kernel called "listen queue". The length of the listen queue is called "backlog".
-		There is an upper limit of the backlog in some systems, and if num_init_children*listen_backlog_multiplier exceeds the number, you need to set the backlong higher. Otherwise, following problems may occur in heavy loaded systems: 1) connecting to pgpool-II fails 2) connecting to pgpool-II is getting slow because of retries in the kernel.
-		You can check if the listen queue is actually overflowed by using "netstat -s" command.
-		If you find something like:
-		</p>
-		<pre>
-535 times the listen queue of a socket overflowed
-		</pre>
-		</p>
-		<p>
-then the listen queue is definitely overflowed.
-		You should increase the backlog in this case (you will be required a super user privilege).
-		</p>
-		<p>
-		<pre>
-# sysctl net.core.somaxconn
-net.core.somaxconn = 128
-# sysctl -w net.core.somaxconn = 256
-		</pre>
-		</p>
-		<p>
-You could add following to /etc/sysctl.conf instead.
-		</p>
-		<p>
-		<pre>
-net.core.somaxconn = 256
-		</pre>
-    </p>
-		<p>
-    Number of connections to each PostgreSQL is roughly max_pool*num_init_children</p>
-
-    <p>Some hints in addition to above:</p>
-    <ul>
-        <li>Canceling a query creates another
-            connection to the backend; thus, a query cannot be canceled if
-            all the connections are in use. If you want to ensure that queries can
-            be canceled, set this value to twice the expected connections.</li>
-
-        <li>PostgreSQL allows concurrent connections for non superusers up
-            to max_connections - superuser_reserved_connections.</li>
-    </ul>
-
-    <p>In summary, max_pool, num_init_children, max_connections,
-    superuser_reserved_connections must satisfy the following formula:
-    </p>
-<pre>
-max_pool*num_init_children &lt;= (max_connections - superuser_reserved_connections) (no query canceling needed)
-max_pool*num_init_children*2 &lt;= (max_connections - superuser_reserved_connections) (query canceling needed)
-</pre>
-
-    <p>
-    This parameter can only be set at server start.</p>
-    </dd>
-
-<dt><a name="LISTEN_BACKLOG_MULTIPLIERE"></a>listen_backlog_multiplier <span class="version">V3.4 -</span></dt>
-    <dd>
-		<p>
-		Controls the length of connection queue from frontend to pgpool-II.	The default is 2.
-		The queue length (actually "backlog" parameter of listen system call) is defined as listen_backlog_multiplier * num_init_children.
-		If the queue length is not long enough, you should increase the parameter.
-		Some systems have upper limit of the backlog parameter of listen system call.
-		See <a href="#NUM_INIT_CHILDREN">num_init_children</a> for more details.
-		</p>
-		<p>
-		This parameter can only be set at server start.</p>
-	</dd>
-
-<dt><a name="SERIALIZE_ACCEPT"></a>serialize_accept <span class="version">V3.5 -</span></dt>
-    <dd>
-		<p>
-		  Whether to serialize accept() call for incoming client connections.
-		  Default is off, which means no serializing (same behavior as pgpool-II 3.4 or before).
-		  If this is off, the kernel wakes up all of pgpool-II child process to execute accept() and one of them actually accepts the incoming connection.
-		  Problem here is, because so my child process wake up at a same time, heavy context switching occurred and
-		  the performance is affected.
-		  This phenomena is a classic problem called "the thundering herd problem".
-		  By enabling serialize_accept, only one of pgpool-II child process is woken up and executes accept() and the problem can be avoided.
-		  When you should turn on serialize_accept?
-		  For large number of num_init_children, it is recommended to turn on serialize_accept.
-		  For small number of num_init_children, it may not enhance the performance rather, it may degrade the performance because of serializing overhead.
-		  How large is actually large is depending on the environment.
-		  It is recommended to do a bench mark test to make the decision.
-		  Here is a example pgbench run:
-		</p>
-		<p>
-		  <pre>
-		    pgbench -n -S -p 9999 -c 32 -C -S -T 300 test
-		  </pre>
-		</p>
-		<p>
-		  Here, -C tells pgbench to connect to database each time a transaction gets executed.
-		  -c 32 specifies the concurrent sessions to pgpool-II. You should change this according to your system's requirement.
-		  When pgbench finishes, you want to check the number from "including connections establishing".
-		</p>
-		<p>
-		  Please note that if <a href="#CHILD_LIFE_TIME">child_life_time</a> is enabled, serialize_accept has no effect.
-		  Make sure that you set child_life_time to 0 if you want to turn on serialize_accept.
-		  If you are care about pgpool-II process memory leak or whatever potential issue, you could use <a href="#CHILD_MAX_CONNECTIONS">child_max_connections</a> instead.
-		  This is purely an implementation limitation and maybe removed in the future.
-		</p>
-		<p>
-		This parameter can only be set at server start.</p>
-    </dd>
-		
-<dt><a name="CHILD_LIFE_TIME"></a>child_life_time</dt>
-    <dd>
-    <p>A pgpool-II child process' life time in seconds.
-    When a child is idle for that many seconds, it is terminated and a new child is created.
-    This parameter is a measure to prevent memory leaks and other unexpected errors.
-    Default value is 300 (5 minutes).
-    0 disables this feature. Note that this doesn't apply for processes
-    that have not accepted any connection yet.
-    </p>
-    <p>
-      Note: if this parameter is non 0, <a href="#SERIALIZE_ACCEPT">serialize_accept</a> has no effect.
-    </p>
-    <p>
-    You need to reload pgpool.conf if you change this value.
-    </p>
-    </dd>
-
-<dt><a name="CHILD_MAX_CONNECTIONS"></a>child_max_connections</dt>
-    <dd>
-    <p>A pgpool-II child process will be terminated after this many connections from clients.
-    This parameter is useful on a server
-    if it is so busy that <a href=#CHILD_LIFE_TIME">child_life_time</a> and
-    <a href="#CONNECTION_LIFE_TIME">connection_life_time</a> are never triggered.
-    Thus this is also useful to prevent PostgreSQL servers from getting too big.
-    </p>
-    <p>
-    You need to reload pgpool.conf if you change this value.
-    </p>
-    </dd>
-
-<dt><a name="CLIENT_IDLE_LIMIT"></a>client_idle_limit</dt>
-    <dd>
-    <p> Disconnect a client if it has been idle for client_idle_limit seconds
-    after the last query has completed.
-    This is useful to prevent pgpool childs from being
-    occupied by a lazy client or a broken TCP/IP connection between client and pgpool.
-    The default value for client_idle_limit is 0, which means
-    the feature is turned off. this value.
-    This parameter is ignored in the second stage of online recovery.
-    </p>
-	<p>
-	You need to reload pgpool.conf if you change this value. And you can also use PGPOOL SET command
-	to alter the value of this parameter for a current session.
-	</p>
-    </dd>
-
-<dt><a name="ENABLE_POOL_HBA"></a>enable_pool_hba</dt>
-    <dd>
-    <p>
-    If true, use pool_hba.conf for client authentication.
-    See <a href="#hba">setting up pool_hba.conf for client authentication</a>.
-    </p>
-    <p>
-    You need to reload pgpool.conf if you change this value.
-    </p>
-    </dd>
-
-<dt><a name="POOL_PASSWD"></a>pool_passwd</dt>
-    <dd>
-    <p>
-    Specify the file name of pool_passwd for md5 authentication.
-    Default value is "pool_passwd". "" disables to read pool_passwd.
-    See <a href="#md5">Authentication / Access Controls</a> for more details.
-    </p>
-    <p>
-    You need to restart pgpool-II if you change this value.
-    </p>
-    </dd>
-
-<dt><a name="AUTHENTICATION_TIMEOUT"></a>authentication_timeout</dt>
-    <dd>
-    <p>Specify the timeout for pgpool authentication. 0 disables the time out.
-    Default value is 60.
-    </p>
-    <p>
-    You need to reload pgpool.conf if you change this value.
-    </dd>
-</dl>
-
-<h3>Logs</h3>
-
-<dl>
-<dt><a name="LOG_DESTINATION"></a>log_destination <span class="version">V3.1 -</span></dt>
-    <dd>
-    <p>PgPool II supports several methods for logging server messages,
-    including stderr and syslog. The default is to log to stderr.
-    </p>
-    <p>Note: you will need to alter the configuration of your system's syslog daemon
-    in order to make use of the syslog option for log_destination.
-    PgPool can log to syslog facilities LOCAL0 through LOCAL7 (see syslog_facility),
-    but the default syslog configuration on most platforms will discard all such messages.
-    You will need to add something like
-    </p>
-<pre>
-local0.*    /var/log/pgpool.log
-</pre>
-      <p>to the syslog daemon's configuration file to make it work.</p>
-    </dd>
-
-<dt><a name="PRINT_TIMESTAMP"></a>print_timestamp <span class="version">- V3.4 (REMOVED)</span></dt>
-    <dd>
-    <p>Add timestamps to the logs when set to true. Default is true.
-    </p>
-    <p>
-    You need to reload pgpool.conf if you change print_timestamp.
-    </p>
-    </dd>
-
-<dt><a name="PRINT_USER"></a>print_user <span class="version">- V3.4 (REMOVED)</span></dt>
-    <dd>
-    <p>Add session user names to the logs when set to true. Default is false.
-    </p>
-    <p>
-    You need to reload pgpool.conf if you change print_user.
-    </p>
-    </dd>
-
-	<dt><a name="LOG_LINE_PREFIX"></a>log_line_prefix</dt>
-	<dd>
-	<p>
-	This is a printf-style string that is output at the beginning of each log line.
-	% characters begin "escape sequences" that are replaced with information outlined below.
-	All unrecognized escapes are ignored. Other characters are copied straight to the log line.
-
-	Default is '%t: pid %p: ', which prints timestamp and process
-	id, which keeps backward compatibily with pre-3.4.
-	</p>
-	<table border>
-	<tr class="header"><th>Escape</th><th>Effect</th></tr>
-	<tr><td>%a</td><td>Client application name.</td></tr>
-	<tr><td>%p</td><td>Process ID (PID).</td></tr>
-	<tr><td>%P</td><td>Process name.</td></tr>
-	<tr><td>%t</td><td>Time stamp.</td></tr>
-	<tr><td>%d</td><td>Database name.</td></tr>
-	<tr><td>%u</td><td>User name.</td></tr>
-	<tr><td>%l</td><td>Log line number for each process.</td></tr>
-	<tr><td>%%</td><td>'%' character</td></tr>
-	</table>
-	<p>
-	You need to reload pgpool.conf if you change log_line_prefix
-	</p>
-	</dd>
-
-<dt><a name="LOG_ERROR_VERBOSITY"></a>log_error_verbosity</dt>
-    <dd>
-    <p>
-    Controls the amount of detail emitted for each message that is logged.
-    Valid values are TERSE, DEFAULT, and VERBOSE, each adding more fields to displayed messages.
-    TERSE excludes the logging of DETAIL, HINT, and CONTEXT error information.
-    </p>
-	<p>
-	You need to reload pgpool.conf if you change this value. And you can also use PGPOOL SET command
-	to alter the value of this parameter for a current session.
-	</p>
-    </dd>
-
-<dt><a name="LOG_CONNECTIONS"></a>log_connections</dt>
-    <dd>
-    <p>
-    If true, all incoming connections will be printed to the log.
-    </p>
-    <p>
-    You need to reload pgpool.conf if you change this value.
-    </p>
-    </dd>
-
-<dt><a name="CLIENT_MIN_MESSAGES"></a>client_min_messages</dt>
-    <dd>
-    <p>
-    Controls which minimum message levels are sent to the client.
-    Valid values are DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, LOG, NOTICE,
-    WARNING and ERROR. Each level includes all the levels that follow it.
-    The default is NOTICE.
-    </p>
-	<p>
-	You need to reload pgpool.conf if you change this value. And you can also use PGPOOL SET command
-	to alter the value of this parameter for a current session.
-	</p>
-    </dd>
-
-<dt><a name="LOG_MIN_MESSAGES"></a>log_min_messages</dt>
-    <dd>
-    <p>
-    Controls which minimum message levels are emitted to log.
-    Valid values are DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, INFO, NOTICE,
-    WARNING, ERROR, LOG, FATAL, and PANIC. Each level includes all the
-    levels that follow it. The default is WARNING.    
-    </p>
-    <p>
-    You need to reload pgpool.conf if you change this value. And you can also use PGPOOL SET command
-	to alter the value of this parameter for a current session.
-	</p>
-    </dd>
-
-<dt><a name="LOG_HOSTNAME"></a>log_hostname</dt>
-    <dd>
-    <p>
-    If true, ps command status will show the client's hostname instead
-    of an IP address. Also, if <a href="#LOG_CONNECTIONS">log_connections</a> is enabled,
-    hostname will be logged.
-    </p>
-    <p>
-    You need to reload pgpool.conf if you change this value.
-    </p>
-    </dd>
-
-<dt><a name="LOG_STATEMENT"></a>log_statement</dt>
-    <dd>
-    <p>Produces SQL log messages when true. This is similar to the
-    log_statement parameter in PostgreSQL. It produces logs even if the
-    debug option was not passed to pgpool-II at start up.
-    </p>
-	<p>
-	You need to reload pgpool.conf if you change this value. And you can also use PGPOOL SET command
-	to alter the value of this parameter for a current session.
-	</p>
-    </dd>
-
-<dt><a name="LOG_PER_NODE_STATEMENT"></a>log_per_node_statement <span class="version">V2.3 -</span></dt>
-    <dd>
-    <p>Similar to <a href="#LOG_PER_NODE_STATEMENT">log_statement</a>,
-    except that it prints logs for each DB node separately.
-    It can be useful to make sure that replication is working, for example.
-    </p>
-	<p>
-	You need to reload pgpool.conf if you change this value. And you can also use PGPOOL SET command
-	to alter the value of this parameter for a current session.
-	</p>
-    </dd>
-
-<dt><a name="SYSLOG_FACILITY"></a>syslog_facility <span class="version">V3.1 -</span></dt>
-    <dd>
-    <p>When logging to syslog is enabled, this parameter determines the syslog "facility" to be used.
-    You can choose from LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7;
-    the default is LOCAL0. See also the documentation of your system's syslog daemon.
-    </p>
-    </dd>
-
-<dt><a name="SYSLOG_IDENT"></a>syslog_ident <span class="version">V3.1 -</span></dt>
-    <dd>
-    <p>When logging to syslog is enabled, this parameter determines the program name
-    used to identify PgPool messages in syslog logs. The default is pgpool.
-    </p>
-    </dd>
-
-<dt><a name="DEBUG_LEVEL"></a>debug_level <span class="version">V3.0 -</span></dt>
-    <dd>
-    <p>
-    Debug message verbosity level. 0 means no message, greater than 1
-    means more verbose message. Default value is 0.
-    </p>
-    </dd>
-</dl>
-
-<h3>File locations</h3>
-
-<dl>
-<dt><a name="PID_FILE_NAME"></a>pid_file_name</dt>
-    <dd>
-    <p>Full path to a file which contains pgpool's process id.
-    Default is "/var/run/pgpool/pgpool.pid".
-    </p>
-    <p>
-    You need to restart pgpool-II if you change this value.
-    </p>
-    </dd>
-
-<dt><a name="LOGDIR"></a>logdir</dt>
-    <dd>
-    <p>pgpool_status is written into this directory.</p>
-    </dd>
-</dl>
-
-<h3>Connection pooling</h3>
-
-<dl>
-<dt><a name="CONNECTION_CACHE"></a>connection_cache</dt>
-    <dd>
-    <p>Caches connections to backends when set to on. Default is true.
-      However, connections to template0, template1, postgres and
-      regression databases are not cached even if connection_cache is
-      on.
-    </p>
-    <p>
-    You need to restart pgpool-II if you change this value.</p>
-    </dd>
-</dl>
-
-<h3>Health check</h3>
-
-<dl>
-<dt><a name="HEALTH_CHECK_TIMEOUT"></a>health_check_timeout</dt>
-    <dd>
-    <p>pgpool-II periodically tries to connect to the backends
-    to detect any error on the servers or networks.
-    This error check procedure is called "health check".
-    If an error is detected, pgpool-II tries to perform failover or degeneration.
-    </p>
-    <p>
-    This parameter serves to prevent the health check from waiting for a long
-    time in a case such as unplugged network cable.
-    The timeout value is in seconds. Default value is 20.
-    0 disables timeout (waits until TCP/IP timeout).
-    </p>
-    <p>
-    This health check requires one extra connection to each backend,
-    so <code>max_connections</code> in the
-    <code>postgresql.conf</code> needs to be incremented as needed.
-    </p>
-    <p>
-    You need to reload pgpool.conf if you change this value.
-    </p>
-    </dd>
-
-<dt><a name="HEALTH_CHECK_PERIOD"></a>health_check_period</dt>
-    <dd>
-    <p>This parameter specifies the interval between the health
-    checks in seconds. Default is 0, which means health check is disabled.
-    </p>
-    <p>
-    You need to reload pgpool.conf if you change health_check_period.
-    </p>
-    </dd>
-
-<dt><a name="HEALTH_CHECK_USER"></a>health_check_user</dt>
-    <dd>
-    <p>The user name to perform health check.
-    This user must exist in all the PostgreSQL backends.
-    Otherwise, health check causes an error.
-    </p>
-    <p>
-    You need to reload pgpool.conf if you change health_check_user.
-    </p>
-    </dd>
-
-<dt><a name="HEALTH_CHECK_PASSWORD"></a>health_check_password <span class="version">V3.1 -</span></dt>
-    <dd>
-    <p>The password of the user to perform health check.
-    </p>
-    <p>
-    You need to reload pgpool.conf if you change health_check_password.
-    </p>
-    </dd>
-
-<dt><a name="HEALTH_CHECK_DATABASE"></a>health_check_database <span class="version">V3.5 -</span></dt>
-    <dd>
-    <p>The database name to perform health check.  The default is '',
-      which tries "postgres" database first, then "template1" database
-      until it succeeds. This is the same behavior as 3.4 or before.
-    </p>
-    <p>
-    You need to reload pgpool.conf if you change health_check_database.
-    </p>
-    </dd>
-
-<dt><a name="HEALTH_CHECK_MAX_RETRIES"></a>health_check_max_retries <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>The maximum number of times to retry a failed health check
-    before giving up and initiating failover.
-    This setting can be useful in spotty networks, when it is expected that health
-    checks will fail occasionally even when the master is fine.
-    Default is 0, which means do not retry.
-    It is advised that you disable <a href="#FAIL_OVER_ON_BACKEND_ERROR">fail_over_on_backend_error</a>
-    if you want to enable health_check_max_retries</dt>.
-    </p>
-    <p>
-    You need to reload pgpool.conf if you change health_check_max_retries.
-    </p>
-    </dd>
-
-<dt><a name="HEALTH_CHECK_RETRY_DELAY"></a>health_check_retry_delay <span class="version">V3.2 -</span></dt>
-    <dd>
-      <p>The amount of time (in seconds) to sleep between failed health check
-      retries (not used unless health_check_max_retries is &gt; 0).
-      If 0, then retries are immediate (no delay).
-    </p>
-    <p>
-      You need to reload pgpool.conf if you change health_check_retry_delay.
-      </p>
-    </dd>
-
-<dt><a name="CONNECT_TIMEOUT"></a>connect_timeout <span class="version">V3.4 -</span></dt>
-    <dd>
-	  <p>Timeout value in milliseconds before giving up connecting to
-		backend using connect() system call.  Default is 10000 ms (10
-		second). Flaky network user may want to increase the value. 0
-		means no timeout.  Note that this value is not only used for
-		health check, but also for creating ordinary conection pools.
-	  </p>
-    <p>
-      You need to reload pgpool.conf if you change connect_timeout.
-    </p>
-    </dd>
-
-<dt><a name="SEARCH_PRIMARY_NODE_TIMEOUT"></a>search_primary_node_timeout <span class="version">V3.3 -</span></dt>
-    <dd>
-    <p>The parameter specifies the maximum amount of time in seconds to search
-    for a primary node when a failover scenario occurs.
-    The default value for the parameter is 300.
-    pgpool-II will search for the primary node for the amount of time given in case of
-    failover before giving up trying to search for a primary node.
-    0 means keep trying forever.
-    This parameter will be ignored if running in other than streaming replication mode.
-    </p>
-    <p>
-    You need to reload pgpool.conf if you change search_primary_node_timeout.
-    </p>
-    </dd>
-
-</dl>
-
-<h3>Failover and failback</h3>
-
-<dl>
-<dt><a name="FAILOVER_COMMAND"></a>failover_command</dt>
-    <dd>
-    <p>
-    This parameter specifies a command to run when a node is detached.
-    pgpool-II replaces the following special characters with backend specific
-    information.
-    </p>
-
-    <table border>
-    <tr class="header"><th>Special character</th><th>Description</th></tr>
-    <tr><td>%d</td><td>Backend ID of a detached node.</td></tr>
-    <tr><td>%h</td><td>Hostname of a detached node.</td></tr>
-    <tr><td>%p</td><td>Port number of a detached node.</td></tr>
-    <tr><td>%D</td><td>Database cluster directory of a detached node.</td></tr>
-    <tr><td>%M</td><td>Old master node ID.</td></tr>
-    <tr><td>%m</td><td>New master node ID.</td></tr>
-    <tr><td>%H</td><td>Hostname of the new master node.</td></tr>
-    <tr><td>%P</td><td>Old primary node ID.</td></tr>
-    <tr><td>%r</td><td>New master port number.</td></tr>
-    <tr><td>%R</td><td>New master database cluster directory.</td></tr>
-    <tr><td>%%</td><td>'%' character</td></tr>
-    </table>
-
-    <p>
-    You need to reload pgpool.conf if you change failover_command.
-    </p>
-
-    <p>
-    When a failover is performed, pgpool kills all its child processes, which
-    will in turn terminate all active sessions to pgpool. Then pgpool invokes
-    the failover_command and waits for its completion.
-    After this, pgpool starts new child processes and is ready again to accept
-    connections from clients.
-    </p>
-    </dd>
-
-<dt><a name="FAILBACK_COMMAND"></a>failback_command</dt>
-    <dd>
-    <p>
-    This parameter specifies a command to run when a node is attached.
-    pgpool-II replaces special the following characters with backend specific
-    information.
-    </p>
-
-    <table border>
-    <tr class="header"><th>Special character</th><th>Description</th></tr>
-    <tr><td>%d</td><td>Backend ID of an attached node.</td></tr>
-    <tr><td>%h</td><td>Hostname of an attached node.</td></tr>
-    <tr><td>%p</td><td>Port number of an attached node.</td></tr>
-    <tr><td>%D</td><td>Database cluster path of an attached node.</td></tr>
-    <tr><td>%M</td><td>Old master node</td></tr>
-    <tr><td>%m</td><td>New master node</td></tr>
-    <tr><td>%H</td><td>Hostname of the new master node.</td></tr>
-    <tr><td>%P</td><td>Old primary node ID.</td></tr>
-    <tr><td>%r</td><td>New master port number.</td></tr>
-    <tr><td>%R</td><td>New master database cluster directory.</td></tr>
-    <tr><td>%%</td><td>'%' character</td></tr>
-    </table>
-
-    <p>
-    You need to reload pgpool.conf if you change failback_command.
-    </p>
-    </dd>
-
-<dt><a name="FOLLOW_MASTER_COMMAND"></a>follow_master_command <span class="version">V3.1 -</span></dt>
-    <dd>
-    <p>
-    This parameter specifies a command to run in master/slave streaming replication mode
-    only after a master failover.
-    pgpool-II replaces the following special characters with backend specific information.
-    </p>
-
-    <table border>
-    <tr class="header"><th>Special character</th><th>Description</th></tr>
-    <tr><td>%d</td><td>Backend ID of a detached node.</td></tr>
-    <tr><td>%h</td><td>Hostname of a detached node.</td></tr>
-    <tr><td>%p</td><td>Port number of a detached node.</td></tr>
-    <tr><td>%D</td><td>Database cluster directory of a detached node.</td></tr>
-    <tr><td>%M</td><td>Old master node ID.</td></tr>
-    <tr><td>%m</td><td>New master node ID.</td></tr>
-    <tr><td>%H</td><td>Hostname of the new master node.</td></tr>
-    <tr><td>%P</td><td>Old primary node ID.</td></tr>
-    <tr><td>%r</td><td>New master port number.</td></tr>
-    <tr><td>%R</td><td>New master database cluster directory.</td></tr>
-    <tr><td>%%</td><td>'%' character</td></tr>
-    </table>
-
-    <p>
-    You need to reload pgpool.conf if you change follow_master_command.
-    </p>
-
-    <p>
-    If follow_master_command is not empty, when a master failover is
-    completed in master/slave streaming replication,
-    pgpool degenerate all nodes excepted the new master and starts new child processes
-    to be ready again to accept connections from clients.
-    After this, pgpool run the command set into the 'follow_master_command' for each
-    degenerated nodes. Typically the command should be used to recover the slave from the new master
-    by call the <a href="#pcp_recovery_node">pcp_recovery_node</a> command for example.
-    </p>
-    </dd>
-
-<dt><a name="FAIL_OVER_ON_BACKEND_ERROR"></a>fail_over_on_backend_error <span class="version">V2.3 -</span></dt>
-    <dd>
-    <p>
-    If true, and an error occurs when reading/writing to the backend communication,
-    pgpool-II will trigger the fail over procedure.
-    If set to false, pgpool will report an error and disconnect the session.
-    If you set this parameter to off, it is recommended that you turn on health checking.
-    Please note that even if this parameter is set to off, however, pgpool will also do the fail over when
-    pgpool detects the administrative shutdown of postmaster.
-    </p>
-    <p>
-    You need to reload pgpool.conf if you change this value.
-    </p>
-   </dd>
-</dl>
-
-<h3>Load balancing mode</h3>
-
-<dl>
-<dt><a name="IGNORE_LEADING_WHITE_SPACE"></a>ignore_leading_white_space</dt>
-    <dd>
-    <p>pgpool-II ignores white spaces at the beginning of SQL
-    queries while in the load balance mode. It is useful if used with
-    APIs like DBI/DBD:Pg which adds white spaces against the user's will.
-    </p>
-    <p>
-    You need to reload pgpool.conf if you change this value.
-    </p>
-    </dd>
-
-	<dt id="ALLOW_SQL_COMMENTS">allow_sql_comments <span class="version">V3.4 〜</span></dt>
-    <dd>
-    <p>
-	  If on, ignore SQL comments when judging if load balance or
-	  query cache is possible.
-	  If off, SQL comments effectively prevent the judgment
-	  (pre 3.4 behavior).
-    </p>
-	<p>
-	You need to reload pgpool.conf if you change this value. And you can also use PGPOOL SET command
-	to alter the value of this parameter for a current session.
-	</p>
-    </dd>
-</dl>
-
-<h3>Backends</h3>
-
-<dl>
-<dt><a name="BACKEND_HOSTNAME"></a>backend_hostname</dt>
-    <dd>
-    <p>Specifies where to connect with the PostgreSQL backend.
-    It is used by pgpool-II to communicate with the server.
-    </p>
-    <p>
-    For TCP/IP communication, this parameter can take a hostname or an IP address.
-    If this begins with a slash, it specifies Unix-domain communication
-    rather than TCP/IP; the value is the name of the directory
-    in which the socket file is stored. The default behavior when backend_hostname
-    is empty (<code>''</code>) is to connect to a Unix-domain socket in <code>/tmp</code>.
-    </p>
-    <p>
-    Multiple backends can be specified by adding a number at the end
-    of the parameter name (e.g.<code>backend_hostname0</code>).
-    This number is referred to as "DB node ID", and it starts from 0.
-    The backend which was given the DB node ID of 0 will be called "Master DB".
-    When multiple backends are defined, the service can be continued
-    even if the Master DB is down (not true in some modes).
-    In this case, the youngest DB node ID alive will be the new Master DB.</p>
-    <p>
-    Please note that the DB node which has id 0 has no special meaning
-    if operated in streaming replication mode.
-    Rather, you should care about if the DB node is the "primary node" or not.
-    See <a href="#stream">Streaming Replication</a> for more details.
-    </p>
-    <p>If you plan to use only one PostgreSQL server, specify it by
-    <code>backend_hostname0</code>.</p>
-
-    <p>
-    New nodes can be added in this parameter by reloading a configuration
-    file. However, values cannot be updated so you must restart pgpool-II in that case.
-    </p>
-    </dd>
-
-<dt><a name="BACKEND_PORT"></a>backend_port</dt>
-    <dd>
-    <p>Specifies the port number of the backends.
-    Multiple backends can be specified by adding a number at the end of the parameter name
-    (e.g. <code>backend_port0</code>).
-    If you plan to use only one PostgreSQL server, specify it by <code>backend_port0</code>.</p>
-
-    <p>
-    New backend ports can be added in this parameter by reloading a configuration
-    file. However, values cannot be updated so you must restart
-    pgpool-II in that case.
-    </p>
-    </dd>
-
-<dt><a name="BACKEND_WEIGHT"></a>backend_weight</dt>
-    <dd>
-    <p>Specifies the load balance ratio for the backends. Multiple
-    backends can be specified by adding a number at the end of the
-    parameter name (e.g. <code>backend_weight0</code>). If you plan
-    to use only one PostgreSQL server, specify it by
-    <code>backend_weight0</code>. In the raw mode, set to 1.</p>
-    <p>
-    New backend weights can be added in this parameter by reloading a configuration file.
-    </p>
-    <p>
-    From pgpool-II 2.2.6/2.3 or later, you can change this value by re-loading the configuration file.
-    This will take effect only for new established client sessions.
-    This is useful if you want to prevent any query sent to slaves to perform
-    some administrative work in master/slave mode.
-    </p>
-    </dd>
-
-<dt><a name="BACKEND_DATA_DIRECTORY"></a>backend_data_directory</dt>
-    <dd>
-    <p>Specifies the database cluster directory of the backends.
-    Multiple backends can be specified by adding a number
-    at the end of the parameter name
-    (e.g. <code>backend_data_directory0</code>).
-    If you don't plan to use online recovery, you do not need to specify this parameter.
-    </p>
-
-    <p>
-    New backend data directories can be added in this parameter by reloading a configuration file.
-    However, values cannot be updated so you must restart pgpool-II in that case.
-    </p>
-    </dd>
-
-<dt><a name="BACKEND_FLAG"></a>backend_flag <span class="version">V3.1 -</span></dt>
-    <dd>
-    <p>Controls various backend behavior.
-    Multiple backends can be specified by adding a number at the end of the parameter name
-    (e.g. <code>backend_flag0</code>).
-    </p>
-    <p>
-    Currently followings are allowed.
-    Multiple flags can be specified by using "|".
-    </p>
-
-    <table border>
-    <tr><th class="nodec">ALLOW_TO_FAILOVER</th>
-        <td>Allow to failover or detaching backend. This is the default.
-            You cannot specify with DISALLOW_TO_FAILOVER at a same time.
-        </td></tr>
-    <tr><th class="nodec">DISALLOW_TO_FAILOVER</th>
-    <td>Disallow to failover or detaching backend.
-        This is useful when you protect backend by using HA(High Availability) softwares
-        such as Heartbeat or Pacemaker.
-        You cannot specify with ALLOW_TO_FAILOVER at a same time.
-    </td></tr>
-    </table>
-    </dt>
-</dl>
-
-<h3>SSL</h3>
-
-<dl>
-<dt><a name="SSL">ssl</a> <span class="version">V2.3 -</span></dt>
-    <dd>
-    <p>
-    If true, enable SSL support for both the frontend and backend connections.
-    Note that <code>ssl_key</code> and <code>ssl_cert</code>
-    must also be set in order for SSL to work with frontend connections.
-    </p>
-
-    <p>
-    SSL is off by default.  Note that OpenSSL support must also
-    have been configured at compilation time, as mentioned in the
-    <a href="#install">installation</a> section.
-    </p>
-
-    <p>
-    The pgpool-II daemon must be restarted when updating SSL related settings.
-    </p>
-    </dd>
-
-<dt><a name="SSL_KEY"></a>ssl_key <span class="version">V2.3 -</span></dt>
-    <dd>
-    <p>
-    The path to the private key file to use for incoming frontend connections.
-    </p>
-
-    <p>
-    There is no default value for this option, and if left unset SSL will
-    be disabled for incoming frontend connections.
-    </p>
-    </dd>
-
-<dt><a name="SSL_CERT"></a>ssl_cert <span class="version">V2.3 -</span></dt>
-    <dd>
-    <p>
-    The path to the public x509 certificate file to use for incoming
-    frontend connections.
-    </p>
-
-    <p>
-    There is no default value for this option, and if left unset SSL will
-    be disabled for incoming frontend connections.
-    </p>
-    </dd>
-
-<dt><a name="SSL_CA_CERT"></a>ssl_ca_cert</dt>
-    <dd>
-    <p>
-    The path to a PEM format file containing one or more CA root
-    certificates, which can be used to verify the backend server certificate.
-    This is analogous to the <code>-CAfile</code> option
-    of the OpenSSL <code>verify(1)</code> command.
-    </p>
-
-    <p>
-    The default value for this option is unset, so no verification takes place.
-    Verification will still occur if this option is not set
-    but a value has been given for <code>ssl_ca_cert_dir</code>.
-    </p>
-    </dd>
-
-<dt><a name="SSL_CA_CERT_DIR"></a>ssl_ca_cert_dir</dt>
-    <dd>
-    <p>
-    The path to a directory containing PEM format CA certificate
-    files, which can be used to verify the backend server certificate.
-    This is analogous to the <code>-CApath</code> option
-    of the OpenSSL <code>verify(1)</code> command.
-    </p>
-
-    <p>
-    The default value for this option is unset, so no verification takes place.
-    Verification will still occur if this option is not set
-    but a value has been given for  <code>ssl_ca_cert</code>.
-    </p>
-    </dd>
-
-</dl>
-
-<h3>Other</h3>
-
-<dl>
-  <dt><a name="RELCACHE_EXPIRE"></a>relcache_expire <span class="version">V3.1 -</span></dt>
-    <dd>
-    <p>
-     Life time of relation cache in seconds. 0 means no cache
-     expiration(the default).
-     The relation cache is used for cache the query result against PostgreSQL
-     system catalog to obtain various information including table structures
-     or if it's a temporary table or not. The cache is maintained in a pgpool
-     child local memory and being kept as long as it survives.
-     If someone modify the table by using ALTER TABLE or some such, the relcache
-     is not consistent anymore.
-     For this purpose, relcache_expiration controls the life time of the cache.
-    </p>
-    </dd>
-
- <dt><a name="RELCACHE_SIZE"></a>relcache_size <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-     Number of relcache entries. Default is 256.
-     If you see following message frequently, increase the number.
-    </p>
-<pre>
-"pool_search_relcache: cache replacement happened"
-</pre>
-    </dd>
-
-<dt><a name="CHECK_TEMP_TABLE"></a>check_temp_table <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    If on, enable temporary table check in SELECT statements. This
-    initiates queries against system catalog of primary/master thus
-    increases load of primary/master.  If you are absolutely sure that your
-    system never uses temporary tables and you want to save access
-    to primary/master, you could turn this off.  Default is on.
-    </p>
-	<p>
-	You need to reload pgpool.conf if you change this value. And you can also use PGPOOL SET command
-	to alter the value of this parameter for a current session.
-	</p>
-    </dd>
-
-<dt><a name="CHECK_UNLOGGED_TABLE"></a>check_unlogged_table <span class="version">V3.4 -</span></dt>
-    <dd>
-    <p>
-    If on, enable unlogged table check in SELECT statements. This
-    initiates queries against system catalog of primary/master thus
-    increases load of primary/master.  If you are absolutely sure that your
-    system never uses unlogged (for example, you are using PostgreSQL 9.0 or before) tables and you want to save access
-    to primary/master, you could turn this off.  Default is on.
-    </p>
-	<p>
-	You need to reload pgpool.conf if you change this value. And you can also use PGPOOL SET command
-	to alter the value of this parameter for a current session.
-	</p>
-    </dd>
-		
-</dl>
-
-<h2>Generating SSL certificates</h2>
-<p>
-Certificate handling is outside the scope of this document.  The
-<a href="http://developer.postgresql.org/pgdocs/postgres/ssl-tcp.html">
-Secure TCP/IP Connections with SSL</a> page at postgresql.org has pointers
-with sample commands for how to generate self-signed certificates.
-</p>
-
-<h2 id="failover_in_raw_mode">Failover in the raw Mode</h2>
-
-<p>Failover can be performed in raw mode if multiple servers are
-defined. pgpool-II usually accesses the backend specified by
-<code>backend_hostname0</code> during normal operation.
-If the backend_hostname0 fails for some reason, pgpool-II tries to access the
-backend specified by backend_hostname1.
-If that fails, pgpool-II tries the backend_hostname2, 3 and so on.</p>
-
-<p class="top_link"><a href="#Top">back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1><a name="connection_pool_mode"></a>Connection Pool Mode</h1>
-
-<p>In connection pool mode, all functions in raw mode and the
-connection pool function can be used.
-To enable this mode, you need to turn on "<a href="#CONNECTION_CACHE">connection_cache</a>".
-Following parameters take effect to connection pool.</p>
-
-<dl>
-<dt><a name="MAX_POOL"></a>max_pool</dt>
-    <dd>
-    <p>The maximum number of cached connections in pgpool-II children processes.
-    pgpool-II reuses the cached connection if an incoming connection is
-    connecting to the same database with the same user name.
-    If not, pgpool-II creates a new connection to the backend.
-    If the number of cached connections exceeds max_pool,
-    the oldest connection will be discarded, and uses that slot for the new connection.
-    </p>
-    <p>
-    Default value is 4. Please be aware that the number of
-    connections from pgpool-II processes to the backends may reach
-    <code><a href="#NUM_INIT_CHILDREN">num_init_children</a></code> *
-    <code><a href="#MAX_POOL">max_pool</a></code>.
-    </p>
-    <p>
-    This parameter can only be set at server start. </p>
-    </dd>
-
-<dt><a name="CONNECTION_LIFE_TIME"></a>connection_life_time</dt>
-    <dd>
-    <p>Cached connections expiration time in seconds. An expired
-    cached connection will be disconnected. Default is 0, which
-    means the cached connections will not be disconnected.</p>
-    </dd>
-
-<dt><a name="RESET_QUERY_LIST"></a>reset_query_list</dt>
-    <dd>
-    <p>Specifies the SQL commands sent to reset the connection
-    to the backend when exiting a session. Multiple commands can be
-    specified by delimiting each by ";".
-    Default is the following, but can be changed to suit your system.
-
-<pre>
-reset_query_list = 'ABORT; DISCARD ALL'
-</pre>
-
-    <p>
-    Commands differ in each PostgreSQL versions. Here are the recommended settings.
-    </p>
-
-    <table border>
-    <tr class="header"><th>PostgreSQL version</th><th>reset_query_list value</th></tr>
-    <tr><th>7.1 or before</th><td>ABORT</td></tr>
-    <tr><th>7.2 to 8.2</th><td>ABORT; RESET ALL; SET SESSION AUTHORIZATION DEFAULT</td></tr>
-    <tr><th>8.3 or later</th><td>ABORT; DISCARD ALL</td></tr>
-    </table>
-
-    <ul>
-    <li>"ABORT" is not issued when not in a transaction block for 7.4 or later.</li>
-    </ul>
-
-    <p>
-    You need to reload pgpool.conf upon modification of this directive.
-    </p>
-    </dd>
-</dl>
-
-<h2 id="failover_in_cp_mode">Failover in the Connection Pool Mode</h2>
-
-<p>Failover in the connection pool mode is the same as in the raw mode.</p>
-
-<p class="top_link"><a href="#Top">back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1><a name="replication_mode"></a>Replication Mode</h1>
-
-<p>This mode enables data replication between the backends. The
-configuration parameters below must be set in addition to everything above.</p>
-
-<dl>
-<dt><a name="REPLICATION_MODE"></a>replication_mode</dt>
-    <dd>
-    <p>Setting to true enables replication mode. Default is false.</p>
-    </dd>
-
-<dt><a name="LOAD_BALANCE_MODE"></a>load_balance_mode</dt>
-    <dd>
-    <p>When set to true, SELECT queries will be
-    distributed to each backend for load balancing. Default is false.</p>
-    <p>This parameter can only be set at server start. </p>
-    </dd>
-
-<dt><a name="REPLICATION_STOP_ON_MISMATCH"></a>replication_stop_on_mismatch</dt>
-    <dd>
-    <p>When set to true, if all backends don't return the same packet kind,
-    the backends that differ from most frequent result set are degenerated.
-    </p>
-    <p>
-    A typical use case is a SELECT statement being part of a transaction,
-    <a href="#REPLICATE_SELECT">replicate_select</a> set to true,
-    and SELECT returning a different number of rows among backends.
-    Non-SELECT statements might trigger this though.
-    For example, a backend succeeded in an UPDATE, while others failed.
-    Note that pgpool does NOT examine the content of records returned by SELECT.
-    </p>
-    <p>
-    If set to false, the session is terminated and the backends are not degenerated.
-    Default is false.</p>
-    </dd>
-
-<dt><a name="FAILOVER_IF_AFFECTED_TUPLES_MISMATCH"></a>failover_if_affected_tuples_mismatch
-    <span class="version">V3.0 -</span></dt>
-    <dd>
-    <p>When set to true, if backends don't return the same number of affected
-    tuples during an INSERT/UPDATE/DELETE,
-    the backends that differ from most frequent result set are degenerated.
-    If the frequencies are same, the group which includes master DB node
-    (a DB node having the youngest node id) is remained and other groups are degenerated.
-    </p>
-    <p>
-    If set to false, the session is terminated and the backends are not
-    degenerated. Default is false.</p>
-    </dd>
-
-<dt><a name="WHITE_FUNCTION_LIST"></a>white_function_list <span class="version">V3.0 -</span></dt>
-    <dd>
-    <p>
-    Specify a comma separated list of function names that <strong>do not</strong>
-    update the database. SELECTs using functions not specified in this list are
-    neither load balanced, nor replicated if in replication mode.
-    In master slave mode, such SELECTs are sent to master (primary) only.
-    </p>
-    <p>You can use regular expression into the list to match function name
-     (to which added automatically ^ and $),
-    for example if you have prefixed all your read only function with 'get_' or 'select_'
-    </p>
-<pre>
-white_function_list = 'get_.*,select_.*'
-</pre>
-    </dd>
-
-<dt><a name="BLACK_FUNCTION_LIST"></a>black_function_list <span class="version">V3.0 -</span></dt>
-    <dd>
-    <p>
-    Specify a comma separated list of function names that <strong>do</strong>
-    update the database. SELECTs using functions specified in this list are neither
-    load balanced, nor replicated if in replication mode.
-    In master slave mode, such SELECTs are sent to master(primary) only.
-    </p>
-    <p>You can use regular expression into the list to match function name
-     (to which added automatically ^ and $)
-    for example if you have prefixed all your updating functions with 'set_', 'update_', 'delete_' or 'insert_':
-    </p>
-<pre>
-black_function_list = 'nextval,setval,set_.*,update_.*,delete_.*,insert_.*'
-</pre>
-    <p>
-    Only one of these two lists can be filled in a configuration.
-    </p>
-    <p>
-    Prior to pgpool-II 3.0, nextval() and setval() were known to do
-    writes to the database. You can emulate this by using white_function_list and
-    black_function_list:
-    </p>
-<pre>
-white_function_list = ''
-black_function_list = 'nextval,setval,lastval,currval'
-</pre>
-
-    <p>
-    Please note that we have lastval and currval in addition to nextval and setval.
-    Though lastval() and currval() are not writing functions,
-    it is wise to add lastval() and currval() to avoid errors
-    in the case when these functions are accidentally load balanced to other DB node.
-    Because adding to black_function_list will prevent load balancing.
-    </p>
-    </dd>
-
-<dt><a name="REPLICATE_SELECT"></a>replicate_select</dt>
-    <dd>
-    <p>When set to true, pgpool-II replicates SELECTs replication mode. If false,
-    pgpool-II sends SELECTs without writing function to the Master DB only. Default is false.
-    </p>
-    <p>
-    If a SELECT query is inside an explicit transaction block, replicate_select and
-    <a href="#LOAD_BALANCE_MODE">load_balance_mode</a> will have an effect on how replication works.
-    Details are shown below.
-    </p>
-
-    <table border>
-    <tr class="center">
-        <th class="nodec">replicate_select is true</th>
-        <td>Y</td><td colspan="4">N</td>
-    </tr>
-    <tr class="center">
-        <th class="nodec">load_balance_mode is true</th>
-        <td>any</td><td colspan="3">Y</td><td>N</td>
-    <tr class="center">
-        <th class="nodec">SELECT is inside a transaction block</th>
-        <td>any</td><td colspan="2">Y</td><td>N</td><td>any</td>
-    </tr>
-    <tr class="center">
-        <th class="nodec">transaction isolation level is SERIALIZABLE and<br>
-                          the transaction has issued a write query</th>
-        <td>any</td><td>Y</td><td>N</td><td>any</td><td>any</td>
-    </tr>
-    <tr class="footer center">
-        <th class="nodec">results(R:replication, M: send only to master, L: load balance)</th>
-        <td>R</td><td>M</td><td>L</td><td>L</td><td>M</td>
-    </tr>
-    </table>
-    </dd>
-
-<dt><a name="INSERT_LOCK"></a>insert_lock</dt>
-    <dd>
-    <p>If replicating a table with SERIAL data type, the SERIAL column value may differ between the backends.
-    This problem is avoidable by locking the table explicitly
-    (although, transactions' parallelism will be severely degraded).
-    To achieve this, however, the following change must be made:
-    </p>
-<pre>
-INSERT INTO ...
-</pre>
-
-    <p>
-    to
-    </p>
-
-<pre>
-BEGIN;
-LOCK TABLE ...
-INSERT INTO ...
-COMMIT;
-</pre>
-
-    <p>When <code>insert_lock</code> is true, pgpool-II automatically adds
-    the above queries each time an INSERT is executed
-    (if already in transaction, it simply adds LOCK TABLE ....).
-    </p>
-    <p>pgpool-II 2.2 or later, it automatically detects whether the table
-    has a SERIAL columns or not, so it will never lock the table if it does not use SERIAL columns.
-    </p>
-    <p>
-    pgpool-II 3.0 series until 3.0.4 uses a row lock against the sequence
-    relation, rather than table lock.
-    This is intended to minimize lock  conflict with VACUUM (including autovacuum).
-    However this will lead to another problem.
-    After transaction wraparound happens, row locking against the sequence relation
-    causes PostgreSQL internal error
-    (more precisely, access error on pg_clog, which keeps transaction status).
-    To prevent this, PostgreSQL core developers decided to disallow row locking
-    against sequences and this will break pgpool-II of course
-    (the &quot;fixed&quot; version of PostgreSQL was released as 9.0.5,
-    8.4.9, 8.3.16 and 8.2.22).
-    </p>
-    <p>
-    pgpool-II 3.0.5 or later uses a row lock against pgpool_catalog.insert_lock
-    table because new PostgreSQL disallows a row lock against the sequence relation.
-    So creating insert_lock table in all databases which are accessed via pgpool-II beforehand is required.
-    See <a href="#install">Creating insert_lock table</a> for more details.
-    If does not exist insert_lock table, pgpool-II locks the insert target table.
-    This behavior is same as pgpool-II 2.2 and 2.3 series.
-    If you want to use insert_lock which is compatible with older releases,
-    you can specify lock method by configure script.
-    See <a href="#install">configure</a> for more details.
-    </p>
-    <p>
-    You might want to have a finer (per statement) control:
-    </p>
-
-    <ol>
-        <li>set <code>insert_lock</code> to true, and add <code>/*NO INSERT LOCK*/</code>
-            at the beginning of an INSERT statement for which
-            you do not want to acquire the table lock.</li>
-
-        <li>set <code>insert_lock</code> to false, and add <code>/*INSERT LOCK*/</code>
-            at the beginning of an INSERT statement for which
-            you want to acquire the table lock.</li>
-    </ol>
-
-    <p>
-    Default value is false. If <code>insert_lock</code> is enabled,
-    the regression tests for PostgreSQL 8.0 will fail in transactions,
-    privileges, rules, and alter_table. The reason for this is that
-    pgpool-II tries to LOCK the VIEW for the rule test, and will
-    produce the following error message:</p>
-
-<pre>
-! ERROR: current transaction is aborted, commands ignored until
-end of transaction block
-</pre>
-
-    <p>For example, the transactions test tries an INSERT into a table which does not exist,
-    and pgpool-II causes PostgreSQL to acquire the lock before that.
-    The transaction will be aborted, and the following INSERT statement produces
-    the above error message.</p>
-    </dd>
-
-<dt><a name="RECOVERY_USER"></a>recovery_user</dt>
-    <dd>
-    <p>
-    This parameter specifies a PostgreSQL user name for online recovery.
-    It can be changed without restarting.
-    </p>
-    </dd>
-
-<dt><a name="RECOVERY_PASSWORD"></a>recovery_password</dt>
-    <dd>
-    <p>
-    This parameter specifies a PostgreSQL password for online recovery.
-    It can be changed without restarting.
-    </p>
-    </dd>
-
-<dt><a name="RECOVERY_1ST_STAGE_COMMAND"></a>recovery_1st_stage_command</dt>
-    <dd>
-    <p>
-    This parameter specifies a command to be run by master(primary) PostgreSQL server
-    at the first stage of online recovery.
-    The command file must be put in the database cluster directory for security reasons.
-    For example, if recovery_1st_stage_command = 'sync-command',
-    then pgpool-II executes $PGDATA/sync-command.
-    </p>
-    <p>
-    recovery_1st_stage_command will receive 4 parameters as follows:
-    </p>
-    <ol>
-        <li>path to master(primary) database cluster</li>
-        <li>PostgreSQL host name to be recovered</li>
-        <li>path to database cluster to be recovered</li>
-		<li>master database port number</li>
-    </ol>
-    <p>
-    Note that pgpool-II <b>accepts</b> connections and queries while
-    recovery_1st_stage command is executed. You can retrieve and update data during this stage.
-    </p>
-	<p>
-	<font color="red">
-	CAUTION:
-	</font>
-	recovery_1st_stage_command runs as an SQL command from PostgreSQL's point of view. If you enable PostgreSQL's statement_time_out and it's shorter than the execution time of the recovery_1st_stage_command, PostgreSQL cancels the command.
-	Typical symptoms of this is, rsync used in the command is killed by signal 2 for example.
-	</p>
-    <p>
-    This parameter can be changed without restarting.
-    </p>
-    </dd>
-
-<dt><a name="RECOVERY_2ND_STAGE_COMMAND"></a>recovery_2nd_stage_command</dt>
-    <dd>
-    <p>
-    This parameter specifies a command to be run by master(primary) PostgreSQL server
-    at the second stage of online recovery.
-    The command file must be put in the database cluster directory for security reasons.
-    For example, if recovery_2nd_stage_command = 'sync-command', then
-    pgpool-II executes $PGDATA/sync-command.
-    </p>
-    <p>
-    recovery_2nd_stage_command will receive 4 parameters as follows:
-    </p>
-    <ol>
-        <li>path to master(primary) database cluster</li>
-        <li>PostgreSQL host name to be recovered</li>
-        <li>path to database cluster to be recovered</li>
-		<li>port number of database cluster to be recovered</li>
-    </ol>
-    </p>
-    <p>
-    Note that pgpool-II <b>does not accept</b> connections and queries while
-    recovery_2nd_stage_command is running.
-    Thus if a client stays connected for a long time,
-    the recovery command won't be executed. pgpool-II waits
-    until all clients have closed their connections. The command is only executed
-    when no client is connected to pgpool-II anymore.
-    </p>
-	<p>
-	<font color="red">
-	CAUTION:
-	</font>
-	recovery_2nd_stage_command runs as an SQL command from PostgreSQL's point of view. If you enable PostgreSQL's statement_time_out and it's shorter than the execution time of the recovery_2nd_stage_command, PostgreSQL cancels the command.
-	Typical symptoms of this is, rsync used in the command is killed by signal 2 for example.
-	</p>
-    <p>
-    This parameter can be changed without restarting.
-    </p>
-    </dd>
-
-<dt><a name="RECOVERY_TIMEOUT"></a>recovery_timeout</dt>
-    <dd>
-    <p>
-    pgpool does not accept new connections during the second stage. If a client
-    connects to pgpool during recovery processing, it will have to wait for the end  of the recovery.
-    </p>
-    <p>
-    This parameter specifies recovery timeout in sec. If this timeout is reached,
-    pgpool cancels online recovery and accepts connections. 0 means no wait.
-    </p>
-    <p>
-    This parameter can be changed without restarting.
-    </p>
-    </dd>
-
-<dt><a name="CLIENT_IDLE_LIMIT_IN_RECOVERY"></a>client_idle_limit_in_recovery
-    <span class="version">V2.2 -</span></dt>
-    <dd>
-    <p> Similar to client_idle_limit but only takes effect in the second
-    stage of recovery. A client being idle for client_idle_limit_in_recovery
-    seconds since its last query will get disconnected.
-    This is useful for preventing the pgpool recovery from being
-    disturbed by a lazy client or if the TCP/IP connection between the client
-    and pgpool is accidentally down (a cut cable for instance).
-    If set to -1, disconnect the client immediately.
-    The default value for client_idle_limit_in_recovery is 0,
-    which means the feature is turned off.
-    </p>
-    <p>
-    If your clients are very busy, pgpool-II cannot enter the second stage of
-    recovery whatever value of client_idle_limit_in_recovery you may choose.
-    In this case, you can set client_idle_limit_in_recovery to -1
-    so that pgpool-II immediately disconnects such busy clients before entering the second stage.
-    </p>
-	<p>
-	You need to reload pgpool.conf if you change this value. And you can also use PGPOOL SET command
-	to alter the value of this parameter for a current session.
-	</p>
-    </dd>
-
-<dt><a name="LOBJ_LOCK_TABLE"></a>lobj_lock_table <span class="version">V2.2 -</span></dt>
-    <dd>
-    <p>
-    This parameter specifies a table name used for large object replication control.
-    If it is specified, pgpool will lock the table specified by
-    lobj_lock_table and generate a large object id by looking into
-    pg_largeobject system catalog and then call lo_create to create the large object.
-    This procedure guarantees that pgpool will get the same large object id in all DB
-    nodes in replication mode. Please note that PostgreSQL 8.0 or older does not
-    have lo_create, thus this feature will not work.
-    </p>
-    <p>
-    A call to the libpq function lo_creat() will trigger this feature. Also
-    large object creation through Java API (JDBC driver), PHP
-    API (pg_lo_create, or similar API in PHP library such as PDO), and this same
-    API in various programming languages are known to use a similar protocol,
-    and thus should work.
-    </p>
-    <p>
-    The following large object create operation will not work:
-    <p>
-    <ul>
-        <li>lo_create of libpq</li>
-        <li>Any API of any language using lo_create</li>
-        <li>lo_import function in backend</li>
-        <li>SELECT lo_create</li>
-    </ul>
-    </p>
-    <p>
-    It does not matter what schema lobj_lock_table is stored in, but this table
-    should be writable by any user. Here is an example showing how to create such a table:
-    </p>
-<pre>
-CREATE TABLE public.my_lock_table ();
-GRANT ALL ON public.my_lock_table TO PUBLIC;
-</pre>
-
-    <p>
-    The table specified by lobj_lock_table must be created beforehand. If
-    you create the table in template1, any database created afterward will have it.
-    </p>
-    <p>
-    If lobj_lock_table has empty string(''), the feature is disabled
-    (thus large object replication will not work). The default value for
-    lobj_lock_table is ''.
-    </p>
-    </dd>
-
-</dl>
-
-<h2 id="condition_for_load_balance">condition for load balancing</h2>
-<p>
-For a query to be load balanced, all the following requirements
-must be met:
-</p>
-<ul>
-    <li>PostgreSQL version 7.4 or later</li>
-    <li>either in replication mode or master slave mode</li>
-    <li>the query must not be in an explicitly declared
-        transaction (i.e. not in a BEGIN ~ END block) when operated in replication mode
-       <ul>
-          <li>However, if following conditions are met, load balance is possible even if in an explicit transaction
-              <ul>
-                <li>transaction isolation level is not SERIALIZABLE</li>
-                <li>the transaction has not issued a write query yet (until a write query is issued, load balance is possible. Here "write query" means non SELECT DML or DDL. SELECTs having write functions as specified in black or white function list is not regarded as a write query. This may be changed in the future.)</li>
-		<li>If black and white function list is empty, SELECTs having functions is regarded as a read only query.</li>
-              </ul>
-          </li>
-        </ul>
-    </li>
-    <li>it's not SELECT INTO
-    <li>it's not SELECT FOR UPDATE nor FOR SHARE
-    <li>it starts with "SELECT" or one of COPY TO STDOUT, EXPLAIN, EXPLAIN ANALYZE SELECT...
-     ignore_leading_white_space = true will ignore leading white space.
-     (Except for SELECTs using writing functions specified in <a href="#BLACK_FUNCTION_LIST">black_list</a> or
-     <a href="#WHITE_FUNCTION_LIST">white_list</a>)
-    <li><span class="version">V3.0 -</span>in master slave mode, in addition to above, following conditions must be met:
-        <ul>
-          <li>does not use temporary tables</li>
-          <li>does not use unlogged tables</li>
-          <li>does not use system catalogs</li>
-        </ul>
-    </li>
-
-</ul>
-
-<p>
-Note that you could suppress load balancing by inserting arbitrary
-comments just in front of the SELECT query:
-<pre>
-/*REPLICATION*/ SELECT ...
-</pre>
-</p>
-<p>
-If you want to use comments without supressing load balancing, you can set <a href="#ALLOW_SQL_COMMENTS">allow_sql_comments</a> to on.
-</p>
-<p>
-Please refer to <a href="#replicate_select">replicate_select</a> as well.
-See also a <a href="where_to_send_queries.pdf">flow chart</a>.
-</p>
-
-<p>
-<font color="red">
-Note: the JDBC driver has an autocommit option. If the autocommit is false, the JDBC
-driver sends "BEGIN" and "COMMIT" by itself. In this case <a href="#condition_for_load_balance">the same restriction above regarding load balancing</a> will be applied.
-</font>
-</p>
-
-<h2 id="failover_in_replication_mode">Failover in Replication Mode</h2>
-
-<p>
-pgpool-II detaches a dead backend from the pool, maintaining the database 
-service via the remaining backends provided that there is at least one healthy 
-backend.
-</p>
-
-<h2 id="errors_in_replication_mode">Specific errors in replication mode</h2>
-<p>
-In replication mode, if pgpool finds that the number of affected tuples
-by INSERT, UPDATE, DELETE are not same,
-it sends erroneous SQL statement to all DB nodes to abort the transaction
-if failover_if_affected_tuples_mismatch is set to false
-(fail-over occurs if it is set to true).
-In this case you will see following error messages on client terminal:
-</p>
-<pre>
-=# UPDATE t SET a = a + 1;
-ERROR: pgpool detected difference of the number of update tuples Possible last query was: "update t1 set i = 1;"
-HINT: check data consistency between master and other db node
-</pre>
-<p>
-You will see number of updated rows in PostgreSQL log
-(in this case DB node 0 has 0 updated row and DB node 1 has 1 updated row)
-<pre>
-2010-07-22 13:23:25 LOG:   pid 5490: SimpleForwardToFrontend: Number of affected tuples are: 0 1
-2010-07-22 13:23:25 LOG:   pid 5490: ReadyForQuery: Degenerate backends: 1
-2010-07-22 13:23:25 LOG:   pid 5490: ReadyForQuery: Number of affected tuples are: 0 1
-</pre>
-</p>
-
-<p class="top_link"><a href="#Top">back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1><a name="master_slave_mode"></a>Master/Slave Mode</h1>
-
-<p>This mode is used to couple pgpool-II with another master/slave
-replication software (like Slony-I and Streaming replication), which is responsible
-for doing the actual data replication.
-</p>
-<p>
-Please note that the number of slaves is not necessarily limited to just 1.
-Actually you could have up to 127 slaves (0 slaves is allowed).
-</p>
-<p>
-DB nodes' information (<a href="#BACKEND_HOSTNAME">backend_hostname</a>,
-<a href="#BACKEND_PORT">backend_port</a>, <a href="#BACKEND_WEIGHT">backend_weight</a>,
-<a href="#BACKEND_FLAG">backend_flag</a> and <a href="#BACKEND_DATA_DIRECTORY">backend_data_directory</a>
-if you need the online recovery functionality) must be set, in the same way as in the replication mode.
-In addition to that, set <code><a href="#MASTER_SLAVE_MODE">master_slave_mode</a></code> and
-<code><a href="#LOAD_BALANCE_MODE">load_balance_mode</a></code> to true.
-</p>
-<p>
-pgpool-II will then send queries that need to be replicated to the
-Master DB, and other queries will be load balanced if possible.
-Queries sent to Master DB because they cannot be balanced are of course accounted for in the
-load balancing algorithm.</p>
-
-
-<p>In master/slave mode, DDL and DML for temporary table can be executed on the master node only.
-SELECT can be forced to be executed on the master as well,
-but for this you need to put a /*NO LOAD BALANCE*/ comment before the SELECT statement.</p>
-
-<p>In the master/slave mode, <code><a href="#REPLICATION_MODE">replication_mode</a></code> must be set
-to false, and <code><a href="#MASTER_SLAVE_MODE">master_slave_mode</a></code> to true.</p>
-
-<p>The master/slave mode has a 'master_slave_sub mode'.
-The default is 'slony' which is
-suitable for Slony-I. You can also set it to 'stream', which should be
-set if you want to work with PostgreSQL's built-in replication system
-(Streaming Replication).
-The sample configuration file for the Slony-I sub-mode is
-pgpool.conf.sample-master-slave and the sample for the streaming replication
-sub-module is pgpool.conf.sample-stream.
-</p>
-<p>
-Please restart pgpool-II if you change any of the above parameters.
-</p>
-<p>
-You can set <a href="#WHITE_FUNCTION_LIST">white_function_list</a> and
-<a href="#BLACK_FUNCTION_LIST">black_function_list</a> to control load
-balancing in master/slave mode.
-See <a href="#WHITE_FUNCTION_LIST">white_function_list</a> for more details.
-</p>
-
-<p class="top_link"><a href="#Top">back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1><a name="stream"></a>Streaming Replication <span class="version">V3.1 -</span></h1>
-<p>
-As stated above, pgpool-II can work together with Streaming Replication, which
-is available since PostgreSQL 9.0. To use it, enable '<a href="#MASTER_SLAVE_MODE">master_slave_mode</a>' and
-set '<a href="#MASTER_SLAVE_SUB_MODE">master_slave_sub_mode</a>' to 'stream'.
-pgpool-II assumes that Streaming Replication is used with Hot Standby at present,
-which means that the standby database is open read-only.
-The following directives can be used with this mode:
-</p>
-<p>
-
-<dl>
-<dt id="DELAY_THRESHOLD">delay_threshold <span class="version">V3.0 -</span></dt>
-    <dd>
-    <p>
-    Specifies the maximum tolerated replication delay of the standby against the
-    primary server in WAL bytes.
-    If the delay exceeds delay_threshold, pgpool-II does not send SELECT queries to
-    the standby server anymore. Everything is sent to the primary server
-    even if load balance mode is enabled, until the standby has caught-up.
-    If delay_threshold is 0 or sr checking is disabled, the delay
-    checking is not performed. This check is performed every '<a href=#SR_CHECK_PERIOD">sr_check_period</a>'.
-    The default value for delay_threshold is 0.
-    </p>
-    <p>
-    You need to reload pgpool.conf if you change this directive.
-    </p>
-    </dd>
-
-<dt id="SR_CHECK_PERIOD">sr_check_period <span class="version">V3.1 -</span></dt>
-    <dd>
-    <p>
-    This parameter specifies the interval between the streaming replication
-    delay checks in seconds. Default is 0, which means the check is disabled.
-    </p>
-    <p>
-    You need to reload pgpool.conf if you change sr_check_period.
-    </p>
-    </dd>
-
-<dt id="SR_CHECK_USER">sr_check_user <span class="version">V3.1 -</span></dt>
-    <dd>
-    <p>
-    The user name to perform streaming replication check. This user must
-    exist in all the PostgreSQL backends.
-    Otherwise, the check causes an error.
-    Note that sr_check_user and sr_check_password are used even sr_check_period is 0.
-    To identify the primary server, pgpool-II sends function call request to each backend.
-    sr_check_user and sr_check_password are used for this session.
-    </p>
-    <p>
-    You need to reload pgpool.conf if you change sr_check_user.
-    </p>
-    </dd>
-
-<dt id="SR_CHECK_PASSWORD">sr_check_password <span class="version">V3.1 -</span></dt>
-    <dd>
-    <p>
-    The password of the user to perform streaming replication check.
-    If no password is required, specify empty string('').
-    </p>
-    <p>
-    You need to reload pgpool.conf if you change sr_check_password.
-    </p>
-    </dd>
-
-<dt id="SR_CHECK_DATABASE">sr_check_database <span class="version">V3.5 -</span></dt>
-    <dd>
-    <p>
-    The database to perform streaming replication delay check.
-    The default is "postgres" (which is the built-in database name in 3.4 or before).
-    </p>
-    <p>
-    You need to reload pgpool.conf if you change sr_check_database.
-    </p>
-    </dd>
-
-<dt id="LOG_STANDBY_DELAY">log_standby_delay <span class="version">V3.1 -</span></dt>
-    <dd>
-    <p>
-    Specifies how to log the replication delay.
-    If 'none' is specified, no log is written.
-    If 'always', log the delay every time the replication delay is checked.
-    If 'if_over_threshold' is specified, the log is written when the delay
-    exceeds <a href="#DELAY_THRESHOLD">delay_threshold</a>.
-    The default value for log_standby_delay is 'none'.
-    You need to reload pgpool.conf if you change this directive.
-    </p>
-    <p>
-    You could monitor the replication delay by using the "<a href="#pool_status">show pool_status</a>"
-    command as well.
-    The column name is "standby_delay#"(where '#' should be replaced by DB node id).
-    </p>
-    </dd>
-</dl>
-
-
-<h2 id="failover_in_stream_mode">Failover with Streaming Replication</h2>
-<p>
-In master/slave mode with streaming replication, if the primary or standby
-node goes down, pgpool-II can be set up to trigger a failover.
-Nodes can be detached automatically without further setup.
-While doing streaming replication, the standby node checks for the presence of a "trigger file"
-and on finding it, the standby stops continuous recovery and goes into read-write mode.
-By using this, you can have the standby database take over when the primary goes down.
-</p>
-<p>
-<strong>Caution: If you plan to use multiple standby nodes, we recommend
-to set a <a href="#DELAY_THRESHOLD">delay_threshold</a> to prevent any query directed to other standby
-nodes from retrieving older data.
-</p>
-<p>
-If a second standby took over primary when the first standby has already
-taken over too, you would get bogus data from the second standby.
-We recommend not to plan this kind of configuration.
-</strong>
-</p>
-<p>
-How to setup a failover configuration is as follows.
-</p>
-<p>
-<ol>
-    <li>Put a failover script somewhere (for example /usr/local/pgsql/bin) and give it execute permission.
-<pre>
-$ cd /usr/loca/pgsql/bin
-$ cat failover_stream.sh
-#! /bin/sh
-# Failover command for streaming replication.
-# This script assumes that DB node 0 is primary, and 1 is standby.
-#
-# If standby goes down, do nothing. If primary goes down, create a
-# trigger file so that standby takes over primary node.
-#
-# Arguments: $1: failed node id. $2: new master hostname. $3: path to
-# trigger file.
-
-failed_node=$1
-new_master=$2
-trigger_file=$3
-
-# Do nothing if standby goes down.
-if [ $failed_node = 1 ]; then
-    exit 0;
-fi
-
-# Create the trigger file.
-/usr/bin/ssh -T $new_master /bin/touch $trigger_file
-
-exit 0;
-
-chmod 755 failover_stream.sh
-</pre>
-    </li>
-
-    <li>Set <a href="#FAILOVER_COMMAND">failover_commmand</a> in pgpool.conf.
-<pre>
-failover_command = '/usr/local/src/pgsql/9.0-beta/bin/failover_stream.sh %d %H /tmp/trigger_file0'
-</pre>
-    </li>
-
-    <li>Set recovery.conf on the standby node.
-    <a href="recovery.conf.sample">A sample recovery.conf</a> can be found
-    under the PostgreSQL installation directory. Its name is
-    "share/recovery.conf.sample".
-    Copy recovery.conf.sample as recovery.conf inside the database cluster directory and edit it.
-<pre>
-standby_mode = 'on'
-primary_conninfo = 'host=name of primary_host user=postgres'
-trigger_file = '/tmp/trigger_file0'
-</pre>
-    </li>
-
-    <li>Set postgresql.conf on the primary node.
-    Below is just an example. You will need to tweak it for your environment.
-<pre>
-wal_level = hot_standby
-max_wal_senders = 1
-</pre>
-    </li>
-
-    <li>Set pg_hba.conf on the primary node.
-    Below is just an example. You will need to tweak it for your environment.
-<pre>
-host    replication    postgres        192.168.0.10/32        trust
-</pre>
-    </li>
-
-</ol>
-
-<p>
-Start primary and secondary PostgreSQL nodes to initiate Streaming replication.
-If the primary node goes down, the standby node will automatically start as a normal PostgreSQL
-and will be ready to accept write queries.
-</p>
-
-<h2 id="load_balance_in_stream_mode">Streaming Replication</h2>
-<p>
-While using Streaming replication and Hot Standby, it is important to
-determine which query can be sent to the primary or the standby,
-and which one should not be sent to the standby.
-pgpool-II's Streaming Replication mode carefully takes care of this.
-In this chapter we'll explain how pgpool-II accomplishes this.
-</p>
-<p>
-We distinguish which query should be sent to which node by looking
-at the query itself.
-</p>
-<p>
-<ul>
-    <li>These queries should be sent to the primary node only
-    <ul>
-       <li>INSERT, UPDATE, DELETE, COPY FROM, TRUNCATE, CREATE, DROP, ALTER, COMMENT</li>
-       <li>SELECT ... FOR SHARE | UPDATE</li>
-       <li>SELECT in transaction isolation level SERIALIZABLE</li>
-       <li>LOCK command more strict than ROW EXCLUSIVE MODE</li>
-       <li>DECLARE, FETCH, CLOSE</li>
-       <li>SHOW</li>
-       <li>Some transactional commands:
-           <ul>
-               <li>BEGIN READ WRITE, START TRANSACTION READ WRITE</li>
-               <li>SET TRANSACTION READ WRITE, SET SESSION CHARACTERISTICS AS TRANSACTION READ WRITE</li>
-               <li>SET transaction_read_only = off</li>
-           </ul>
-       </li>
-       <li>Two phase commit commands: PREPARE TRANSACTION, COMMIT PREPARED, ROLLBACK PREPARED</li>
-       <li>LISTEN, UNLISTEN, NOTIFY</li>
-       <li>VACUUM</li>
-       <li>Some sequence functions (nextval and setval)</li>
-       <li>Large objects creation commands</li>
-    </ul>
-    </li>
-
-    <li>These queries can be sent to both the primary node and the standby node.
-    If load balancing is enabled, these types of queries can be sent to the standby node.
-    However, if delay_threshold is set and the replication delay is higher than
-    <a href="#DELAY_THRESHOLD">delay_threshold</a>, queries are sent to the primary node.
-    <ul>
-       <li>SELECT not listed above</li>
-       <li>COPY TO</li>
-    </ul>
-    </li>
-
-   <li>These queries are sent to both the primary node and the standby node
-   <ul>
-       <li>SET</li>
-       <li>DISCARD</li>
-       <li>DEALLOCATE ALL</li>
-   </ul>
-   </li>
-</ul>
-</p>
-
-<p>
-In an explicit transaction:
-</p>
-
-<ul>
-    <li>Transaction starting commands such as BEGIN are sent to the primary node.
-    <li>Following SELECT and some other queries that can be sent to both
-        primary or standby are executed in the transaction or on the standby node.
-    </li>
-    <li>
-        Commands which cannot be executed on the standby such as INSERT are sent
-        to the primary.
-        After one of these commands, even SELECTs are sent to the primary node,
-        This is because these SELECTs might want to see the result of an INSERT immediately.
-        This behavior continues until the transaction closes or aborts.
-    </li>
-</ul>
-
-<p>
-In the extended protocol, it is possible to determine if the query can
-be sent to standby or not in load balance mode while parsing the query.
-The rules are the same as for the non extended protocol.
-For example, INSERTs are sent to the primary node.
-Following bind, describe and execute will be sent to the primary node as well.
-</p>
-
-<p>
-[Note: If the parse of a SELECT statement is sent to the standby node due to load
-balancing, and then a DML statement, such as an INSERT, is sent to pgpool-II,
-then the parsed SELECT will have to be executed on the primary node.
-Therefore, we re-parse the SELECT on the primary node.]
-</p>
-
-<p>
-Lastly, queries that pgpool-II's parser thinks to be an error are sent to the
-primary node.
-</p>
-
-<p>
-You can use database name and application name for smaller granularity
-in specifying load balance.
-</p>
-
-<p>
-<dl>
-  <dt id="DATABASE_REDIRECT_PREFERENCE_LIST">database_redirect_preference_list <span class="version">V3.4 〜</span></dt>
-    <dd>
-    <p>
-	  you can set "database name:node id" pair to specify the node id when connecting to the database.
-	  For example, by specifying "test:1",  pgpool-II always redirects SELECT to node 1 in case of connecting to database "test".
-	  You can specify multiple "database name:node id" pair by separating them using comma (,).
-	  Regular expressions are accepted for database name.
-	  Special keyword "primary" indicates the primary node and "standby" indicates one of standby nodes.
-    </p>
-	<p>
-	  Here is an example.
-	<pre>
-database_redirect_preference_list = 'postgres:primary,mydb[01]:1,mydb2:standby'
-	</pre>
-	</p>
-	<p>
-	  SELECTs will be redirected to primary if you connect to postgres database.
-	  Connecting to mydb0 or mydb1 will redirect SELECTs to node 1.
-	  Connecting to mydb2 will redirect SELECTs to one of standby nodes.
-	</p>
-    <p>
-    You need to reload pgpool.conf if you change this directive.
-    </p>
-    </dd>
-
-  <dt id="APP_NAME_REDIRECT_PREFERENCE_LIST">app_name_redirect_preference_list <span class="version">V3.4 〜</span></dt>
-    <dd>
-    <p>
-	  you can set "application name:node id" pair to specify the node id when the application is used.
-	  "Application name" is a name specified by a client when it connects to database.
-	You can use it in PostgreSQL 9.0 or later.
-    </p>
-    <p>
-      <blockquote>
-	<font color="red">Caution: </font>
-	JDBC driver postgresql-9.3 or before does not send the application name in the startup packet
-	even if application name is specified for the JDBC driver option "ApplicationName" and "assumeMinServerVersion=9.0" is specified and cannot use this feature.
-	If you want to use the feature through JDBC, please use postgresql-9.4 or later version of driver.
-      </blockquote>
-    </p>
-    <p>
-	  For example, application of psql command is "psql".
-	  pgpool-II recognize application names only when clients sends a start up packet.
-	  Clients can send application names later on but pgpool-II will not recognize them.
-	</p>
-	<p>
-	  The notion of app_name_redirect_preference_list is same as database_redirect_preference_list.
-	  Thus you can use regular expressions for application name.
-    </p>
-	<p>
-	  Here is an example.
-	<pre>
-app_name_redirect_preference_list = 'psql:primary,myapp1:1,myapp2:standby'
-	</pre>
-	</p>
-	<p>
-	  In this example, psql sends SELECTs to primary node, myapp1 sends to node 1, and myapp2 sends to one of standby nodes.
-	</p>
-	<p>
-	  app_name_redirect_preference_list takes precedence over database_redirect_preference_list.
-	  See the next example.
-	  <pre>
-		database_redirect_preference_list = 'bigdb:primary'
-		app_name_redirect_preference_list = 'myapp:2'
-	  </pre>
-	</p>
-	<p>
-	  Applications connecting to bigdb database send SELECTs to primary node.
-	  However myapp sends SELECTs to node 2 even if it connects to bigdb.
-	  This is useful in a scenario: myapp2 sends very heavy SELECTs to execute analysis jobs.
-	  You want to use node 2 solely for analysis purpose.
-	</p>
-    <p>
-    You need to reload pgpool.conf if you change this directive.
-    </p>
-    </dd>
-</dl>
-</p>
-
-
-
-<h2 id="online_recovery_in_stream_mode">Online recovery with Streaming Replication</h2>
-<p>
-In master/slave mode with streaming replication, online recovery can be performed.
-In the online recovery procedure, primary server acts as a master server and recovers specified standby server.
-Thus the recovery procedure requires that the primary server is up and running.
-If the primary server goes down, and no standby server is promoted, you need to stop
-pgpool-II and all PostgreSQL servers and recover them manually.
-</p>
-
-<p>
-<ol>
-    <li>Set <a href="#RECOVERY_USER">recovery_user</a>. Usually it's "postgres".
-<pre>
-recovery_user = 'postgres'
-</pre>
-    </li>
-
-    <li>Set <a href="#RECOVERY_PASSWORD">recovery_password</a> for
-    <a href="#RECOVERY_USER">recovery_user</a> to login database.
-<pre>
-recovery_password = 't-ishii'
-</pre>
-    </li>
-
-    <li>Set <a href="#RECOVERY_1ST_STAGE_COMMAND">recovery_1st_stage_command</a>.
-    The script for this stage should perform a base backup of the primary and
-    restore it on the standby node.
-    Place this script inside the primary database cluster directory and give it
-    execute permission.
-    Here is the sample script <a href="basebackup.sh">(basebackup.sh)</a> for
-    a configuration of one primary and one standby.
-    You need to setup ssh so that recovery_user can login from the primary to
-    the standby without being asked for a password.
-<pre>
-recovery_1st_stage_command = 'basebackup.sh'
-</pre>
-    </li>
-
-    <li>Leave <a href="#RECOVERY_2ND_STAGE_COMMAND">recovery_2nd_stage_command</a> be empty.
-<pre>
-recovery_2nd_stage_command = ''
-</pre>
-    </li>
-
-    <li>Install required C and SQL functions to perform online recovery into each DB nodes.</li>
-</p>
-
-<pre>
-# cd pgpool-II-x.x.x/sql/pgpool-recovery
-# make
-# make install
-# psql -f pgpool-recovery.sql template1
-</pre>
-
-    <li>After completing online recovery, pgpool-II will start PostgreSQL on
-    the standby node.
-    Install the script for this purpose on each DB nodes.
-    <a href="pgpool_remote_start">Sample script</a> is included in "sample"
-    directory of the source code.
-    This script uses ssh. You need to allow recovery_user to login from the
-    primary node to the standby node without being asked password.
-    </li>
-</ol>
-
-
-<p>
-That's it.
-Now you should be able to use <a href="#pcp_recovery_node">pcp_recovery_node</a> (as long as the standby
-node stops) or push "recovery" button of pgpoolAdmin to perform online recovery.
-If something goes wrong, please examine pgpool-II log, primary server log and standby server log(s).
-</p>
-
-<p>
-For your reference, here are the steps taken in the recovery procedure.
-<ol id="setting_for_online_recovery_in_stream_mode">
-    <li>Pgpool-II connects to primary server's template1 database
-        as user = <a href="#RECOVERY_USER">recovery_user</a>,
-        password = <a href="#RECOVERY_PASSWORD">recovery_password</a>.
-    </li>
-    <li>Primary server executes pgpool_recovery function.
-    </li>
-    <li>pgpool_recovery function executes <a href="#RECOVERY_1ST_STAGE_COMMAND">recovery_1st_stage_command</a>.
-        Note that PostgreSQL executes functions with database cluster as the current directory.
-        Thus recovery_1st_stage_command is executed in the database cluster directory.
-    </li>
-    <li>Primary server executes <a href="#pool_remote_start">pgpool_remote_start</a> function.
-        This function executes a script named "pgpool_remote_start" in the database cluster directory,
-        and it executes pg_ctl command on the standby server to be recovered via ssh.
-        pg_ctl will start postmaster in background.
-        So we need to make sure that postmaster on the standby actually starts.
-    </li>
-    <li>pgpool-II tries to connect to the standby PostgreSQL
-        as user = <a href="#RECOVERY_USER">recovery_user</a> and
-        password = <a href="#RECOVERY_PASSWORD">recovery_password</a>.
-        The database to be connected is "postgres" if possible. Otherwise "template1" is used.
-        pgpool-II retries for <a href="#RECOVERY_TIMEOUT">recovery_timeout</a> seconds.
-        If success, go to next step.
-    </li>
-    <li>If <a href="#FAILBACK_COMMAND">failback_command</a> is not empty,
-        pgpool-II parent process executes the script.
-    </li>
-    <li>After failback_command finishes, pgpool-II restart all child processes.
-    </li>
-</ol>
-</p>
-
-<p class="top_link"><a href="#Top">back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1><a name="hba"></a>Setting up pool_hba.conf for client authentication (HBA)</h1>
-<p>
-Just like the pg_hba.conf file for PostgreSQL, pgpool supports a similar
-client authentication function using a configuration file called  "pool_hba.conf".
-</p>
-<p>
-When you install pgpool, pool_hba.conf.sample will be installed in
-"/usr/local/etc", which is the default directory for configuration
-files. Copy pool_hba.conf.sample as pool_hba.conf and edit it if necessary.
-By default, pool_hba authentication is disabled.
-Change <a href="#ENABLE_POOL_HBA">enable_pool_hba</a> to on to enable it.
-</p>
-<p>
-The format of the pool_hba.conf file follows very closely PostgreSQL's
-pg_hba.conf format.
-</p>
-<pre>
-local      DATABASE  USER  METHOD  [OPTION]
-host       DATABASE  USER  CIDR-ADDRESS  METHOD  [OPTION]
-</pre>
-<p>
-See "pool_hba.conf.sample" for a detailed explanation of each field.
-</p>
-<p>
-Here are the limitations of pool_hba.
-</p>
-
-<ul>
-<li>"samegroup" for DATABASE field is not supported</li>
-    <p>
-    Since pgpool does not know anything about users in the backend server,
-    the database name is simply checked against entries in the DATABASE
-    field of pool_hba.conf.
-    </p>
-
-<li>group names following "+" for USER field is not supported</li>
-    <p>
-    This is for the same reason as for the "samegroup" described above. A
-    user name is simply checked against the entries in the USER field
-    of pool_hba.conf.
-    </p>
-
-<li>IPv6 for IP address/mask is not supported</li>
-    <p>
-    pgpool currently does not support IPv6.
-    </p>
-
-<li>Only "trust", "reject", "md5" and "pam" for METHOD field are supported</li>
-    <p>
-    Again, this is for the same reason as for the "samegroup" described above.
-    pgpool does not have access to user/password information.
-    </p>
-    <p>
-    To use md5 authentication, you need to register your name and password in "pool_passwd".
-    See <a href="#md5">Authentication / Access Controls</a> for more details.
-</ul>
-
-<p>
-Note that everything described in this section is about the authentication
-taking place between a client and pgpool;
-a client still has to go through the PostgreSQL's authentication process.
-As far as pool_hba is concerned, it does not matter if a user name and/or database name
-given by a client (i.e. psql -U testuser testdb) really exists in the backend.
-pool_hba only cares if a match in the pool_hba.conf is found or not.
-</p>
-
-<p>
-PAM authentication is supported using user information on the host where
-pgpool is executed. To enable PAM support in pgpool, specify "--with-pam"
-option to configure:
-</p>
-<pre>
-configure --with-pam
-</pre>
-<p>
-To enable PAM authentication, you need to create a
-service-configuration file for pgpool in the system's PAM
-configuration directory (which is usually at "/etc/pam.d").
-A sample service-configuration file is installed as "share/pgpool.pam" under the install directory.
-</p>
-
-<p class="top_link"><a href="#Top">back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1><a name="memqcache"></a>In memory query Cache <span class="version">V3.2 -</span></h1>
-
-<p>
-You can use in memory query cache in any mode.
-It is different from the above query cache on the point that
-in memory query cache is faster because cache storage is in memory.
-Moreover you don't need to restart pgpool-II when the cache is outdated
-because the underlying table gets updated.
-</p>
-
-<p>
-In memory cache saves pair of SELECT statements
-(with its Bind parameters if the SELECT is an extended query).
-If the same SELECTs comes in, it returns the value from cache.
-Since no SQL parsing nor access to PostgreSQL are involved, it's extremely fast.
-</p>
-
-<p>
-On the other hand, it might be slower than the normal path because it adds some overhead to store cache.
-Moreover when a table is updated, pgpool automatically deletes all the caches related to the table.
-So the performance will be degraded by a system with a lot of updates.
-If the cache_hit_ratio is lower than 70%, you might want to disable in memory cache.
-</p>
-
-<h2 id="MEMORY_CACHE_RESTRICTIONS">Restrictions</h2>
-<ul>
-    <li>
-    In memory query cache deletes the all cache of an updated table automatically
-    with monitoring if the executed query is UPDATE, INSERT, ALTER TABLE and so on.
-    But pgpool-II isn't able to recognize implicit updates due to triggers, foreign keys and
-    DROP TABLE CASCADE.
-    You can avoid this problem with <a href="#MEMQCACHE_EXPIRE">memqcache_expire</a>
-    by which pgpool deletes old cache in a fixed time automatically, or with
-    <a href="#BLACK_MEMQCACHE_TABLE_LIST">black_memqcache_table_list</a>
-    by which pgpool's memory cache flow ignores the tables.
-    </li>
-
-    <li>
-    If you want to use multiple instances of pgpool-II with online memory cache which uses shared memory,
-    it could happen that one pgpool deletes cache,
-    and the other one doesn't do it thus finds old cached result when a table gets updated.
-    Memcached is the better cache storage in this case.
-    </li>
-</ul>
-
-<h2 id="MEMORY_CACHE_ENABLED">Enabling in memory query cache</h2>
-<p>
-To enable the memory cache functionality, set this to on (default is off).
-</p>
-
-<pre>
-memory_cache_enabled = on
-</pre>
-
-<h2 id="MEMQCACHE_METHOD">Choosing cache storage</h2>
-<p>
-You can choose a cache storage: shared memory or <a href="http://memcached.org">memcached</a>
-(you can't use the both).
-Query cache with shared memory is fast and easy because you don't have to install and configure memcached,
-but restricted the max size of cache by the one of shared memory.
-Query cache with memcached needs a overhead to access network, but you can set the size as you like.
-</p>
-<p>
-Memory cache behavior can be specified by memqcache_method directive.
-Either "shmem"(shared memory) or "memcached". Default is shmem.
-</p>
-<pre>
-memqcache_method = 'shmem'
-</pre>
-
-
-<h2 id="memqcache_cases">When in memory query cache is prohibited</h2>
-<p>
-
-Not All of SELECTs and WITH can be cached. In some cases including followings,
-cache is avoided to keep consistency between caches and databases.
-</p>
-<ul>
-    <li>SELECT starting with "/*NO QUERY CACHE*/" comment</li>
-    <li>SELECT including tables in <a href="#BLACK_MEMQCACHE_TABLE_LIST">black_memqcache_table_list</a></li>
-    <li>SELECT FOR SHARE / UPDATE</li>
-    <li>SELECT including un-immutable functions</li>
-    <li>SELECT including TEMP TABLE</li>
-    <li>SELECT including system catalogs</li>
-    <li>SELECT including VIEWs or unlogged tables.
-        However if the table is in <a href="#WHITE_MEMQCACHE_TABLE_LIST">white_memqcache_table_list</a>, the result will be cached.</li>
-
-    <li>SELECT including VIEWs</li>
-    <li>SELECT in an aborted explicit transaction</li>
-    <li>SELECT with the result larger than <a href="#MEMQCACHE_MAXCACHE">memqcache_maxcache</a></li>
-</ul>
-
-<h2 id="non_memqcache_case">When cache is not used</h2>
-<p>
-It can happen that even if the matched query cache exists, pgpool doesn't return it.
-</p>
-<ul>
-    <li>If an updating query is executed in an explicit transaction, during the transaction,
-        pgpool doesn't use any query cache.</li>
-    <li>The matched query cache is made by the other user (for security reason)</li>
-    <li>The matched query cache has to be deleted due to <a href="#MEMQCACHE_EXPIRE">memqcache_expire</a>.</li>
-</ul>
-
-<h2 id="memqcache_params">Configuring</h2>
-
-<p>
-These are the parameters used with both of shmem and memcached.
-</p>
-
-<dl>
-<dt id="MEMQCACHE_EXPIRE">memqcache_expire <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    Life time of query cache in seconds. Default is 0.
-    0 means no cache expiration, and cache have been enabled until a table is updated.
-    This parameter and <a href="#MEMQCACHE_AUTO_CACHE_INVALIDATION">memqcache_auto_cache_invalidation</a>
-    are orthogonal.
-    </p>
-    </dd>
-
-<dt id="MEMQCACHE_AUTO_CACHE_INVALIDATION">memqcache_auto_cache_invalidation
-<span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    If on, automatically deletes cache related to the updated tables.
-    If off, does not delete caches. Default is on.
-    This parameter and <a href="#MEMQCACHE_EXPIRE">memqcache_expire</a>. are orthogonal.
-    </p>
-    </dd>
-
-<dt id="MEMQCACHE_MAXCACHE">memqcache_maxcache <span class="version">V3.2 -</span></dt>
-    <dd>
-        <p>
-        If the size of a SELECT result is larger than memqcache_maxcache bytes,
-        it is not cached and the messages is shown:
-        </p>
-<pre>
-2012-05-02 15:08:17 LOG:   pid 13756: pool_add_temp_query_cache: data size exceeds memqcache_maxcache. current:4095 requested:111 memq_maxcache:4096
-</pre>
-        <p>
-        To avoid this problem, you have to set memqcache_maxcache larger.
-        But if you use shared memory as the cache storage,
-        it must be lower than <a href="#MEMQCACHE_CACHE_BLOCK_SIZE">memqcache_cache_block_size</a>.
-        If memqcached, it must be lower than the size of slab (default is 1 MB).
-        </p>
-    </dd>
-
-<dt id="WHITE_MEMQCACHE_TABLE_LIST">white_memqcache_table_list <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    Specify a comma separated list of table names whose SELECT results are to be cached even if
-    they are VIEWs or unlogged tables. You can use regular expression (to which added automatically ^ and $).
-    </p>
-    <p>
-    TABLEs and VIEWs in both of white_memqcache_table_list and
-    <a href="#BLACK_MEMQCACHE_TABLE_LIST">black_memqcache_table_list</a> are cached.
-    </p>
-    <p>
-    You need to add both non schema qualified name and schema qualified name if you plan to use both of them in your query. For exmaple, if you want to use both "table1" and "public.table1" in your query, you need to add "table1,public.table1", not just "table1".
-    </p>
-
-    </dd>
-
-<dt id="BLACK_MEMQCACHE_TABLE_LIST">black_memqcache_table_list <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    Specify a comma separated list of table names whose SELECT results are <strong>NOT</strong> to be cached.
-    You can use regular expression (to which added automatically ^ and $).
-    </p>
-    <p>
-    You need to add both non schema qualified name and schema qualified name if you plan to use both of them in your query. For exmaple, if you want to use both "table1" and "public.table1" in your query, you need to add "table1,public.table1", not just "table1".
-    </p>
-    </dd>
-
-<dt id="MEMQCACHE_OIDDIR">memqcache_oiddir <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    Full path to the directory where oids of tables used by SELECTs are stored.
-    Under memqcache_oiddir there are directories named database oids,
-    and under each of them there are files named table oids used by SELECTs.
-    In the file pointers to query cache are stored.
-    They are used as keys to delete caches.
-    </p>
-    <p>
-    Directories and files under memqcache_oiddir are not deleted whenever pgpool-II restarts.
-    If you start pgpool by "<a href="#start">pgpool -C</a>", pgpool starts without the old oidmap.
-    </p>
-    </dd>
-</dl>
-
-<h2 id="monitoring_memqcache">Monitoring caches</h2>
-<p>
-This explains how to monitor in memory query cache.
-To know if a SELECT result is from query cache or not,
-enable <a href="#LOG_PER_NODE_STATEMENT">log_per_node_statement</a>.
-</p>
-<pre>
-2012-05-01 15:42:09 LOG:   pid 20181: query result fetched from cache. statement: select * from t1;
-</pre>
-
-<p>
-<a href="#pool_status">pool_status</a> command shows the cache hit ratio.
-</p>
-<pre>
-memqcache_stats_start_time           | Tue May  1 15:41:59 2012 | Start time of query cache stats
-memqcache_no_cache_hits              | 80471                    | Number of SELECTs not hitting query cache
-memqcache_cache_hits                 | 36717                    | Number of SELECTs hitting query cache
-</pre>
-
-
-<p>
-In this example, you can calculate like the below:
-</p>
-<p>
-<pre>
-(memqcache_cache_hits) / (memqcache_no_cache_hits+memqcache_cache_hits) = 36717 / (36717 + 80471) = 31.3%
-</pre>
-
-<p>
-<a href="#pool_cache">show pool_cache</a> commands shows the same one.
-</p>
-
-<h2 id="shmem_params">Configuring to use shared memory</h2>
-<p>
-These are the parameters used with shared memory as the cache storage.
-</p>
-
-<dl>
-<dt id="MEMQCACHE_TOTAL_SIZE">memqcache_total_size <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    Specify the size of shared memory as cache storage in bytes.
-    </p>
-    </dd>
-
-<dt id="MEMQCACHE_MAX_NUM_CACHE">memqcache_max_num_cache <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    Specify the number of cache entries.
-    This is used to define the size of cache management space
-    (you need this in addition to <a href="#MEMQCACHE_TOTAL_SIZE">memqcache_total_size</a>).
-    The management space size can be calculated by:
-    <a href="#MEMQCACHE_MAX_NUM_CACHE">memqcache_max_num_cache</a> * 48 bytes.
-    Too small number will cause an error while registering cache.
-    On the other hand too large number is just a waste of space.
-    </p>
-    </dd>
-
-<dt id="MEMQCACHE_CACHE_BLOCK_SIZE">memqcache_cache_block_size <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    If cache storage is shared memory, pgpool uses the memory divided by memqcache_cache_block_size.
-    SELECT result is packed into the block.
-    However because the SELECT result cannot be placed in several blocks, it cannot be cached if it is larger
-    than memqcache_cache_block_size.
-    memqcache_cache_block_size must be greater or equal to 512.
-    </p>
-    </dd>
-</dl>
-
-<h2 id="memcached_params">Configuring to use memcached</h2>
-
-<p>
-These are the parameters used with memcached as the cache storage.
-</p>
-
-<dl>
-<dt id="MEMQCACHE_MEMCACHED_HOST">memqcache_memcached_host <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    Specify the host name or the IP address in which memcached works.
-    If it is the same one as pgpool-II, set 'localhost'.
-    </p>
-    </dd>
-
-<dt id="MEMQCACHE_MEMCACHED_PORT">memqcache_memcached_port <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    Specify the port number of memcached. Default is 11211.
-    </p>
-    </dd>
-</dl>
-
-
-<h3 id="install_memcached">memcached Installation</h3>
-
-<p>
-To use memcached as cache storage, pgpool-II needs a working memcached and
-the client library: libmemcached.
-It is easy to install them by rpms. This explains how to install from source codes.
-</p>
-
-<p>
-memcached's source code can be downloaded from:
-<a href="http://memcached.org/">memcached development page</a>
-</p>
-
-<dl>
-<dt>configure</dt>
-    <dd>
-    <p>
-    After extracting the source tarball, execute the configure script.
-    </p>
-<pre>
-./configure
-</pre>
-    </dd>
-
-<dt>make</dt>
-    <dd>
-<pre>
-make
-make install
-</pre>
-    </dd>
-</dl>
-
-<h3 id="install_libmemcached">libmemcached Installation</h3>
-
-<p>
-Libmemcached is a client library for memcached.
-You need to install libmemcached after installing memcached.
-</p>
-
-<p>
-libmemcached's source code can be downloaded from:
-<a href="http://libmemcached.org/libMemcached.html">libmemcached development page</a>
-</p>
-
-<dl>
-<dt>configure</dt>
-    <dd>
-    <p>
-    After extracting the source tarball, execute the configure script.
-    </p>
-<pre>
-./configure
-</pre>
-
-    <p>
-    If you want non-default values, some options can be set:
-    </p>
-
-    <ul>
-        <li><code>--with-memcached=path</code><br/>
-        The top directory where Memcached are installed.</li>
-    </ul>
-    </dd>
-
-<dt>make</dt>
-    <dd>
-<pre>
-make
-make install
-</pre>
-    </dd>
-</dl>
-
-<p class="top_link"><a href="#Top">back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1>Starting/Stopping pgpool-II<a name="start"></a></h1>
-
-<h2 id="start_pgpool">Start pgpool-II</h2>
-
-<p>All the backends must be started before starting pgpool-II.</p>
-
-<pre>
-pgpool [-c][-f config_file][-a hba_file][-F pcp_config_file][-n][-D][-d][x]
-</pre>
-
-<table border>
-  <tr><td>-c</td><td>--clear-cache</td>
-      <td>deletes query cache</td></tr>
-  <tr><td>-f config_file</td><td>--config-file config-file</td>
-      <td>specifies pgpool.conf</td></tr>
-  <tr><td>-a hba_file</td><td>--hba-file hba_file</td>
-       <td>specifies pool_hba.conf</tr>
-  <tr><td>-F pcp_config_file</td><td>--pcp-password-file</td>
-      <td>specifies pcp.conf</td></tr>
-  <tr><td>-n</td><td>--no-daemon</td>
-      <td>no daemon mode (terminal is not detached)</td></tr>
-  <tr><td>-D</td><td>--discard-status</td>
-      <td>Discard pgpool_status file and do not restore previous status
-      <span class="version">V3.0 -</span></td></tr>
-  <tr><td>-C</td><td>--clear-oidmaps</td>
-      <td>Discard oid maps in <a href="#MEMQCACHE_OIDDIR">memqcache_oiddir</a> for in memory query cache
-      (only when <a href="#MEMQCACHE_METHOD">memqcache_method</a> is 'memcached',
-      if shmem, discard whenever pgpool starts).
-      <span class="version">V3.2 -</span></td></tr>
-  <tr><td>-d</td><td>--debug</td><td>debug mode</tr>
-  <tr><td>-x</td><td>--debug-assertions</td>
-      <td>Turns on various assertion checks, This is a debugging aid</td></tr>
-</table>
-
-<h2 id="stop_pgpool">Stop pgpool-II</h2>
-
-<p>
-There are two ways to stop pgpool-II. One is using a PCP command
-(described later), the other using a pgpool-II command. Below is an example of the
-pgpool-II command.
-</p>
-
-<pre>
-pgpool [-f config_file][-F pcp_config_file] [-m {s[mart]|f[ast]|i[mmediate]}] stop
-</pre>
-
-<table border>
-  <tr><td><code>-m s[mart]</code></td><td><code>--mode s[mart]</code></td>
-      <td>waits for clients to disconnect, and shutdown (default)</td></tr>
-  <tr><td><code>-m f[ast]</code></td><td><code>--mode f[ast]</code></td>
-      <td>does not wait for clients; shutdown immediately</td></tr>
-  <tr><td><code>-m i[mmediate]</code></td><td><code>--mode i[mmediate]</code></td>
-      <td>the same as <code>'-m f'</code></td></tr>
-</table>
-
-<p>
-pgpool records backend status into the [logdir]/pgpool_status file.
-From pgpool-II 3.4.0 the file format of pgpool_status has been changed: it's an ordinary ASCII file and you can read and edit the contents by using your favorite text editor.
-For example, if you add new backend and restart pgpool-II, you might have wait for long time until pgpool-II detects the new backend and performs failover.
-By editing pgpool_status to set the backend to be down status, you could avoid the situation because pgpool-II's health check skips down nodes.
-Each line in the file corresponding to each backend node status.
-The first backend status is the first line, and and the seconds backend status is the second line and so on.
-The backend status is represented by any of "up", "down", "unused" (case ignored).
-Here is an example of pgpool_status:
-<pre>
-up
-down
-up
-</pre>
-</p>
-
-<p>
-Note that pre-3.4.0 pgpool-II uses binary format pgpool_status. Pgpool-II 3.4.0 or later can read the file as well. However pre-3.4.0 pgpool-II cannot read ASCII format pgpool_status file.
-</p>
-
-<p>
-When pgpool
-restarts, it reads this file and restores the backend status. This will prevent
-a difference in data among DB nodes which might be caused by following scenario:
-</p>
-<ol>
-    <li>A backend suddenly stops and pgpool executes the fail over procedure</li>
-    <li>An update occurs on one of the active DBs through pgpool</li>
-    <li>The administrator decides to stop pgpool</li>
-    <li>Someone decides to restart the stopping DB without notifying the admin</li>
-    <li>The administrator restarts pgpool</li>
-</ol>
-
-<p>
-If for some reason, for example, the stopped DB has been synced with the
-active DB by another means, pgpool_status can be removed safely before
-starting pgpool.
-</p>
-
-<p class="top_link"><a href="#Top">back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1>Reloading pgpool-II configuration files<a name="reload"></a></h1>
-<p>pgpool-II can reload configuration files without restarting.
-</p>
-
-<pre>
-pgpool [-c][-f config_file][-a hba_file][-F pcp_config_file] reload
-</pre>
-<p>
-<table border>
-  <tr><td>-f config_file</td><td>--config-file config-file</td><td>specifies pgpool.conf</tr>
-  <tr><td>-a hba_file</td><td>--hba-file hba_file</td><td>specifies pool_hba.conf</tr>
-  <tr><td>-F pcp_config_file</td><td>--pcp-password-file</td><td>specifies pcp.conf</tr>
-</table>
-
-<p>
-Please note that some configuration items cannot be changed by
-reloading. New configuration takes effect after a change for new sessions.
-</p>
-
-<p class="top_link"><a href="#Top">back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1><a name="pgpool-show-commands"></a>PGPOOL SHOW and SET commands <span class="version">V3.6 -</span></h1>
-
-<h2>PGPOOL SHOW</h2>
-<p>The PGPOOL SHOW command will display the current value of pgpool-II configuration parameters.
-This command is similar to the SHOW command in PostgreSQL with an addition of
-PGPOOL keyword to distinguish it from the PostgreSQL SHOW command.
-</p>
-
-<h3>Syntax</h3>
-<dl>
-	<dt><a name="PGPOOL_SHOW_NAME"></a>PGPOOL SHOW <a>configuration_parameter</a></dt>
-	<dd>
-		<p>
-		Show the current value of one pgpool-II configuration parameter.
-		</p>
-	</dd>
-	<dt><a name="PGPOOL_SHOW_GROUP_NAME"></a>PGPOOL SHOW <a>configuration_parameter_group</a></dt>
-	<dd>
-		<p>
-		Show the current value of all pgpool-II configuration parameter belonging to group_name group.
-		Currently there are three parameter groups.
-		
-		<ul>
-			<li><strong>backend:</strong> configuration group of all backend config parameters </li>
-			<li><strong>other_pgpool:</strong> configuration group of all watchdog node config parameters </li>
-			<li><strong>heartbeat:</strong> configuration group of all watchdog heartbeat node config parameters </li>
-		</ul>
-
-		</p>
-	</dd>
-	<dt><a name="PGPOOL_SHOW_ALL"></a>PGPOOL SHOW ALL</dt>
-	<dd>
-		<p>
-		Show the values of all pgpool-II configuration parameters, with descriptions.
-		</p>
-	</dd>
-</dl>
-<p>
-<strong>Examples.</strong>
-</p>
-<p>
-Show the current setting of the parameter port.
-</p>
-<pre>
-PGPOOL SHOW port;
-port
-------
-9999
-(1 row)
-</pre>
-</p>
-
-<p>
-Show the current setting of the parameter black_function_list.
-</p>
-<pre>
- PGPOOL SHOW black_function_list;
- black_function_list
- ---------------------
- nextval,setval
- (1 row)
-
-</pre>
-</p>
-
-<p>
-Show the current settings of all the configuration parameters belonging to backend group.
-</p>
-<pre>
- PGPOOL SHOW backend;
- item                     |          value          |              description
- -------------------------+-------------------------+-----------------------------------------------------------
- backend_hostname0        | 127.0.0.1               | hostname or IP address of PostgreSQL backend.
- backend_port0            | 5434                    | port number of PostgreSQL backend.
- backend_weight0          | 0                       | load balance weight of backend.
- backend_data_directory0  | /var/lib/pgsql/data     | data directory of the backend.
- backend_flag0            | ALLOW_TO_FAILOVER       | Controls various backend behavior.
- backend_hostname1        | 127.0.0.1               | hostname or IP address of PostgreSQL backend.
- backend_port1            | 5432                    | port number of PostgreSQL backend.
- backend_weight1          | 1                       | load balance weight of backend.
- backend_data_directory1  | /home/work/installed/pg | data directory of the backend.
- backend_flag1            | ALLOW_TO_FAILOVER       | Controls various backend behavior.
- (10 rows)
- 
-</pre>
-</p>
-
-<p>
-Show all settings.
-</p>
-<pre>
- PGPOOL SHOW ALL;
- item                     |          value          |              description
- -------------------------+-------------------------+-----------------------------------------------------------
- backend_hostname0        | 127.0.0.1               | hostname or IP address of PostgreSQL backend.
- backend_port0            | 5434                    | port number of PostgreSQL backend.
- backend_weight0          | 0                       | load balance weight of backend.
- backend_data_directory0  | /var/lib/pgsql/data     | data directory of the backend.
- backend_flag0            | ALLOW_TO_FAILOVER       | Controls various backend behavior.
- backend_hostname1        | 127.0.0.1               | hostname or IP address of PostgreSQL backend.
- backend_port1            | 5432                    | port number of PostgreSQL backend.
- backend_weight1          | 1                       | load balance weight of backend.
- backend_data_directory1  | /home/work/installed/pg | data directory of the backend.
- backend_flag1            | ALLOW_TO_FAILOVER       | Controls various backend behavior.
- other_pgpool_hostname0   | localhost               | Hostname of other pgpool node for watchdog connection.
- .
- .
- .
- ssl                      | off                     | Enables SSL support for frontend and backend connections
- (138 rows)
-
-</pre>
-</p>
-
-<h2>PGPOOL SET</h2>
-<p>
-The PGPOOL SET command changes the value of pgpool-II configuration parameters for the current session.
-This command is similar to the SET command in PostgreSQL with an addition of
-PGPOOL keyword to distinguish it from the PostgreSQL SET command.
-</p>
-
-<h3>Syntax</h3>
-<dl>
-	<dt><a name="PGPOOL_SET_NAME"></a>PGPOOL SET <a>configuration_parameter</a> { TO | = } { value | 'value' | DEFAULT }</dt>
-	<dd>
-		<p>
-		Sets the current value of the pgpool-II configuration parameter to new or DEFAULT value for current session.
-		</p>
-	</dd>
-</dl>
-
-<p>
-<strong>Examples.</strong>
-</p>
-<p>
-Change the value of client_idle_limit parameter.
-</p>
-<pre>
- PGPOOL SET client_idle_limit = 350;
-</pre>
-</p>
-
-<p>
-Reset the value of client_idle_limit parameter to default.
-</p>
-<pre>
- PGPOOL SET client_idle_limit TO DEFAULT;
-</pre>
-</p>
-
-<p>
-Change the value of log_min_messages parameter.
-</p>
-<pre>
- PGPOOL SET log_min_messages TO INFO;
-</pre>
-</p>
-
-<h2>PGPOOL RESET</h2>
-<p>
-The PGPOOL RESET command restores the value of pgpool-II configuration parameters to the default value.
-The default value is defined as the value that the parameter would have had, if no PGPOOL SET had ever been issued for it in the current session.
-This command is similar to the RESET command in PostgreSQL with an addition of
-PGPOOL keyword to distinguish it from the PostgreSQL SET command.
-</p>
-
-<h3>Syntax</h3>
-<dl>
-	<dt><a name="PGPOOL_RESET_NAME"></a>PGPOOL RESET <a>configuration_parameter</a></dt>
-	<dd>
-		<p>
-		Reset the value of one pgpool-II configuration parameter.
-		</p>
-	</dd>
-	<dt><a name="PGPOOL_RESET_ALL"></a>PGPOOL RESET ALL</dt>
-	<dd>
-		<p>
-		Reset the values of all pgpool-II configuration parameters.
-		</p>
-	</dd>
-</dl>
-
-<p>
-<strong>Examples.</strong>
-</p>
-<p>
-Reset the value of client_idle_limit parameter.
-</p>
-<pre>
- PGPOOL RESET client_idle_limit;
-</pre>
-</p>
-
-<p>
-Reset the value of all parameter to default.
-</p>
-<pre>
- PGPOOL RESET ALL;
-</pre>
-</p>
-
-<p class="top_link"><a href="#Top">back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1><a name="show-commands"></a>SHOW commands</h1>
-<h2>Overview</h2>
-<p>
-pgpool-II provides some information via the SHOW command. SHOW is a real SQL
-statement, but pgPool-II intercepts this command if it asks for specific
-pgPool-II information. Available options are:
-</p>
-<ul>
-  <li>pool_status, to get the configuration</li>
-  <li>pool_nodes, to get the nodes information <span class="version">V3.0 -</span></li>
-  <li>pool_processes, to get information on pgPool-II processes <span class="version">V3.0 -</span></li>
-  <li>pool_pools, to get information on pgPool-II pools <span class="version">V3.0 -</span></li>
-  <li>pool_version, to get the pgPool_II release version <span class="version">V3.0 -</span></li>
-</ul>
-
-<p>Other than "pool_status" are added since pgpool-II 3.0.
-<p>
-<u>Note</u> : The term 'pool' refers to the pool of PostgreSQL sessions owned by one pgpool process,
-not the whole sessions owned by pgpool.
-</p>
-</p>
-<p>the "pool_status" SQL statement was already available in previous releases,
-but the other ones have appeared in release 3.0.</p>
-
-<h2 id="pool_status">pool_status</h2>
-<p>"SHOW pool_status" sends back the list of configuration parameters with
-their name, value, and description. Here is an excerpt of the result:
-</p>
-<pre>
-benchs2=# show pool_status;
-                 item                 |             value              |                           description
---------------------------------------+--------------------------------+------------------------------------------------------------------
- listen_addresses                     | localhost                      | host name(s) or IP address(es) to listen to
- port                                 | 9999                           | pgpool accepting port number
- socket_dir                           | /tmp                           | pgpool socket directory
- pcp_port                             | 9898                           | PCP port # to bind
- pcp_socket_dir                       | /tmp                           | PCP socket directory
-</pre>
-
-<h2 id="pool_nodes">pool_nodes <span class="version">V3.0 -</span></h2>
-<p>"SHOW pool_nodes" sends back a list of all configured nodes. It
-displays the node id, the hostname, the port, the status, the weight (only meaningful
-if you use the load balancing mode), the role, the SELECT query counts issued to each backend, whether the node is for load balancing or not and the streaming replication delay value in bytes if operated in streaming replication mode (in other mode, it is simply 0). The possible values in the status column
-are explained in the <a href="#pcp_node_info">pcp_node_info reference</a>.
-If the hostname is something like "/tmp", that means pgpool-II is connecting to backend by using UNIX domain sockets. The SELECT count does not include internal queries used by pgoool-II. Also the counters are reset to zero upon starting up of pgpool-II.
-</p>
-<p>
-Please note that since pgpool-II <span class="version">3.6</span>, The status column shows the human readable status instead of status code
-</p>
-<pre>
-benchs2=# show pool_nodes;
- node_id | hostname | port  | status | lb_weight |  role   | select_cnt | load_balance_node | replication delay 
----------+----------+-------+--------+-----------+---------+------------+-------------------+-------------------
- 0       | /tmp     | 11002 | up      | 0.500000  | primary | 9231       | true             | 0
- 1       | /tmp     | 11003 | up      | 0.500000  | standby | 9469       | false            | 4248
-(2 rows)
-</pre>
-
-<h2>pool_processes <span class="version">V3.0 -</span></h2>
-<p>"SHOW pool_processes" sends back a list of all pgPool-II processes waiting
-for connections and dealing with a connection.
-</p>
-<p>
-It has 6 columns:
-<ul>
-    <li>pool_pid is the PID of the displayed pgPool-II process</li>
-    <li>start_time is the timestamp of when this process was launched</li>
-    <li>database is the database name of the currently active backend for this process</li>
-    <li>username is the user name used in the connection of the currently active backend for this process</li>
-    <li>create_time is the creation time and date of the connection</li>
-    <li>pool_counter counts the number of times this pool of connections (process) has been used by clients</li>
-</ul>
-</p>
-<p>This view will always return num_init_children lines.</p>
-<pre>
-benchs2=# show pool_processes;
- pool_pid |     start_time      | database | username  |     create_time     | pool_counter
-----------+---------------------+----------+-----------+---------------------+--------------
- 8465     | 2010-08-14 08:35:40 |          |           |                     |
- 8466     | 2010-08-14 08:35:40 | benchs   | guillaume | 2010-08-14 08:35:43 | 1
- 8467     | 2010-08-14 08:35:40 |          |           |                     |
- 8468     | 2010-08-14 08:35:40 |          |           |                     |
- 8469     | 2010-08-14 08:35:40 |          |           |                     |
-(5 lines)
-</pre>
-
-<h2 id="pool_pools">pool_pools <span class="version">V3.0 -</span></h2>
-<p>"SHOW pool_pools" sends back a list of pools handled by pgPool-II.
-their name, value, and description. Here is an excerpt of the result:
-</p>
-<p>
-It has 11 columns:
-<ul>
-    <li>pool_pid is the PID of the pgPool-II process</li>
-    <li>start_time is the time and date when this process was launched</li>
-    <li>pool_id is the pool identifier (should be between 0 and max_pool-1)</li>
-    <li>backend_id is the backend identifier
-        (should be between 0 and the number of configured backends minus one)</li>
-    <li>database is the database name for this process's pool id connection</li>
-    <li>username is the user name for this process's pool id connection</li>
-    <li>create_time is the creation time and date of this connection</li>
-    <li>majorversion and minorversion are the version of the protocol used in this connection</li>
-    <li>pool_counter counts the number of times this connection has been used by clients</li>
-    <li>pool_backendpid is the PID of the PostgreSQL process</li>
-    <li>pool_connected is a true (1) if a frontend is currently using this backend.</li>
-</ul>
-</p>
-<p>It'll always return <a href="#NUM_INIT_CHILDREN">num_init_children</a> * <a href="#MAX_POOL">max_pool</a> * number_of_backends lines.</p>
-<pre>
-  pool_pid |     start_time      | pool_id | backend_id | database | username  |     create_time     | majorversion | minorversion | pool_counter | pool_backendpid | pool_connected
-----------+---------------------+---------+------------+----------+-----------+---------------------+--------------+--------------+--------------+-----------------+----------------
- 8465     | 2010-08-14 08:35:40 | 0       | 0          |          |           |                     |              |              |              |                 |
- 8465     | 2010-08-14 08:35:40 | 1       | 0          |          |           |                     |              |              |              |                 |
- 8465     | 2010-08-14 08:35:40 | 2       | 0          |          |           |                     |              |              |              |                 |
- 8465     | 2010-08-14 08:35:40 | 3       | 0          |          |           |                     |              |              |              |                 |
- 8466     | 2010-08-14 08:35:40 | 0       | 0          | benchs   | guillaume | 2010-08-14 08:35:43 | 3            | 0            | 1            | 8473            | 1
- 8466     | 2010-08-14 08:35:40 | 1       | 0          |          |           |                     |              |              |              |                 |
- 8466     | 2010-08-14 08:35:40 | 2       | 0          |          |           |                     |              |              |              |                 |
- 8466     | 2010-08-14 08:35:40 | 3       | 0          |          |           |                     |              |              |              |                 |
- 8467     | 2010-08-14 08:35:40 | 0       | 0          |          |           |                     |              |              |              |                 |
- 8467     | 2010-08-14 08:35:40 | 1       | 0          |          |           |                     |              |              |              |                 |
- 8467     | 2010-08-14 08:35:40 | 2       | 0          |          |           |                     |              |              |              |                 |
- 8467     | 2010-08-14 08:35:40 | 3       | 0          |          |           |                     |              |              |              |                 |
- 8468     | 2010-08-14 08:35:40 | 0       | 0          |          |           |                     |              |              |              |                 |
- 8468     | 2010-08-14 08:35:40 | 1       | 0          |          |           |                     |              |              |              |                 |
- 8468     | 2010-08-14 08:35:40 | 2       | 0          |          |           |                     |              |              |              |                 |
- 8468     | 2010-08-14 08:35:40 | 3       | 0          |          |           |                     |              |              |              |                 |
- 8469     | 2010-08-14 08:35:40 | 0       | 0          |          |           |                     |              |              |              |                 |
- 8469     | 2010-08-14 08:35:40 | 1       | 0          |          |           |                     |              |              |              |                 |
- 8469     | 2010-08-14 08:35:40 | 2       | 0          |          |           |                     |              |              |              |                 |
- 8469     | 2010-08-14 08:35:40 | 3       | 0          |          |           |                     |              |              |              |                 |
-(20 lines)
-</pre>
-</p>
-
-<h2 id="pool_version">pool_version <span class="version">V3.0 -</span></h2>
-<p>"SHOW pool_version" displays a string containing the pgPool-II release
-number. Here is an example of it:
-<pre>
-benchs2=# show pool_version;
-      pool_version
-------------------------
- 3.0-dev (umiyameboshi)
-(1 line)
-</pre>
-
-<h2 id="pool_cache">pool_cache <span class="version">V3.0 -</span></h2>
-<p>"SHOW pool_cache" displays cache storage statistics if <a href="#memqcache">in memory query cache</a> is enabled.
-Here is an example of it:
-</p>
-
-<pre>
-test=# \x
-\x
-Expanded display is on.
-test=# show pool_cache;
-show pool_cache;
--[ RECORD 1 ]---------------+---------
-num_cache_hits              | 891703
-num_selects                 | 99995
-cache_hit_ratio             | 0.90
-num_hash_entries            | 131072
-used_hash_entries           | 99992
-num_cache_entries           | 99992
-used_cache_enrties_size     | 12482600
-free_cache_entries_size     | 54626264
-fragment_cache_entries_size | 0
-</pre>
-
-<ul>
-<li>num_cache_hits means the number of SELECTs which hit cache.</li>
-<li>num_selects  means the number of SELECTs which do not hit cache.</li>
-<li>
-cache_hit_ratio means cache hit ratio, calculated from num_cache_hits/(num_cache_hits+num_selects)
-Anything below num_hash_entries are valid only when cache storage is on shared memory.
-</li>
-<li>
-num_hash_entries means number of entries in hash table, which is used for index to cache storage
-and should be equal to <a href="#MEMQCACHE_MAX_NUM_CACHE">memqcache_max_num_cache</a> in pgpool.conf.
-This is the upper limit for number of cache entries.
-</li>
-<li>used_hash_entries means number of already used entries in num_hash_entries.</li>
-<li>
-num_cache_entries means number of valid cache entries in the cache storage and
-should be equal to used_hash_entries.
-</li>
-<li>used_cache_entries_size means total size of cache storage in bytes which is already used.</li>
-<li>free_cache_entries_size means total size of cache storage in bytes which is not used yet or can be usable.</li>
-<li>fragment_cache_entries_size means total size of cache storage in bytes which cannot be used because of fragmentation.</li>
-<li>The fragmented area can be reused later if free_cache_entries_size becomes 0 (or there's no enough space for the SELECT result).</li>
-</ul>
-
-<p class="top_link"><a href="#Top">back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1><a name="online-recovery"></a>Online Recovery</h1>
-<h2>Overview</h2>
-<p>
-pgpool-II, while in replication mode, can sync a database and attach a node
-while still servicing clients. We call this feature "online recovery".
-</p>
-
-<p>
-A recovery target node must be in the detached state before doing online
-recovery.
-
-If you wish to add a PostgreSQL server dynamically, add 'backend_hostname' and
-its associated parameters and reload pgpool.conf. pgpool-II registers this new
-node as a detached node.
-</p>
-
-<p>
-<font color="red">caution: Stop autovacuum on the master node (the
-first node which is up and running). Autovacuum may change the contents
-of the database and might cause inconsistency after online recovery if
-it's running. This applies only if you're recovering with a simple copy mechanism, such
-as the rsync one explained below. This doesn't apply if you're using PostgreSQL's
-PITR mechanism.</font>
-</p>
-
-<p>
-   If the target PostgreSQL server has already started, you need to shut it down.
-</p>
-
-<p>
-pgpool-II performs online recovery in two separated phases. There are a few
-seconds or minutes when client will be waiting to connect to pgpool-II while a
-recovery node synchronizes database. It follows these steps:
-</p>
-
-<ol>
-    <li> CHECKPOINT</li>
-    <li> First stage of online recovery</li>
-    <li> Wait until all clients have disconnected</li>
-    <li> CHECKPOINT</li>
-    <li> Second stage of online recovery</li>
-    <li> Start up postmaster (perform <a href="#pool_remote_start">pgpool_remote_start</a>)</li>
-    <li> Node attach</li>
-</ol>
-
-<p>
-The first step of data synchronization is called "first stage". Data is
-synchronized during the first stage. In the first stage, data <b>can</b> be
-updated or retrieved from any table concurrently.
-</p>
-
-<p>
-You can specify a script executed during the first stage. pgpool-II
-passes three arguments to the script.
-</p>
-
-<ol>
-    <li> The database cluster path of a master node.</li>
-    <li> The hostname of a recovery target node.</li>
-    <li> The database cluster path of a recovery target node.</li>
-</ol>
-
-<p>
-Data synchronization is finalized during what is called "second stage".
-Before entering the second stage, pgpool-II waits until all clients have disconnected.
-It blocks any new incoming connection until the second stage is over.
-</p>
-<p>
-After all connections have terminated, pgpool-II merges updated data between
-the first stage and the second stage. This is the final data
-synchronization step.
-</p>
-
-<p>
-<font color="red">
-Note that there is a restriction about online recovery. If pgpool-II itself
-is installed on multiple hosts, online recovery does not work correctly,
-because pgpool-II has to stop all clients during the 2nd stage of
-online recovery. If there are several pgpool hosts, only one will have received
-the online recovery command and will block connections.
-</font>
-</p>
-
-<h2 id="online_recovery_params">Configuration for online recovery</h2>
-<p>
-Set the following parameters for online recovery in pgpool.conf.
-</p>
-
-<ul>
-    <li><a href="#BACKEND_DATA_DIRECTORY">backend_data_directory</a></li>
-    <li><a href="#RECOVERY_USER">recovery_user</a></li>
-    <li><a href="#RECOVERY_PASSWORD">recovery_password</a></li>
-    <li><a href="#RECOVERY_1ST_STAGE_COMMAND">recovery_1st_stage_command</a></li>
-    <li><a href="#RECOVERY_2ND_STAGE_COMMAND">recovery_2nd_stage_command</a></li>
-</ul>
-
-
-<h2><a name="installing-c-functions"></a>Installing C language functions</h2>
-<p>
-You need to install the following C language function for online recovery into
-the "template1" database of all backend nodes.
-
-Its source code is in pgpool-II tarball.
-</p>
-
-<pre>
-pgpool-II-x.x.x/sql/pgpool-recovery/
-</pre>
-
-<p>
-Change directory there and do "make install".
-</p>
-
-<pre>
-% cd pgpool-II-x.x.x/sql/pgpool-recovery/
-% make install
-</pre>
-
-<p>
-Then, install the SQL function.
-</p>
-
-<pre>
-% cd pgpool-II-x.x.x/sql/pgpool-recovery/
-% psql -f pgpool-recovery.sql template1
-</pre>
-
-
-<h2 id="recovery_script">Recovery script deployment </h2>
-<p>
-We must deploy some data sync scripts and a remote start script into
-the database cluster directory ($PGDATA). Sample script files are available in
-pgpool-II-x.x.x/sample directory.
-</p>
-
-<h3 id="recovery_pitr">Online recovery by PITR</h3>
-<p>
-Here is how to do online recovery by Point In Time Recovery (PITR), which is
-available in PostgreSQL 8.2 and later versions.
-Note that all PostgreSQL servers involved need to have PITR enabled.
-</p>
-
-<h4>1st stage</h4>
-
-<p>
-A script to get a base backup on a master node and copy it to a
-recovery target node on the first stage is needed. The script can be named
-"copy-base-backup" for example. Here is the sample script.
-</p>
-
-<pre>
-#! /bin/sh
-DATA=$1
-RECOVERY_TARGET=$2
-RECOVERY_DATA=$3
-
-psql -c "select pg_start_backup('pgpool-recovery')" postgres
-echo "restore_command = 'scp $HOSTNAME:/data/archive_log/%f %p'" &gt; /data/recovery.conf
-tar -C /data -zcf pgsql.tar.gz pgsql
-psql -c 'select pg_stop_backup()' postgres
-scp pgsql.tar.gz $RECOVERY_TARGET:$RECOVERY_DATA
-</pre>
-
-<p>
-This script puts the master database in backup mode, generates the following recovery.conf:
-</p>
-<pre>
-restore_command = 'scp master:/data/archive_log/%f %p'
-</pre>
-
-<p>
-performs the backup, then puts the master database out of backup mode and copies
-the backup on the chosen target node.
-</p>
-
-<h4>2nd stage</h4>
-
-<p>
-The second stage of the procedure is a script to force an XLOG file switch.
-This script is named "pgpool_recovery_pitr" here.
-It enforces a switch of the transaction log.
-For this purpose, pg_switch_xlog could be used.
-</p>
-<p><span class="version">V3.1 -</span>
-However it may return <b>before</b> the switch is done and this might lead to
-failure of the online recovery procedure.
-Pgpool-II provides a safer function called "pgpool_switch_xlog" which will wait
-until the transaction log switching is actually finished.
-pgpool_switch_xlog is installed during the procedure performed in the
-<a href="#installing-c-functions">Installing C functions</a> section.
-</p>
-
-<p>
-Here is the sample script.
-</p>
-<pre>
-#! /bin/sh
-# Online recovery 2nd stage script
-#
-datadir=$1       # master dabatase cluster
-DEST=$2          # hostname of the DB node to be recovered
-DESTDIR=$3       # database cluster of the DB node to be recovered
-port=5432        # PostgreSQL port number
-archdir=/data/archive_log    # archive log directory
-
-# Force to flush current value of sequences to xlog
-psql -p $port -t -c 'SELECT datname FROM pg_database WHERE NOT datistemplate AND datallowconn' template1|
-while read i
-do
-  if [ "$i" != "" ];then
-    psql -p $port -c "SELECT setval(oid, nextval(oid)) FROM pg_class WHERE relkind = 'S'" $i
-  fi
-done
-
-psql -p $port -c "SELECT pgpool_switch_xlog('$archdir')" template1
-</pre>
-</p>
-
-<p>
-This flushing of sequences is only useful in replication mode: in this case, sequences have to have the
-same starting point on all nodes. It's not useful in master-slave mode.
-</p>
-<p>
-The loop in the script forces PostgreSQL to emit current value of all sequences
-in all databases in the master node to the transaction log so that it is
-propagated to the recovery target node.
-
-<p>
-We deploy these scripts into the $PGDATA directory.
-</p>
-<p>
-Finally, we edit pgpool.conf.
-</p>
-
-<pre>
-recovery_1st_stage_command = 'copy-base-backup'
-recovery_2nd_stage_command = 'pgpool_recovery_pitr'
-</pre>
-
-<p>
-We have finished preparing online recovery by PITR.
-</p>
-
-<h4 id="pool_remote_start">pgpool_remote_start</h4>
-<p>
-This script starts up the remote host's postmaster process.
-pgpool-II executes it the following way.
-</p>
-
-<pre>
-% pgpool_remote_start remote_host remote_datadir
-remote_host:    Hostname of a recovery target.
-remote_datadir: Database cluster path of a recovery target.
-</pre>
-
-<p>
-In this sample script, we start up the postmaster process over ssh.
-So you need to be able to connect over ssh without a password for it to work.
-</p>
-
-<p>
-If you recover with PITR, you need to deploy a base backup. PostgreSQL will
-automatically start up doing a PITR recovery. Then it will accept connections.
-</p>
-
-<pre>
-#! /bin/sh
-DEST=$1
-DESTDIR=$2
-PGCTL=/usr/local/pgsql/bin/pg_ctl
-
-# Deploy a base backup
-ssh -T $DEST 'cd /data/; tar zxf pgsql.tar.gz' 2&gt;/dev/null 1&gt;/dev/null &lt; /dev/null
-# Startup PostgreSQL server
-ssh -T $DEST $PGCTL -w -D $DESTDIR start 2&gt;/dev/null 1&gt;/dev/null &lt; /dev/null &amp;
-</pre>
-
-<h3 id="recovery_rsync">Online recovery with rsync.</h3>
-<p>
-PostgreSQL 7.4 does not have PITR.
-PostgreSQL 8.0 and 8.1 cannot force to switch transaction log.
-So rsync can be used to do online recovery.
-In the "sample" directory of pgpool-II's tarball,
-there is a recovery script named "pgpool_recovery". It uses the rsync
-command. pgpool-II calls the script with three arguments.
-</p>
-
-<pre>
-% pgpool_recovery datadir remote_host remote_datadir
-datadir:        Database cluster path of a master node.
-remote_host:    Hostname of a recovery target node.
-remote_datadir: Database cluster path of a recovery target node.
-</pre>
-
-<p>
-This script copies physical files with rsync over ssh. So you need to
-be able to connect over ssh without a password.
-</p>
-
-<p>
-Note about rsync:
-<ul>
-    <li>-c (or --checksum) option is required to enable reliable file tranmitting
-    </li>
-    <li>-z (or --compress) option does compression before transmitting data.
-        This will be great for slower connection, but it might add too much
-        CPU overhead for a 100Mbit or faster connections. In this case you
-        might want not to use this option.
-    </li>
-    <li>rsync 3.0.5 has great speed performance
-        improvements (50% faster according to a report from pgpool-general mailing list.
-    </li>
-</ul>
-
-</p>
-
-<p>
-If you use pgpool_recovery, add the following lines into pgpool.conf.
-</p>
-
-<pre>
-recovery_1st_stage_command = 'pgpool_recovery'
-recovery_2nd_stage_command = 'pgpool_recovery'
-</pre>
-
-<h2 id="perform_online_recovery">How to perform online recovery</h2>
-<p>
-In order to do online recovery, use the <a href="pcp_recovery_node">pcp_recovery_node</a> command or
-pgpoolAdmin.
-</p>
-
-<p>
-Note that you need to pass a large number to the first argument of
-<a href="#pcp_recovery_node">pcp_recovery_node</a>. It is the timeout parameter in seconds. If you use
-pgpoolAdmin, set "_PGPOOL2_PCP_TIMEOUT " parameter to a large number in
-pgmgt.conf.php.
-</p>
-
-<h2 id="minorup_w_online_recovery">PostgreSQL version up using online recovery</h2>
-<h3>replication mode case</h3>
-<p>
-You can update PostgreSQL on each node without stopping pgpool-II if pgpool-II operated in replication mode.
-Please note that active sessions from clients to pgpool-II will be disconnected
-while disconnecting and attaching DB nodes.
-Also please note that you cannot do major version up in the method described below
-(i.e. the version up should not require dump/restore).
-</p>
-
-<p>
-<ol>
-    <li><p>
-    Prepare online recovery.</p>
-    </li>
-
-    <li><p>Version up should perform nodes which are not master node first.
-        Stop PostgreSQL on a non-master node.
-        Pgpool-II will detect PostgreSQL termination and degenerate emitting logs below.
-        At this point all sessions connected to pgpool-II disconnected.
-        </p>
-<pre>
-2010-07-27 16:32:29 LOG:   pid 10215: set 1 th backend down status
-2010-07-27 16:32:29 LOG:   pid 10215: starting degeneration. shutdown host localhost(5433)
-2010-07-27 16:32:29 LOG:   pid 10215: failover_handler: set new master node: 0
-2010-07-27 16:32:29 LOG:   pid 10215: failover done. shutdown host localhost(5433)
-</pre>
-    </li>
-
-    <li><p>
-    Version up PostgreSQL on the stopping node.
-    You can overwrite old PostgreSQL, we recommend move old PostgreSQL somewhere
-    so that you could recover it just in case however.
-    </p>
-    </li>
-
-    <li><p>
-    If you install new PostgreSQL in different location from the old one and
-    do not want to update your recovery script,
-    you need to match the path by using tools including symbolic link.
-    If you choose to overwrite, you can skip following steps till installation of C function step.
-    You can execute online recovery immediately.
-    </p>
-    </li>
-
-    <li><p>
-    Change installation directory of old PostgreSQL.
-    Installting directory of PostgreSQL is supposed to be /usr/local/pgsql in following description.
-    </p>
-<pre>
-$ mv /usr/local/pgsql /usr/local/pgsql-old
-</pre>
-    </li>
-
-    <li><p>
-    Create a symbolic link to the location where newer version of PostgreSQL installed.
-    This allow you to continue to use command search path you currently use.
-    Installing directory of newer PostgreSQL is supposed to be /usr/local/pgsql-new in following description.
-    </p>
-<pre>
-$ ln -s /usr/local/pgsql-new /usr/local/pgsql
-</pre>
-    </li>
-
-    <li><p>
-    If database directory is located under older PostgreSQL installation directory,
-    you should create or copy so that newer PostgreSQL can access it.
-    We use symbolic link in the following example.
-    </p>
-<pre>
-$ ln -s /usr/local/pgsql-old/data /usr/local/pgsql/data
-</pre>
-    </li>
-
-    <li><p>
-    Install C functions into PostgreSQL. "Installing C functions" section may help you.
-    Because online recovery copies database cluster, the last step installing functions
-    using psql is not necessary.
-    Do make install.
-    </p>
-    </li>
-
-    <li><p>
-    Do online recovery. You are done with one node version up.
-    To execute online recovery, you can use <a href="#pcp_recovery_node">pcp_recovery_node</a> or pgpoolAdmin.
-    </p>
-    </li>
-
-    <li><p>
-    Repeat steps above on each node. In the very last master node should be updated.
-    You are done.
-    </p>
-    </li>
-</ol>
-
-<h3>If you are using streaming replication</h3>
-<p>
-You can update standby PostgreSQL server without stopping pgpool-II.
-</p>
-
-<p>
-The procedure to update standby PostgreSQL servers are same as the one of replication mode.
-Please refer to "Online recovery with Streaming Replication" to set up recovery_1st_stage_command and recovery_2nd_stage_command.
-</p>
-
-<p>
-You cannot version up primary server without stopping pgpool-II.
-You need to stop pgpool-II while updating primary server.
-The procedure to update primary PostgreSQL server is same as the one standby server.
-The procedure to update primary PostgreSQL server is as follows:
-</p>
-<ol>
-    <li>Stop pgpool-II</li>
-    <li>Stop primary PostgreSQL</li>
-    <li>Update primary PostgreSQL</li>
-    <li>Start primary PostgreSQL</li>
-    <li>Start pgpool-II</li>
-</ol>
-
-<p class="top_link"><a href="#Top">back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1><a name="backup"></a>Backup</h1>
-<p>
-To back up backend PostgreSQL servers, you can use physical
-backup, logical backup (pg_dump, pg_dumpall) and PITR in the same manner as PostgreSQL.
-Please note that using logical backup and PITR should be performed directory with PostgreSQL,
-rather than via pgpool-II to avoid errors caused by <a href="#LOAD_BALANCE_MODE">load_balance_mode</a> and
-<a href="#REPLICATE_SELECT">replicate_select</a>.
-</p>
-
-<h2 id="backup_rep_or_ms_mode">replication mode and master/slave mode</h2>
-<p>
-If pgpool-II is operated in replication mode or master/slave mode, take a backup on one DB nodes in the cluster.
-</p>
-
-<p>
-If you are using master/slave mode and asynchronous replication
-systems(Slony-I and streaming replication) and need the latest backup,
-you should take a backup on the master node.
-</p>
-
-<p>
-pg_dump takes ACCESS SHARE lock on database. Commands taking ACCESS
-EXECUTE lock, such as ALTER TABLE, DROP TABLE, TRUNCATE, REINDEX,
-CLUSTER and VACUUM FULL will wait for the completion of pg_dump because
-of lock conflict. Also this may affect the primary node even if you are
-doing pg_dump on standby.
-</p>
-
-<p class="top_link"><a href="#Top">back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1><a name="deploy"></a>Deploying pgpool-II</a></h1>
-<p>
-pgpool-II can run on a dedicated server, on the server where application
-server is running on or other servers.  In this section we discuss how
-to make those deployments and pros and cons.
-</p>
-
-<p>
-<dl>
-<dt>Dedicated server</dt>
-    <dd>
-    <p>
-    Pgpool-II is running on a dedicated server.
-    It's simple and pgpool-II is not affected by other server softwares.
-    Obvious cons is you need to buy more hardware.
-    Also pgpool-II can be a single point of failure with this configuration
-    (you can avoid this by enabling <a href="#watchdog">watchdog</a> or using pgpool-HA described described below).
-    </p>
-    </dd>
-
-<dt>Deploying on a web server or application server</dt>
-    <dd>
-    <p>
-    Deploying pgpool-II on a server where Apache, JBoss, Tomcat or other web
-    server and application servers.
-    Since communication between pgpool-II and web servers and application servers
-    is within a local machine, socket communication can be faster than inter-sever communication.
-    Also if you are using multiple web serves or application servers, you can avoid
-    the single point of failure problem
-    (in this case you must have identical pgpool.conf on each pgpool-II instance except the <a href="#watchdog">watchdog section</a>).
-		</p>
-		<p>
-		We strongly recommend to enable <a href="#watchdog">watchdog</a> to avoid following concerns in this configuration.
-    </p>
-    <ul>
-        <li>If the communication between pgpool-II and DB servers is not stable, it is possible
-            that DB node #1 is down from a point of a pgpool-II instance,
-            while it is up from other pgpool-II instance's point of view.
-            To avoid this, you can multiplex the network connection.
-        </li>
-        <li>While executing online recovery in replication mode,
-            you need to stop all pgpool-II instances except the one which is doing online recovery.
-            Otherwise DB can be running into inconsistent state.
-            In master slave mode+streaming replication mode, you do not need to stop other pgpool-II instances.
-            You should not execute online recovery at the same time on multiple pgpool-II instances however.
-        </li>
-    </ul>
-    </dd>
-
-<dt>Running pgpool-II on DB server</dt>
-    <dd>
-    <p>
-    Running pgpool-II on the server as PostgreSQL is running on.
-    You can avoid the single point of failure problem of pgpool-II with configuration.
-    And obviously you do need to buy additional dedicated server.
-    Problem with this configuration is, application need to aware of which DB server they should connect to.
-    To solve the problem you can use virtual IP with <a href="#watchdog">watchdog</a> or pgpool-HA.
-    </p>
-    </dd>
-</dl>
-
-<h2 id="pgpool_ha">About pgpool-HA</h2>
-<p>
-Pgpool-HA is a high availability software for pgpool-II using heartbeat.
-Pgpool-HA is a sub-project of the pgpool project as well as pgpool-II.
-Pgpool-HA can be available from the pgpool development site as an open source software.
-</p>
-
-<p class="top_link"><a href="#Top">back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1 id="watchdog">Watchdog <span class="version">V3.2 -</span></h1>
-<h2 id="what_is_watchdog">What is watchdog</h2>
-
-<p>
-    "Watchdog" is a sub process of pgpool-II, which adds high availability.
-	This resolves the single point of failure by coordinating multiple pgpool-IIs.
-	The watchdog system in pgpool-II <span class="version">V3.5 -</span> is significantly enhanced
-	and it now ensures the presence of a quorum at all time.
-	This new addition to watchdog makes it more fault tolerant and robust in handling
-	and guarding against the split-brain syndrome and network partitioning.
-    However to ensure the quorum mechanism properly work, the number of pgpool-II nodes must be greater than or equal to 3 or more and the number must be odd.
-	Watchdog consists of the following features.
-</p>
-<h3>Life checking of pgpool-II</h3>
-    <p>
-    Watchdog lifecheck is the sub-component of watchdog to monitor the health of pgpool-II
-	nodes participating in the watchdog cluster to provide the high availability.
-	Traditionally pgpool-II watchdog provides two methods of remote node health checking.
-	"heartbeat" and "query" mode. The watchdog in pgpool-II  <span class="version">V3.5 -</span> adds a new "external"
-	health checking method, which enables to hook an external third party health checking system with pgpool-II watchdog.
-	See the section <a href="#INTEGRATE_EXT_LIFECHECK">integrating external lifecheck with watchdog </a> for details on how
-	to hook a third party system with watchdog. Apart from remote node health checking
-	watchdog lifecheck can also check the health of node it is installed on by monitoring the connection to upstream servers.
-    </p>
-    <ul>
-    <li>
-    In heartbeat mode, watchdog monitors other pgpool-II processes by using heartbeat signal.
-    Watchdog receives heartbeat signals sent by other pgpool-II periodically.
-    If there are no signal for a certain period, watchdog regards this as failure of the pgpool-II.
-    For redundancy you can use multiple network connections for heartbeat exchange between pgpool-IIs.
-    This is the default mode and recommended.
-    </li>
-    <li>
-    In query mode, watchdog monitors pgpool-II's service rather than process.
-    watchdog sends queries to other pgpool-II and checks the response.
-    Note that this method requires connections from other pgpool-IIs, so it would fail monitoring if
-    <a href="#NUM_INIT_CHILDREN">num_init_children </a>isn't large enough.
-    This mode is deprecated and left for backward compatibility.
-    </li>
-	<li>
-	"external"<span class="version">V3.5 -</span> mode basically disables the built in lifecheck of pgpool-II watchdog and expects the
-	external system will inform the watchdog about health of local and all remote nodes
-	participating in the watchdog cluster.
-	</li>
-    </ul>
-    <p>
-    Also watchdog monitors connections to upstream servers
-    (application servers etc.) from the pgpool-II, and checks whether the pgpool-II can serves to the servers.
-    If the monitoring fails, watchdog treats the pgpool-II as down.
-    </p>
-
-<h3>Coordinating multiple pgpool-IIs</h3>
-    <p>
-    Watchdog coordinates multiple pgpool-IIs by exchanging information with each other.
-    </p>
-    <ul>
-    <li>
-    When backend node status changes by failover etc., watchdog notifies the information to other pgpool-IIs and synchronizes them.
-    When online recovery occurs, watchdog restricts client connections to other pgpool-IIs for avoiding inconsistency between backends.
-    </li>
-    <li>
-    Commands on failback or failover (<a href="#FAILOVER_COMMAND">failover_command</a>,
-    <a href="#FAILBACK_COMMAND">failback_command</a>, <a href="#FOLLOW_MASTER_COMMAND">follow_master_command</a>)
-    are executed by only one pgpool-II by interlocking.
-    </li>
-    </ul>
-	<h3> <span class="version">V3.5 -</span>Verifies the consistency of important configuration parameters of all nodes</h3>
-
-	<p>
-	At start up watchdog verifies the pgpool-II configuration of the local node for the consistency with
-	the configurations on the master watchdog node.
-	This eliminates the likelihood of undesired behavior that can happen because of
-	different configuration on different pgpool-II nodes.
-	</p>
-<h3>Changing active/standby state in case of certain faults detected</h3>
-    <p>
-    When a fault of pgpool-II is detected, watchdog notifies the other watchdogs of it.
-    If this is the active pgpool-II, watchdogs decides the new active pgpool-II by voting and change active/standby state.
-    </p>
-
-<h3>Automatic virtual IP address assigning synchronous to server switching</h3>
-    <p>
-    When a standby pgpool-II server promotes to active, the new active server brings up virtual IP interface.
-    Meanwhile, the previous active server brings down the virtual IP interface.
-    This enables the active pgpool-II to work using the same IP address even when servers are switched.
-    </p>
-
-<h3>Automatic registration of a server as standby in recovery</h3>
-    <p>
-    When broken server recovers or new server is attached,
-    the watchdog process notifies the other watchdog process along with information of the new server,
-    and the watchdog process receives information on the active server and other servers.
-    Then, the attached server is registered as a standby.
-    </p>
-</dl>
-
-<h2 id="watchdog_server_composition">Server composition</h2>
-
-<p>
-Figure below describes how pgpool-II and watchdog process is configured.
-</p>
-<p><img src="wd-en.jpg" alt="watchdog server composition" hight=70% width=70%></p>
-
-<h2 id="start_watchdog">Starting/stopping watchdog</h2>
-<p>
-Watchdog process starts/stops automatically as sub-processes of pgpool-II,
-therefore there is no dedicated command to start/stop it.
-</p>
-<p>
-Watchdog requires <font color="red">root privilege</font> for controling the virtual IP interface.
-One method is to start pgpool-II by root privilege.
-However, for security reason, to set custom commands to <a href="#IF_UP_CMD">if_up_cmd</a>,
-<a href="#IF_DOWN_CMD">if_down_cmd</a>, <a href="#ARPING_CMD">arping_cmd</a> using sudo or setuid is recommended method.
-</p>
-<p>
-Watchdog's built-in life-checking starts after all of the pgpool-IIs has started.
-This doesn't start if not all "other" nodes are alive
-Until this, failover of the virtual IP never occurs.
-</p>
-
-<h2>Configuring watchdog (pgpool.conf)</h2>
-<p>
-Watchdog configuration parameters are described in pgpool.conf.
-There is sample configuration in WATCHDOG section in pgpool.conf.sample file.
-</p>
-
-<p>
-All following options are required to be specified in watchdog process.
-</p>
-
-<h3>Enabling</h3>
-<dl>
-<dt><a name="USE_WATCHDOG"></a>use_watchdog <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    If on, activates watchdog. Default is off.
-    </p>
-    <p>
-    You need to restart pgpool-II if you change this value.
-    </p>
-    </dd>
-</dl>
-
-<h3>Watchdog communication</h3>
-<dl>
-<dt><a name="WD_HOSTNAME"></a>wd_hostname <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    Specifies the hostname or IP address of pgpool-II server.
-    This is used for sending/receiving queries and packets, and also as identifier of watchdog.
-    </p>
-    <p>
-    You need to restart pgpool-II if you change this value.
-    </p>
-    </dd>
-
-<dt><a name="WD_PORT"></a>wd_port <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    Specifies the port number for watchdog communication.
-    </p>
-    <p>
-    You need to restart pgpool-II if you change this value.
-    </p>
-    </dd>
-
-<dt><a name="WD_AUTHKEY"></a>wd_authkey <span class="version">V3.3 -</span></dt>
-    <dd>
-    <p>
-    This option specifies the authentication key used in watchdog communication.
-    All the pgpool-II must have the same key.
-    Packets from watchdog of wrong key will be rejects.
-    This authentication is applied also for heatrbeat singals if lifecheck method is heartbeat mode.
-	</p><p>
-	Since pgpool-II <span class="version">V3.5 -</span> wd_authkey is also used to authenticate the watchdog IPC clients.
-	All clients communicating with pgpool-II watchdog process needs to provide this
-	wd_authkey value for "IPCAuthKey" key in the JSON data of the command.
-	</p><p>
-    If this is empty (default), watchdog IPC and watchdog cluster authentication is disabled.
-    </p>
-    <p>
-    You need to restart pgpool-II if you change this value.
-    </p>
-    </dd>
-</dl>
-
-<h3>Connection to up stream servers</h3>
-
-<dl>
-<dt><a name="TRUSTED_SERVERS"></a>trusted_servers <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    The list of trusted servers to check the up stream connections.
-    Each server is required to respond to ping.
-    Specify a comma separated list of servers such as "hostA,hostB,hostC".
-    If none of the server are pingable, watchdog regards it as failure of the pgpool-II.
-    Therefore, it is recommended to specify multiple servers.
-    </p>
-    <p>
-    If this option is empty, watchdog doesn't check up stream connections.
-    </p>
-    <p>
-    You need to restart pgpool-II if you change this value.
-    </p>
-    </dd>
-
-<dt><a name="PING_PATH"></a>ping_path <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    This parameter specifies a path of ping command for monitoring connection
-    to the upper servers.
-    Set the only path such as "/bin".
-    </p>
-    <p>
-    You need to restart pgpool-II if you change this value.
-    </p>
-    </dd>
-</dl>
-
-<h3>Virtual IP control</h3>
-
-<p>
-Configuration about virtual IP interface control
-</p>
-
-<dl>
-<dt><a name="DELEGATE_IP"></a>delegate_IP <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    Specifies the virtual IP address (VIP) of pgpool-II that is connected from
-    client servers (application servers etc.).
-    When a pgpool-II is switched from standby to active, the pgpool-II takes over this VIP.
-    If this option is emply, virtual IP is never brought up.
-    </p>
-    <p>
-    You need to restart pgpool-II if you change this value.
-    </p>
-    </dd>
-
-<dt><a name="IF_CMD_PATH"></a>if_cmd_path <span class="version">V3.5 -</span></dt>
-    <dd>
-    <p>
-    This parameter specifies a path of a command to switch the IP address.
-    Set the only path such as "/sbin".
-    </p>
-    <p>
-    You need to restart pgpool-II if you change this value.
-    </p>
-    </dd>
-
-<dt><a name="IF_UP_CMD"></a>if_up_cmd <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    This parameter specifies a command to bring up the virtual IP.
-    Set the command and parameters such as
-    "ip addr add $_IP_$/24 dev eth0 label eth0:0"
-    $_IP_$ is replaced by the IP address specified in <a href="#DELEGATE_IP">delegate_IP</a>.
-    </p>
-    <p>
-    You need to restart pgpool-II if you change this value.
-    </p>
-    </dd>
-
-<dt><a name="IF_DOWN_CMD"></a>if_down_cmd <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    This parameter specifies a command to bring down the virtual IP.
-    Set the command and parameters such as
-    "ip addr del $_IP_$/24 dev eth0"
-    </p>
-    <p>
-    You need to restart pgpool-II if you change this value.
-    </p>
-    </dd>
-
-<dt><a name="ARPING_PATH"></a>arping_path <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    This parameter specifies a path of a command to send an ARP request
-    after the virtual IP is switched.
-    Set the only path such as "/usr/sbin".
-    </p>
-    <p>
-    You need to restart pgpool-II if you change this value.
-    </p>
-    </dd>
-
-<dt><a name="ARPING_CMD"></a>arping_cmd <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    This parameter specifies a command to send an ARP request
-    after the virtual IP is switched.
-    Set the command and parameters such as
-    "arping -U $_IP_$ -w 1".
-    $_IP_$ is replaced by the IP address specified in <a href="#DELEGATE_IP">delegate_IP</a>.
-    </p>
-    <p>
-    You need to restart pgpool-II if you change this value.
-    </p>
-    </dd>
-</dl>
-
-<h3>Behaivor on escalation and de-escalation</h3>
-
-<p> Configuration about behavior when pgpool-II escalates to active (virtual IP holder)
-
-<dl>
-<dt><a name="CLEAR_MEMQCACHE_ON_ESCALATION"></a>clear_memqcache_on_escalation <span class="version">V3.3 -</span></dt>
-    <dd>
-    <p>
-    If this is on, watchdog clears all the query cache in the shared memory when pgpool-II escaltes to active.
-    This prevents the new active pgpool-II from using old query caches inconsistence to the old active.
-    Default is on.
-    </p>
-    <p>
-    This works only if <a href="#MEMQCACHE_METHOD">memqcache_method</a> is 'shmem'.
-    </p>
-    </dd>
-
-<dt><a name="WD_ESCALATION_COMMAND"></a>wd_escalation_command <span class="version">V3.3 -</span></dt>
-    <dd>
-    <p>
-    Watchdog executes this command on the node that is escalated to the master watchdog.
-	<p>
-    This command is executed just before bringing up the virtual/floating IP if that is configured on the node.
-	</p>
-	</p>
-    </dd>
-	<dt><a name="WD_DE-ESCALATION_COMMAND"></a>wd_de_escalation_command <span class="version">V3.5 -</span></dt>
-	<dd>
-		<p>
-		Watchdog executes this command on the master pgpool-II watchdog node when that node resigns
-		from the master node responsibilities. A master watchdog node can resign from
-		being a master node, when the master node pgpool-II shuts down, detects a network blackout
-		or detects the lost of quorum.
-		</p>
-		<p>
-		This command is executed before bringing down the virtual/floating IP address if it is configured on the watchdog node
-		</p>
-	</dd>
-</dl>
-
-<h3>Life checking pgpool-II</h3>
-
-<p>Watchdog checks pgpool-II status periodically. This is called "life check".
-
-<h4>Common</h4>
-
-<dl>
-<dt><a name="WD_LIFECHECK_METHOD"></a>wd_lifecheck_method <span class="version">V3.3 -</span></dt>
-    <dd>
-    <p>
-    This parameter specifies the method of life check. This can be either of 'heartbeat' (default), 'query' or 'external'.
-    </p>
-    <p>
-    In 'heartbeat' mode, watchdog sends heartbeat singals (UDP packets) periodically to other pgpool-II.
-    Watchdog also receives the signals from other pgpool-II.
-    If there are no signal for a certain period, watchdog regards is as failure of the pgpool-II.
-    </p>
-    <p>
-    In 'query' mode, watchdog sends monitoring queries to other pgpool-II and checks the response.
-    </p>
-    <p>
-    <font color="red">CAUTION: In query mode, you need to set <a href="#NUM_INIT_CHILDREN">num_init_children</a>
-    large enough if you plan to use watchdog. This is because the watchdog process connects to pgpool-II as a client.</font>
-    </p>
-
-	<p>
-	The 'external' mode (<span class="version">V3.5 -</span>), disables the built in lifecheck of pgpool-II watchdog
-	and relies on external system to provide node health checking of local and remote watchdog nodes.
-	</p>
-
-	<p>
-    You need to restart pgpool-II if you change this value.
-    </p>
-    </dd>
-
-<dt><a name="WD_MONITORING_INTERFACES_LIST"></a>wd_monitoring_interfaces_list <span class="version">V3.5 -</span></dt>
-<dd>
-	<p>
-	Specify a comma separated list of network device names, to be monitored by the watchdog process
-	for the network link state. If all network interfaces in the list become inactive
-	(disabled or cable unplugged), the watchdog will consider it as a complete network
-	failure and the pgpool-II node will commit the suicide.
-	Specifying an empty '' list disables the network interface monitoring.
-	Setting it to 'any' enables the monitoring on all available network interfaces except the loopback.
-	Default is '' empty list (monitoring disabled).
-	</p>
-	<p>
-	You need to restart pgpool-II if you change this value.
-	</p>
-</dd>
-
-
-<dt><a name="WD_INTERVAL"></a>wd_interval <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    This parameter specifies the interval between life checks of pgpool-II
-    in second.
-    (A number greater than or equal to 1)
-    Default is 10.
-    </p>
-    <p>
-    You need to restart pgpool-II if you change this value.
-    </p>
-    </dd>
-
-<dt><a name="WD_PRIORITY"></a>wd_priority <span class="version">V3.5 -</span></dt>
-<dd>
-	<p>
-	This parameter can be used to
-	elevate the local watchdog node priority in the elections to select master watchdog node.
-	The node with the higher wd_priority value will get selected as master
-	watchdog node when cluster will be electing its master node at cluster startup or in the event of old master watchdog node failure	</p>
-	<p>
-	You need to restart pgpool-II if you change this value.
-	</p>
-</dd>
-
-<dt><a name="WD_IPC_SOCKET_DIR"></a>wd_ipc_socket_dir <span class="version">V3.5 -</span></dt>
-<dd>
-	<p>The directory where the UNIX domain socket accepting pgpool-II watchdog IPC
-	connections will be created. Default is <code>'/tmp'</code>. Be
-	aware that this socket might be deleted by a cron job. We recommend to
-	set this value to <code>'/var/run'</code> or such directory.
-	</p>
-	<p>
-	This parameter can only be set at server start.</p>
-</dd>
-</dl>
-
-<h4>Configuration of heartbeat mode</h4>
-
-<dl>
-<dt><a name="WD_HEARTBEAT_PORT"></a>wd_heartbeat_port <span class="version">V3.3 -</span></dt>
-    <dd>
-    <p>
-    This option specifies the port number to receive heartbeat signals.
-    Default is 9694.
-    This works only heartbeat mode.
-    </p>
-    <p>
-    You need to restart pgpool-II if you change this value.
-    </p>
-    </dd>
-
-<dt><a name="WD_HEARTBEAT_KEEPALIVE"></a>wd_heartbeat_keepalive <span class="version">V3.3 -</span></dt>
-    <dd>
-    <p>
-    This option specifies the interval time (sec.) of sending heartbeat signals.
-    Default is 2.
-    This works only heartbeat mode.
-    </p>
-    <p>
-    You need to restart pgpool-II if you change this value.
-    </p>
-    </dd>
-
-<dt><a name="WD_HEARTBEAT_DEADTIME"></a>wd_heartbeat_deadtime <span class="version">V3.3 -</span></dt>
-    <dd>
-    <p>
-    If there are no heartbeat signal for the period specified by this option, watchdog regards it as failure of the remote pgpool-II.
-    Default is 30.
-    This works only heartbeat mode.
-    </p>
-    <p>
-    You need to restart pgpool-II if you change this value.
-    </p>
-    </dd>
-
-<dt><a name="HEARTBEAT_DESTINATION"></a>heartbeat_destination<font color="red">0</font> <span class="version">V3.3 -</span></dt>
-    <dd>
-    <p>
-    This option specifies the destination of heartbeat signals by IP address or hostname.
-    You can use multiple destination.
-    The number at the end of the parameter name is referred as "destination number",
-    and it starts from 0.
-    This works only heartbeat mode.
-    </p>
-    <p>
-    You need to restart pgpool-II if you change this value.
-    </p>
-    </dd>
-
-<dt><a name="HEARTBEAT_DESTINATION_PORT"></a>heartbeat_destination_port<font color="red">0</font> <span class="version">V3.3 -</span></dt>
-    <dd>
-    <p>
-    This option specifies the port number of destination of heartbeat signals
-    which is specified by <a href="HEARTBEAT_DESTINATION">heartbeat_destinationX</a>.
-    This is usually the same value as <a href="WD_HEARTBEAT_PORT">wd_heartbeat_port</a>
-    You must use another value if the port number is unusable on a certain host or
-    there are more than two pgpool-IIs in a host.
-    The number at the end of the parameter name is referred as "destination number",
-    and it starts from 0.
-    This works only heartbeat mode.
-    </p>
-    <p>
-    You need to restart pgpool-II if you change this value.
-    </p>
-    </dd>
-
-<dt><a name="HEARTBEAT_DEVICE"></a>heartbeat_device<font color="red">0</font> <span class="version">V3.3 -</span></dt>
-    <dd>
-    <p>
-    This option specifies the network device name for sending heartbeat signals to
-    destination specified by <a href="HEARTBEAT_DESTINATION">heartbeat_destinationX</a>.
-    You can use the same device for different distinations.
-    The number at the end of the parameter name is referred as "destination number",
-    and it starts from 0.
-    This works only heartbeat mode. This is ignored when the value is empty.
-    In addition, this works only when pgpool-II has root privilege and are running on Linux,
-    because this uses SO_BINDTODEVICE socket option.
-    </p>
-    <p>
-    You need to restart pgpool-II if you change this value.
-    </p>
-    </dd>
-</dl>
-
-<h4>Configuration of query mode</h4>
-
-<dl>
-<dt><a name="WD_LIFE_POINT"></a>wd_life_point <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    The times to retry a failed life check of pgpool-II.
-    (A number greater than or equal to 1)
-    Default is 3.
-    This works only query mode.
-    </p>
-    <p>
-    You need to restart pgpool-II if you change this value.
-    </p>
-    </dd>
-
-<dt><a name="WD_LIFECHECK_QUERY"></a>wd_lifecheck_query <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    Actual query to check pgpool-II.
-    Default is "SELECT 1".
-    This works only query mode.
-    </p>
-    <p>
-    You need to restart pgpool-II if you change this value.
-    </p>
-    </dd>
-
-<dt><a name="WD_LIFECHECK_DBNAME"></a>wd_lifecheck_dbname <span class="version">V3.3 -</span></dt>
-    <dd>
-    <p>
-    The database name connected for checking pgpool-II.
-    Default is "template1".
-    This works only query mode.
-    </p>
-    </dd>
-
-<dt><a name="WD_LIFECHECK_USER"></a>wd_lifecheck_user <span class="version">V3.3 -</span></dt>
-    <dd>
-    <p>
-    The user name to check pgpool-II.
-    This user must exist in all the PostgreSQL backends.
-    Default is "nobody".
-    This works only query mode.
-    </p>
-    </dd>
-
-<dt><a name="WD_LIFECHECK_PASSWORD"></a>wd_lifecheck_password <span class="version">V3.3 -</span></dt>
-    <dd>
-    <p>
-    The password of the user to check pgpool-II.
-    Default is "".
-    This works only query mode.
-    </p>
-    </dd>
-</dl>
-
-<h3>Servers to monitor</h3>
-<dl>
-<dt><a name="OTHER_PGPOOL_HOSTNAME"></a>other_pgpool_hostname<font color="red">0</font>
-    <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    Specifies the hostname pgpool-II server to be monitored.
-    This is used for sending/receiving queries and packets, and also as identifier of watchdog.
-    The number at the end of the parameter name is referred as "server id",
-    and it starts from 0.
-    </p>
-    <p>
-    You need to restart pgpool-II if you change this value.
-    </p>
-    </dd>
-
-<dt><a name="OTHER_PGPOOL_PORT"></a>other_pgpool_port<font color="red">0</font>
-    <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    Specifies the port number for pgpool service of pgpool-II server to be monitored.
-    In query mode, the queries specified in <a href="#WD_LIFECHECK_QUERY">wd_lifecheck_query</a> is sent to this port.
-    The number at the end of the parameter name is referred as "server id",
-    and it starts from 0.
-    </p>
-    <p>
-    You need to restart pgpool-II if you change this value.
-    </p>
-    </dd>
-
-<dt><a name="OTHER_WD_PORT"></a>other_wd_port<font color="red">0</font> <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    Specifies the port number for watchdog on pgpool-II server to be monitored.
-    The number at the end of the parameter name is referred as "server id",
-    and it starts from 0.
-    </p>
-    <p>
-    You need to restart pgpool-II if you change this value.
-    </p>
-    </dd>
-</dl>
-
-<h2 id="INTEGRATE_EXT_LIFECHECK">Integrating external lifecheck with watchdog <span class="version">V3.5 -</span></h2>
-<p>
-pgpool-II watchdog process uses the BSD sockets for communicating with all pgpool-II processes and
-the same BSD socket can be used by any third party system to provide the lifecheck function for
-local and remote pgpool-II watchdog nodes.
-The BSD socket file name for IPC is constructed by appending pgpool-II <a href="WD_PORT">wd_port</a> after "s.PGPOOLWD_CMD."
-string and the socket file is placed in the pgpool-II <a href="#WD_IPC_SOCKET_DIR">wd_ipc_socket_dir</a> directory.
-</p>
-<h3 id="Watchdog_IPC_command_packet_format">Watchdog IPC command packet format</h3>
-<dl>
-<p>
-The watchdog IPC command packet consists of three fields. Below table details the message fields and description
-</p>
-<table border>
-	<tr class="header"><th>Field</th>		<th>Type</th>						<th>Description</th></tr>
-	<tr><th>TYPE</th>		<td>BYTE1</td>						<td>Command Type</td></tr>
-	<tr><th>LENGTH</th>		<td>INT32 Network byte order</td>	<td>The length of data to follow</td></tr>
-	<tr><th>DATA</th>		<td>DATA in JSON format</td>		<td>Command data in JSON format</td></tr>
-</table>
-</dl>
-<h3 id="Watchdog_IPC_result_packet_format">Watchdog IPC command result packet format</h3>
-<dl>
-<p>
-The watchdog IPC command result packet consists of three fields. Below table details the message fields and description
-</p>
-<table border>
-	<tr class="header"><th>Field</th>		<th>Type</th>						<th>Description</th></tr>
-	<tr><th>TYPE</th>		<td>BYTE1</td>						<td>Command Type</td></tr>
-	<tr><th>LENGTH</th>		<td>INT32 Network byte order</td>	<td>The length of data to follow</td></tr>
-	<tr><th>DATA</th>		<td>DATA in JSON format</td>		<td>Command result data in JSON format</td></tr>
-</table>
-</dl>
-<h3 id="Watchdog_IPC_command_packet_types">Watchdog IPC command packet types</h3>
-<dl>
-<p>
-The first byte of the IPC command packet sent to watchdog process and the result returned by watchdog process is identified
-as the command or command result type. The below table lists all valid types and their meanings
-</p>
-<table border>
-	<tr class="header"><th>Name</th>		<th>Byte Value</th>	<th>Type</th><th>Description</th></tr>
-	<tr><th><a name="ipc_reg_for_notifications"></a>REGISTER FOR NOTIFICATIONS</th>	<td>'0'</td>	<td>Command packet</td> <td>Command to register the current connection to receive watchdog notifications</td></tr>
-	<tr><th><a name="ipc_node_status_change"></a>NODE STATUS CHANGE</th>			<td>'2'</td>	<td>Command packet</td> <td>Command to inform watchdog about node status change of watchddog node</td></tr>
-	<tr><th><a name="ipc_get_nodes_list"></a>GET NODES LIST</h4></th>				<td>'3'</td>	<td>Command packet</td> <td>Command to get the list of all configured watchdog nodes</td></tr>
-	<tr><th><a name="ipc_nodes_list_data"></a>NODES LIST DATA</th>			<td>'4'</td>	<td>Result packet</td>  <td>The JSON data in packet
-		contains the list of all configured watchdog nodes</th></tr>
-	<tr><th><a name="ipc_cluster_in_tran"></a>CLUSTER IN TRANSITION</th>		<td>'7'</td>	<td>Result packet</td> <td>Watchdog returns this packet type when it is not possible to process the command because the cluster is transitioning.'</td></tr>
-	<tr><th><a name="ipc_result_bad"></a>RESULT BAD</th>					<td>'8'</td>	<td>Result packet</td> <td>Watchdog returns this packet type when the IPC command fails</td></tr>
-	<tr><th><a name="ipc_result_ok"></a>RESULT OK</th>					<td>'9'</td>	<td>Result packet</td> <td>Watchdog returns this packet type when IPC command succeeds</td></tr>
-
-</table>
-</dl>
-
-<h3 id="external_lifecheck_ipc">External lifecheck IPC packets and data</h3>
-<dl>
-<a href="#ipc_get_nodes_list">"GET NODES LIST"</a> ,<a href="#ipc_nodes_list_data">"NODES LIST DATA"</a>
-and <a href="#ipc_node_status_change">"NODE STATUS CHANGE"</a> IPC messages of watchdog can be used to integration an external lifecheck systems.
-Note that the built-in lifecheck of pgpool also uses the same channel and technique.
-<h4 id="external_lifecheck_ipc">Getting list of configured watchdog nodes</h4>
-<dl>
-Any third party lifecheck system can send the <a href="#ipc_get_nodes_list">"GET NODES LIST"</a> packet on watchdog IPC socket with a JSON data containing the authorization key and value if
-<a href="#WD_AUTHKEY">wd_authkey</a> is set or empty packet data when wd_authkey is not set to get the <a href="#ipc_nodes_list_data">"NODES LIST DATA"</a> result packet which, contains the list of all configured
-watchdog nodes to health check on in JSON format.
-The JSON of watchdog nodes contains the "WatchdogNodes" Array of all watchdog nodes. Each watchdog JSON node contains
-"ID", "NodeName", "HostName", "DelegateIP", "WdPort" and "PgpoolPort" for each node.
-<pre>
--- The example JSON data contained in <a href="#ipc_nodes_list_data">"NODES LIST DATA"</a>
-
-  {
-	"NodeCount":3,
-	"WatchdogNodes":
-		[
-			{
-				"ID":0,
-				"State":1,
-				"NodeName":"Linux_ubuntu_9999",
-				"HostName":"watchdog-host1",
-				"DelegateIP":"172.16.5.133",
-				"WdPort":9000,
-				"PgpoolPort":9999
-			},
-			{
-				"ID":1,
-				"State":1,
-				"NodeName":"Linux_ubuntu_9991",
-				"HostName":"watchdog-host2",
-				"DelegateIP":"172.16.5.133",
-				"WdPort":9000,
-				"PgpoolPort":9991
-			},
-			{
-				"ID":2,
-				"State":1,
-				"NodeName":"Linux_ubuntu_9992",
-				"HostName":"watchdog-host3",
-				"DelegateIP":"172.16.5.133",
-				"WdPort":9000,
-				"PgpoolPort":9992
-			}
-		]
-  }
-
- -- Note that ID 0 is always reserved for local watchdog node
-</pre>
-
-After getting the configured watchdog nodes information from the watchdog the external lifecheck system can proceed
-with health checking of watchdog nodes, and when it detects some status change of any node it can inform that to watchdog
-using the <a href="#ipc_node_status_change">"NODE STATUS CHANGE"</a> IPC messages of watchdog.
-The data in the message should contain the JSON with the node ID of the node whose status is changed (The node ID must be
-same as returned by watchdog for that node in WatchdogNodes list) and the new status of node.
-<pre>
--- The example JSON to inform pgpool-II watchdog about health check
-failed on node with ID 1 will look like
-
-  {
-	"NodeID":1,
-	"NodeStatus":1,
-	"Message":"optional message string to log by watchdog for this event"
-	"IPCAuthKey":"<a href="#WD_AUTHKEY">wd_authkey</a> configuration parameter value"
-  }
-
--- NodeStatus values meanings are as follows
-NODE STATUS DEAD  =  1
-NODE STATUS ALIVE =  2
-
-</pre>
-
-</dl>
-</dl>
-
-<h2 id="watchdog_restrictions">Restrictions on watchdog</h2>
-<ul>
-<li>
-In query mode, when all the DB nodes are detached from a pgpool-II due to PostgreSQL server failure or
-pcp_detach_node issued, watchdog regards that the pgpool-II service is in down status and
-brings the virtual IP assigned to watchdog down. Thus clients of pgpool cannot connect to
-pgpool-II using the virtual IP any more. This is neccessary to avoid <i>split-brain</i>,
-that is, situations where there are multiple active pgpool-II.
-</li>
-<li>
-Don't connect to pgpool-II in down status using the real IP. Because a pgpool-II in down status
-can't receive information from watchdog, its backend status may be different from other pgpool-II.
-</li>
-<li>
-pgpool-II in down status can't become active nor standby pgpool-II.
-Recovery from down status requires restart of pgpool-II.
-</li>
-<li>
-Please note that after the active pgpool-II stops, it will take a few seconds until the
-standby pgpool-II promote to new active, to make sure that the former virtual IP is brought
-down before a down notification packet is sent to other pgpool-IIs.
-</li>
-</ul>
-<p class="top_link"><a href="#Top">back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1 id="pcp_command">PCP Commands</h1>
-
-<h2>PCP commands list</h2>
-<p>PCP commands are UNIX commands which manipulate pgpool-II via the network.
-Please note that the parameter format for all PCP commands has been changed since pgpool-II 3.5</p>
-<table border>
-<tr><th><a href="#pcp_node_count">pcp_node_count</a></th>
-    <td>retrieves the number of nodes</td></tr>
-<tr><th><a href="#pcp_node_info">pcp_node_info</a></th>
-    <td>retrieves the node information</td></tr>
-<tr><th><a href="#pcp_watchdog_info">pcp_watchdog_info</a> <span class="version">V3.3 -</span></th>
-    <td>retrieves the watchdog information</td></tr>
-<tr><th><a href="#pcp_proc_count">pcp_proc_count</a></th>
-    <td>retrieves the process list</td></tr>
-<tr><th><a href="#pcp_proc_info">pcp_proc_info</a></th>
-    <td>retrieves the process information</td></tr>
-<tr><th><a href="#pcp_pool_status ">pcp_pool_status</a> <span class="version">V3.1 -</span></th>
-    <td>retrieves parameters in pgpool.conf</td></tr>
-<tr><th><a href="#pcp_detach_node">pcp_detach_node</a></th>
-    <td>detaches a node from pgpool-II</td></tr>
-<tr><th><a href="#pcp_attach_node">pcp_attach_node</a></th>
-    <td>attaches a node to pgpool-II</td></tr>
-<tr><th><a href="#pcp_promote_node">pcp_promote_node</a> <span class="version">V3.1 -</span></th>
-    <td>promote a new master node to pgpool-II</td></tr>
-<tr><th><a href="#pcp_stop_pgpool">pcp_stop_pgpool</a></th>
-    <td>stops pgpool-II</td></tr>
-</table>
-
-
-<h2 id="pcp_comand_password">PCP connection authentication</h2>
-
-<p>PCP user names and passwords must be declared in
-<code>pcp.conf</code> in <code>$prefix/etc</code>
-directory. <code>-F</code> option can be used when starting pgpool-II
-if <code>pcp.conf</code> is placed somewhere else.</p>
-
-<h3 id="password_file">The Password File</h3>
-
-<p>The file .pcppass in a user's home directory or the file referenced by environment variable
-PCPPASSFILE can contain passwords to be used if no password has been specified for the pcp connection.</p>
-<p>This file should contain lines of the following format:/<p>
-
-<pre>
-hostname:port:username:password
-</pre>
-<p>
-(You can add a reminder comment to the file by copying the line above and preceding it with #.)
-Each of the first three fields can be a literal value, or *, which matches anything. The password
-field from the first line that matches the current connection parameters will be used. (Therefore,
-put more-specific entries first when you are using wildcards.) If an entry needs to contain : or \,
-escape this character with \. A host name of localhost matches both TCP (host name localhost) and
-Unix domain socket connections coming from the local machine.</p>
-
-<p>The permissions on .pcppass must disallow any access to world or group; achieve this by the command
-chmod 0600 ~/.pcppass. If the permissions are less strict than this, the file will be ignored.</p>
-
-<h2 id="pcp_common_options">Common options</h2>
-
-<p>There are some arguments common to all PCP commands.
-Most of these are for authentication and
-the rest are about verbose mode, debug message, and so on.
-<pre>
-e.g.)  $ pcp_node_count -h localhost -p 9898 -u postgres -w -d -v
-</pre>
-
-<dl class="options">
-<dt><code>
--h <strong>hostname</strong>, --host=<strong>hostname</strong>
-</code></dt>
-<dd><p>
-The host name of the machine on which the server is running. If the
-value begins with a slash, it is used as the directory for the Unix-domain socket.
-</p></dd>
-
-<dt><code>
--p <strong>port</strong>, --port=<strong>port</strong>
-</code></dt>
-<dd><p>
-The PCP port number (default:"9898").
-</p></dd>
-
-<dt><code>
--u <strong>username</strong>, --username=<strong>username</strong>
-</code></dt>
-<dd><p>
-The user name for PCP authentication (default: OS user name).
-</p></dd>
-
-<dt><code>
--w, --no-password
-</code></dt>
-<dd><p>
-Never prompt for password. And if a password is not available by a .pcppass file,
-the connection attempt will fail. This option can be useful in batch jobs and scripts
-where no user is present to enter a password.
-</p></dd>
-
-<dt><code>
--W, --password
-</code></dt>
-<dd><p>
-Force password prompt (should happen automatically).
-</p></dd>
-
-<dt><code>
--d, --debug
-</code></dt>
-<dd><p>
-Enable debug message.
-</p></dd>
-
-<dt><code>
--v, --verbose
-</code></dt>
-<dd><p>
-Enable verbose output.
-</p></dd>
-
-<dt><code>
--V, --version
-</code></dt>
-<dd><p>
-Print the command version, then exit.
-</p></dd>
-
-<dt><code>
--?, --help
-</code></dt>
-<dd><p>
-Shows help for the command line arguments, then exit.
-</p></dd>
-</dl>
-
-<h2>PCP Commands to know status and configuration</h2>
-
-<p>All PCP commands display the results to the standard output.</p>
-
-
-<h3 id="pcp_node_count">pcp_node_count</h3>
-<dl>
-<dt>Format:</dt>
-<dd>
-	<pre><code>pcp_node_count [options...] </code></pre>
-</dd>
-<dt>Description:</dt>
-<dd>
-	<p>Displays the total number of nodes defined in <code>pgpool.conf</code>. It does
-	not distinguish between nodes status, ie attached/detached. ALL nodes are counted.</p>
-</dd>
-<dt>Options:</dt>
-<dd>
-	<p>See <a href="#pcp_common_options">common options</a>. </p>
-</dd>
-</dl>
-
-<h3 id="pcp_node_info">pcp_node_info</h3>
-<dl>
-<dt>Format:</dt>
-<dd>
-	<pre><code>pcp_node_info [options...] [node_id] </code></pre>
-</dd>
-<dt>Description:</dt>
-<dd>
-	<p>Displays the information on the given node ID.</p>
-	<p>
-	Please note that since pgpool-II <span class="version">3.6</span>, The output also contains the human readable node status
-	</p>
-
-</dd>
-<dt>Options:</dt>
-<dd>
-	<dl class="options">
-	<dt><code>-n <strong>node_id</strong>, --node-id=<strong>node_id</strong></code></dt>
-	<dd>
-		<p>The index of backend node to get information of.</p>
-	</dd>
-	<dt>Other options</dt>
-	<dd>
-		<p>See <a href="#pcp_common_options">common options</a>. </p>
-	</dd>
-	</dl>
-</dd>
-<dt>Output example:</dt>
-<dd>
-<pre>
-$ pcp_node_info -h localhost -U postgres 0
-host1 5432 1 1073741823.500000 waiting
-</pre>
-
-<p>The result is in the following order:</p>
-<ol>
-<li>hostname</li>
-<li>port number</li>
-<li>status</li>
-<li>load balance weight</li>
-<li>status name</li>
-</ol>
-
-<p>Status is represented by a digit from [0 to 3].</p>
-<ul>
-<li>0 - This state is only used during the initialization. PCP will never display it.</li>
-<li>1 - Node is up. No connections yet.</li>
-<li>2 - Node is up. Connections are pooled.</li>
-<li>3 - Node is down.</li>
-</ul>
-<p>The load balance weight is displayed in normalized format.</p>
-
-<p>The <code>--verbose</code> option can help understand the output. For example:</p>
-
-<pre>
-$ pcp_node_info --verbose -h localhost -U postgres 0
-Hostname   : host1
-Port       : 5432
-Status     : 1
-Weight     : 0.5
-Status Name: waiting
-</pre>
-</dd>
-</dl>
-
-<h3><a name="pcp_watchdog_info"/></a>pcp_watchdog_info <span class="version">V3.3 -</span></h3>
-<dl>
-<dt>Format:</dt>
-<dd>
-	<pre><code>pcp_watchdog_info [options...] [watchdog_id]</code></pre>
-</dd>
-<dt>Description:</dt>
-<dd>
-<p>Displays the watchdog status of the pgpool-II.
-<code>watchdog_id</code> is the index of watchdog node to get information for.
-If this is omitted, display the watchdog status of all watchdog nodes in the cluster.
-</p><p>
-<code>watchdog_id</code> = 0 is reserved for local pgpool-II node,
-So the index of remote watchdog nodes starts from 1.
-Note that since the index numbering in pcp_watchdog_info utility starts from 1 while
-the pgpool.conf file uses 0 based indexing to define remote watchdog nodes, so you will require
-to add one to the other watchdog index to get its information using pcp_watchdog_info utility.
-</p><p>
-For example, to get the information of first remote watchdog node configured with prefix 0
-defined by other_pgpool_hostname0 parameters you will use <code>watchdog_id</code> = 1 for pcp_watchdog_info.</p>
-</dd>
-<dt>Options:</dt>
-<dd>
-	<dl class="options">
-	<dt><code>-n <strong>watchdog_id</strong>, --node-id=<strong>watchdog_id</strong></code></dt>
-	<dd>
-		<p>The index of other pgpool-II to get information for.</p>
-		<p>Index 0 gets one's self watchdog information'.</p>
-		<p>If ommitted then gets information of all watchdog nodes'.</p>
-	</dd>
-	<dt>Other options</dt>
-	<dd>
-		<p>See <a href="#pcp_common_options">common options</a>. </p>
-	</dd>
-	</dl>
-</dd>
-<dt>Output example:</dt>
-<dd>
-<pre>
-$ pcp_watchdog_info -h localhost -u postgres
-
-3 NO Linux_host1.localdomain_9991 host1
-
-Linux_host1.localdomain_9991 host1 9991 9001 7 STANDBY
-Linux_host2.localdomain_9992 host2 9992 9002 4 MASTER
-Linux_host3.localdomain_9993 host3 9993 9003 7 STANDBY
-
-</pre>
-
-<p>The result is in the following order:</p>
-<p>The first output line describes the watchdog cluster information:</p>
-<ol>
-<li>Total watchdog nodes in the cluster</li>
-<li>Is VIP is up on current node?</li>
-<li>Master node name</li>
-<li>Master node host</li>
-</ol>
-
-
-<p>Next is the list of watchdog nodes:</p>
-<ol>
-	<li>node name</li>
-	<li>hostname</li>
-	<li>pgpool port</li>
-	<li>watchdog port</li>
-	<li>current node state</li>
-	<li>current node state name</li>
-</ol>
-</dd>
-
-<dt>verbose mode:</dt>
-<dd>
-<pre>
-$ pcp_watchdog_info -h localhost -v -u postgres
-
-Watchdog Cluster Information
-Total Nodes          : 3
-Remote Nodes         : 2
-Quorum state         : QUORUM EXIST
-Alive Remote Nodes   : 2
-VIP up on local node : NO
-Master Node Name     : Linux_host2.localdomain_9992
-Master Host Name     : localhost
-
-Watchdog Node Information
-Node Name      : Linux_host1.localdomain_9991
-Host Name      : host1
-Delegate IP    : 192.168.1.10
-Pgpool port    : 9991
-Watchdog port  : 9001
-Node priority  : 1
-Status         : 7
-Status Name    : STANDBY
-
-Node Name      : Linux_host2.localdomain_9992
-Host Name      : host2
-Delegate IP    : 192.168.1.10
-Pgpool port    : 9992
-Watchdog port  : 9002
-Node priority  : 1
-Status         : 4
-Status Name    : MASTER
-
-Node Name      : Linux_host3.localdomain_9993
-Host Name      : host3
-Delegate IP    : 192.168.1.10
-Pgpool port    : 9993
-Watchdog port  : 9003
-Node priority  : 1
-Status         : 7
-Status Name    : STANDBY
-
-</pre>
-</dd>
-</dl>
-
-
-<h3 id="pcp_proc_count">pcp_proc_count</h3>
-<dl>
-<dt>Format:</dt>
-<dd>
-	<pre><code>pcp_proc_count [options...] </code></pre>
-</dd>
-<dt>Description:</dt>
-<dd>
-	<p>Displays the list of pgpool-II children process IDs. If there is more than
-	one process, IDs will be delimited by a white space.</p>
-</dd>
-
-<dt>Options:</dt>
-	<p>See <a href="#pcp_common_options">common options</a>. </p>
-</dd>
-</dl>
-
-
-<h3 id="pcp_proc_info">pcp_proc_info</h3>
-<dl>
-<dt>Format:</dt>
-<dd>
-	<pre><code>pcp_proc_info [options...] [processid] </code></pre>
-</dd>
-<dt>Description:</dt>
-<dd>
-	<p>Displays the information on the given pgpool-II child process ID.</p>
-</dd>
-<dt>Options:</dt>
-<dd>
-	<dl class="options">
-	<dt><code>-P <strong>PID</strong>, --process-id=<strong>PID</strong></code></dt>
-	<dd>
-		<p>PID of pgpool-II child process.</p>
-	</dd>
-	<dt>Other options</dt>
-	<dd>
-		<p>See <a href="#pcp_common_options">common options</a>. </p>
-	</dd>
-</dd>
-<dt>Output example:</dt>
-<dd>
-<pre>
-$ pcp_proc_info -h localhost -p 9898 -U postgres 3815
-postgres_db postgres 1150769932 1150767351 3 0 1 1467 1
-postgres_db postgres 1150769932 1150767351 3 0 1 1468 1
-</pre>
-
-<p>The result is in the following order:</p>
-<ol>
-<li>connected database name</li>
-<li>connected user name</li>
-<li>process start-up timestamp</li>
-<li>connection created timestamp</li>
-<li>protocol major version</li>
-<li>protocol minor version</li>
-<li>connection-reuse counter</li>
-<li>PostgreSQL backend process id</li>
-<li>1 if frontend conncted 0 if not</li>
-</ol>
-
-<p>
-If there is no connection to the backends, nothing will be
-displayed. If there are multiple connections, one connection's
-information will be displayed on each line multiple
-times. Timestamps are displayed in EPOCH format.
-</p>
-
-<p>
-The </code>--verbose</code> option can help understand the output. For example:
-</p>
-
-<pre>
-$ pcp_proc_info --verbose -U postgres 3815
-Database     : postgres_db
-Username     : postgres
-Start time   : 1150769932
-Creation time: 1150767351
-Major        : 3
-Minor        : 0
-Counter      : 1
-PID          : 1467
-Connected    : 1
-Database     : postgres_db
-Username     : postgres
-Start time   : 1150769932
-Creation time: 1150767351
-Major        : 3
-Minor        : 0
-Counter      : 1
-PID          : 1468
-Connected    : 1
-</pre>
-</dd>
-</dl>
-
-<h3 id="pcp_pool_status">pcp_pool_status <span class="version">V3.1 -</span></h3>
-<dl>
-<dt>Format:</dt>
-<dd>
-	<pre><code>pcp_pool_status [options...]</code></pre>
-</dd>
-<dt>Description:</dt>
-<dd>
-	<p>Displays the parameter values as defined in pgpool.conf.</p>
-</dd>
-<dt>Options:</dt>
-<dd>
-	<p>See <a href="#pcp_common_options">common options</a>. </p>
-</dd>
-<dt>Output example:</dt>
-<dd>
-<pre>
-$ pcp_pool_status -h localhost -U postgres
-name : listen_addresses
-value: localhost
-desc : host name(s) or IP address(es) to listen to
-
-name : port
-value: 9999
-desc : pgpool accepting port number
-
-name : socket_dir
-value: /tmp
-desc : pgpool socket directory
-
-name : pcp_port
-value: 9898
-desc : PCP port # to bind
-</pre>
-</dd>
-</dl>
-
-<h2>PCP Commands to control backend nodes, etc.</h2>
-
-<h3 id="pcp_detach_node">pcp_detach_node</h3>
-<dl>
-<dt>Format:</dt>
-<dd>
-	<pre><code>pcp_detach_node [options...] [node_id] [gracefully]</code></pre>
-</dd>
-<dt>Description:</dt>
-<dd>
-	<p>Detaches the given node from pgpool-II. Exisiting connections to pgpool-II are forced to be disconnected.</p>
-</dd>
-<dt>Options:</dt>
-<dd>
-	<dl class="options">
-	<dt><code>-n <strong>node_id</strong>, --node-id=<strong>node_id</strong></code></dt>
-	<dd>
-		<p>The index of backend node to detach.</p>
-	</dd>
-	<dt><code>-g, --gracefully </code></dt>
-	<dd>
-		<p>Wait until all clients are disconnected (unless
-		client_idle_limit_in_recovery is -1 or recovery_timeout is expired).</p>
-	</dd>
-	<dt>Other options</dt>
-	<dd>
-		<p>See <a href="#pcp_common_options">common options</a>. </p>
-	</dd>
-	</dl>
-</dd>
-</dl>
-
-
-<h3 id="pcp_attach_node">pcp_attach_node</h3>
-<dl>
-<dt>Format:</dt>
-<dd>
-	<pre><code>pcp_attach_node [options...] [node_id]</code></pre>
-</dd>
-<dt>Description:</dt>
-<dd>
-	<p>Attaches the given node to pgpool-II.</p>
-</dd>
-<dt>Options:</dt>
-<dd>
-	<dl class="options">
-	<dt><code>-n <strong>node_id</strong>, --node-id=<strong>node_id</strong></code></dt>
-	<dd>
-		<p>The index of backend node to attach.</p>
-	</dd>
-	<dt>Other options</dt>
-	<dd>
-		<p>See <a href="#pcp_common_options">common options</a>. </p>
-	</dd>
-	</dl>
-</dd>
-</dl>
-
-<h3 id="pcp_promote_node">pcp_promote_node <span class="version">V3.1 -</span></h3>
-<dl>
-<dt>Format:</dt>
-<dd>
-	<pre><code>pcp_promote_node [options...] [node_id] [gracefully]</code></pre>
-</dd>
-<dt>Description:</dt>
-<dd>
-	<p>Promotes the given node as new master to pgpool-II. In master/slave streaming replication only. Please note that this command does not actually promote standby PostgreSQL backend: it just changes the internal status of pgpool-II and trigger failover and users have to promote standby PostgreSQL outside pgpool-II.</p>
-</dd>
-<dt>Options:</dt>
-<dd>
-	<dl class="options">
-	<dt><code>-n <strong>node_id</strong>, --node-id=<strong>node_id</strong></code></dt>
-	<dd>
-		<p>The index of backend node to promote as new master.</p>
-	</dd>
-	<dt><code>-g, --gracefully </code></dt>
-	<dd>
-		<p>Wait until all clients are disconnected (unless
-		client_idle_limit_in_recovery is -1 or recovery_timeout is expired).</p>
-	</dd>
-	<dt>Other options</dt>
-	<dd>
-		<p>See <a href="#pcp_common_options">common options</a>. </p>
-	</dd>
-	</dl>
-</dd>
-</dl>
-
-<h3 id="pcp_stop_pgpool">pcp_stop_pgpool</h3>
-<dl>
-<dt>Format:</dt>
-<dd>
-	<pre><code>pcp_stop_pgpool [options...] [mode]</code></pre>
-</dd>
-<dt>Description:</dt>
-<dd>
-	<p>Terminate the pgpool-II process.</p>
-</dd>
-<dt>Options:</dt>
-<dd>
-	<dl class="options">
-	<dt><code>-m <strong>mode</strong>, --mode=<strong>mode</strong></code></p>
-	<dd>
-		<p>Shutdown mode for terminating the pgpool-II process.</p>
-		<p>The available modes are as follows:</p>
-		<ul>
-			<li>s, smart        : smart mode</li>
-			<li>f, fast         : fast mode</li>
-			<li>i, immediate    : immediate mode</li>
-		</ul>
-	</dd>
-	<dt>Other options</dt>
-	<dd>
-		<p>See <a href="#pcp_common_options">common options</a>. </p>
-	</dd>
-	</dl>
-</dl>
-
-<h3 id="pcp_recovery_node">pcp_recovery_node</h3>
-<dl>
-<dt>Format:</dt>
-<dd>
-	<pre><code>pcp_recovery_node [options...] [node_id] </code></pre>
-</dd>
-<dt>Description:</dt>
-<dd>
-	<p>Attaches the given backend node with recovery.</p>
-</dd>
-<dt>Options:</dt>
-<dd>
-	<dl class="options">
-	<dt><code>-n <strong>node_id</strong>, --node-id=<strong>node_id</strong></code></dt>
-	<dd>
-		<p>The index of backend node.</p>
-	</dd>
-	<dt>Other options</dt>
-	<dd>
-		<p>See <a href="#pcp_common_options">common options</a>. </p>
-	</dd>
-	</dl>
-</dd>
-</dl>
-
-<p class="top_link"><a href="#Top">back to top</a></p>
-
-<h1 id="pgpool_adm">pool_adm</h1>
-<p>
-  pgpoo_adm is a set of extensions to allow SQL access to pcp commands
-  (actually, pcp libraries).
-  It uses foreign data wrapper as shown in the diagram below.
-</p>
-
-<p><img src="pgpool_adm.png" alt="Data flow in pgpool_adm" hight=70% width=70%></p>
-
-<p>
-  It is possible to call the functions from either via pgpool-II (1) or via PostgreSQL (2).
-  In case (1), pgpool-II accepts query from user (1), then forward to PostgreSQL (3).
-  PostgreSQL connects to pgpool-II (5) and pgpool-II reply back to PostgreSQL with the result (3). PostgreSQL returns the result to pgpool-II (5) and pgpool-II fowards the data to the user (6).
-</p>
-<p>
-  In case (2), PostgreSQL accepts query from user (2).
-  PostgreSQL connects to pgpool-II (5) and pgpool-II reply back to PostgreSQL with the result (3).
-  PostgreSQL replies back the data to the user (6).
-</p>
-<p>
-  There are two forms to call pgpool_adm functions: first form accepts pgpool-II host name (or IP address), pcp port number, pcp user name, its password and another parameters.
-</p>
-<p>
-  In the second form, pgpool-II server name is required.
-  The server name must be already defined using "CREATE FOREIGN SERVER" command of PostgreSQL.
-The pcp port number is hard coded as 9898, the pcp user name is assumes to be same as caller's PostgreSQL user name.
-  password is extraced from $HOME/.pcppass.
-</p>
-
-<h2>Installing pgpool_adm</h2>
-<p>
-pgpool_adm is an extension and should be installed on all PostgreSQL servers.
-</p>
-<p>
-<pre>
-$ cd src/sql/pgpool_adm
-$ make
-$ make install
-</pre>
-</p>
-<p>
-Then issue following SQL command for every database you want to access.
-</p>
-<p>
-<pre>
-$ psql ...
-$ CREATE EXTENSION pgpool_adm
-</pre>
-</p>
-
-<h2>pgpool_adm functions list</h2>
-<table border>
-<tr><th><a href="#func_pcp_node_info">pcp_node_info</a></th>
-  <td>retrieves the node information</td></tr>
-<tr><th><a href="#func_pcp_pool_status">pcp_pool_status</a></th>
-    <td>retrieves parameters in pgpool.conf</td></tr>
-<tr><th><a href="#func_pcp_node_count">pcp_node_count</a></th>
-  <td>retrieves the number of nodes</td></tr>
-<tr><th><a href="#func_pcp_attach_node">pcp_attach_node</a></th>
-  <td>attaches a node to pgpool-II</td></tr>
-<tr><th><a href="#func_pcp_detach_node">pcp_detach_node</a></th>
-  <td>detaches a node to pgpool-II</td></tr>
-</table>
-
-<h3 id="func_pcp_node_info">pcp_node_info</h3>
-<dl>
-<dt>Format:</dt>
-<dd>
-  <pre><code>pcp_node_info(integer node_id, text host, integer port, text username, text password, OUT status text, OUT weight float4) returns record</code></pre>
-  <pre><code>pcp_node_info(integer node_id, text pcp_server, OUT status text, OUT weight float4) returns record</code></pre>
-</dd>
-
-<dt>Description:</dt>
-<dd>
-  <p>Retrieves the node information.
-  See <a href="#pcp_node_info">pcp_node_info command</a> for more details.</p>
-  <p>
-    Here is an example output.
-<pre>
-test=# SELECT * FROM pcp_node_info(0,'',11001,'t-ishii','t-ishii');
- host | port  |      status       | weight 
-------+-------+-------------------+--------
- /tmp | 11002 | Connection in use |      0
-(1 row)
-</pre>
-  </p>
-</dd>
-
-<dt>Parameters:</dt>
-<dd>
-  <dl class="options">
-  <dt><code>node_id</strong></code></dt>
-  <p>The index of backend node.</p>
-
-  <dt><code>host</strong></code></dt>
-  <p>The host name or IP address where pcp server is running on.</p>
-
-  <dt><code>port</strong></code></dt>
-  <p>The port number pcp server is listening on.</p>
-
-  <dt><code>username</strong></code></dt>
-  <p>The user name to access pcp server.</p>
-
-  <dt><code>password</strong></code></dt>
-  <p>The password to access pcp server.</p>
-
-  <dt><code>pcp_server</strong></code></dt>
-  <p>The foreign server name for pcp server.</p>
-
-</dd>
-
-</dd>
-</dl>
-</h3>
-
-<h3 id="func_pcp_pool_status">pcp_pool_status</h3>
-<dl>
-<dt>Format:</dt>
-<dd>
-  <pre><code>pcp_pool_status(text host, integer port, text username, text password) returns record</code></pre>
-  <pre><code>pcp_pool_status(text pcp_server) returns record</code></pre>
-</dd>
-
-<dt>Description:</dt>
-<dd>
-  <p>Retrieves parameters in pgpool.conf.
-  See <a href="#pool_status">pool_status</a> for more details.</p>
-  <p>
-    Here is an example output.
-<pre>
-test=# SELECT * FROM pcp_pool_status('localhost',11001,'t-ishii','t-ishii') WHERE item ~ 'backend.*0';
-          item           |                     value                      |          description          
--------------------------+------------------------------------------------+-------------------------------
- backend_hostname0       | /tmp                                           | backend #0 hostname
- backend_port0           | 11002                                          | backend #0 port number
- backend_weight0         | 0.500000                                       | weight of backend #0
- backend_data_directory0 | /home/t-ishii/work/pgpool-II/current/aaa/data0 | data directory for backend #0
- backend_status0         | 2                                              | status of backend #0
- backend_flag0           | ALLOW_TO_FAILOVER                              | backend #0 flag
-(6 rows)
-</pre>
-  </p>
-</dd>
-
-<dt>Parameters:</dt>
-<dd>
-  <dl class="options">
-<dd>
-  <dt><code>host</strong></code></dt>
-  <p>The host name or IP address where pcp server is running on.</p>
-
-  <dt><code>port</strong></code></dt>
-  <p>The port number pcp server is listening on.</p>
-
-  <dt><code>username</strong></code></dt>
-  <p>The user name to access pcp server.</p>
-
-  <dt><code>password</strong></code></dt>
-  <p>The password to access pcp server.</p>
-
-  <dt><code>pcp_server</strong></code></dt>
-  <p>The foreign server name for pcp server.</p>
-
-</dd>
-
-</dd>
-</dl>
-</h3>
-
-<h3 id="func_pcp_node_count">pcp_node_node_count</h3>
-<dl>
-<dt>Format:</dt>
-<dd>
-  <pre><code>pcp_node_count(integer node_id, text host, integer port, text username, text password, OUT node_count integer) returns integer</code></pre>
-  <pre><code>pcp_node_count(integer node_id, OUT node_count integer) returns record</code></pre>
-</dd>
-
-<dt>Description:</dt>
-<dd>
-  <p>Retrieves the number of DB nodes.
-  See <a href="#pcp_node_count">pcp_node_count command</a> for more details.</p>
-  <p>
-    Here is an example output.
-<pre>
-test=# SELECT * FROM pcp_node_count('localhost',11001,'t-ishii','t-ishii');
- node_count 
-------------
-          2
-(1 row)
-</pre>
-  </p>
-</dd>
-
-<dt>Parameters:</dt>
-<dd>
-  <dl class="options">
-
-<dd>
-  <dt><code>host</strong></code></dt>
-  <p>The host name or IP address where pcp server is running on.</p>
-
-  <dt><code>port</strong></code></dt>
-  <p>The port number pcp server is listening on.</p>
-
-  <dt><code>username</strong></code></dt>
-  <p>The user name to access pcp server.</p>
-
-  <dt><code>password</strong></code></dt>
-  <p>The password to access pcp server.</p>
-
-  <dt><code>pcp_server</strong></code></dt>
-  <p>The foreign server name for pcp server.</p>
-
-</dd>
-
-</dd>
-</dl>
-</h3>
-
-<h3 id="func_pcp_attach_node">pcp_attach_node</h3>
-<dl>
-<dt>Format:</dt>
-<dd>
-  <pre><code>pcp_attach_node(integer node_id, text host, integer port, text username, text password, OUT node_attached boolean) returns boolean</code></pre>
-  <pre><code>pcp_attach_node(integer node_id, text pcp_server, OUT node_attached boolean) returns boolean</code></pre>
-</dd>
-
-<dt>Description:</dt>
-<dd>
-  <p>attaches a node to pgpool-II.
-  See <a href="#pcp_attach_node">pcp_attach_node command</a> for more details.</p>
-  <p>
-    Here is an example output.
-<pre>
-test=# SELECT * FROM pcp_attach_node(1,'localhost',11001,'t-ishii','t-ishii');
- node_attached 
----------------
- t
-(1 row)
-</pre>
-  </p>
-</dd>
-
-<dt>Parameters:</dt>
-<dd>
-  <dl class="options">
-  <dt><code>node_id</strong></code></dt>
-  <p>The index of backend node.</p>
-
-  <dt><code>host</strong></code></dt>
-  <p>The host name or IP address where pcp server is running on.</p>
-
-  <dt><code>port</strong></code></dt>
-  <p>The port number pcp server is listening on.</p>
-
-  <dt><code>username</strong></code></dt>
-  <p>The user name to access pcp server.</p>
-
-  <dt><code>password</strong></code></dt>
-  <p>The password to access pcp server.</p>
-
-  <dt><code>pcp_server</strong></code></dt>
-  <p>The foreign server name for pcp server.</p>
-
-</dd>
-
-</dd>
-</dl>
-</h3>
-
-<h3 id="func_pcp_detach_node">pcp_detach_node</h3>
-<dl>
-<dt>Format:</dt>
-<dd>
-  <pre><code>pcp_detach_node(integer node_id, boolean gracefully, text host, integer port, text username, text password, OUT node_detached boolean) returns boolean</code></pre>
-  <pre><code>pcp_detach_node(integer node_id, boolean gracefully, text pcp_server, OUT node_detached boolean) returns boolean</code></pre>
-</dd>
-
-<dt>Description:</dt>
-<dd>
-  <p>Detaches a node to pgpool-II and initiate fail over.
-  See <a href="#pcp_detach_node">pcp_detach_node</a> for more details.</p>
-  <p>
-    Here is an example output.
-<pre>
-test=# SELECT * FROM pcp_detach_node(1, 'false', 'localhost',11001,'t-ishii','t-ishii');
- node_detached 
----------------
- t
-(1 row)
-</pre>
-  </p>
-</dd>
-
-<dt>Parameters:</dt>
-<dd>
-  <dl class="options">
-  <dt><code>node_id</strong></code></dt>
-  <p>The index of backend node.</p>
-
-  <dt><code>gracefully</strong></code></dt>
-  <p>If true, wait for all session of pgpool-II terminates.
-    Actually specifying true to this is not a good idea, since this query will not end because the session itself is waiting the result.
-    It is strongly recommended to specify false to this parameter.
-  </p>
-
-  <dt><code>host</strong></code></dt>
-  <p>The host name or IP address where pcp server is running on.</p>
-
-  <dt><code>port</strong></code></dt>
-  <p>The port number pcp server is listening on.</p>
-
-  <dt><code>username</strong></code></dt>
-  <p>The user name to access pcp server.</p>
-
-  <dt><code>password</strong></code></dt>
-  <p>The password to access pcp server.</p>
-
-  <dt><code>pcp_server</strong></code></dt>
-  <p>The foreign server name for pcp server.</p>
-
-</dd>
-
-</dd>
-</dl>
-</h3>
-
-<p class="top_link"><a href="#Top">back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1><a name="troubleshooting"></a>Troubleshooting</h1>
-<p>
-This section describes problems and their workarounds while you are using
-pgpool-II.
-</p>
-
-<dl>
-
-<dt id="health_check_failed">Health check failed</dt>
-    <dd>
-    <p>
-    Pgpool-II's health checking feature detects DB nodes failure.
-    </p>
-
-<pre>
-2010-07-23 16:42:57 ERROR: pid 20031: health check failed. 1 th host foo at port 5432 is down
-2010-07-23 16:42:57 LOG:   pid 20031: set 1 th backend down status
-2010-07-23 16:42:57 LOG:   pid 20031: starting degeneration. shutdown host foo(5432)
-2010-07-23 16:42:58 LOG:   pid 20031: failover_handler: set new master node: 0
-2010-07-23 16:42:58 LOG:   pid 20031: failover done. shutdown host foo(5432)
-</pre>
-
-    <p>
-    The log shows that the DB node 1 (host foo) goes down and disconnected (shutdown)
-    from pgpool, and then that DB node 0 becomes new master.
-    Check DB node 1 and remove the cause of failure. After that perform an online
-    recovery against DB node 1 if possible.
-    </p>
-    </dd>
-
-<dt id="failed_to_read_kind_from_frontend">Failed to read kind from frontend</dt>
-    <dd>
-<pre>
-2010-07-26 18:43:24 LOG:   pid 24161: ProcessFrontendResponse: failed to read kind from frontend. frontend abnormally exited
-</pre>
-    <p>
-    This log indicates that the frontend program didn't disconnect properly from
-    pgpool-II.
-    The possible causes are: bugs of client applications, forced termination (kill)
-    of a client application, or temporary network failure.
-    This kind of events don't lead to a DB destruction or data consistency problem.
-    It's only a warning about a protocol violation.
-    It is advised that you check the applications and networks if the
-    message keeps on occurring.
-    </p>
-    </dd>
-
-<dt id="kind_mismatch">Kind mismatch errors</dt>
-    <dd>
-    <p>
-    It is possible that you get this error when pgpool-II operates in replication mode.
-    </p>
-<pre>
-2010-07-22 14:18:32 ERROR: pid 9966: kind mismatch among backends. Possible last query was: "FETCH ALL FROM c;" kind details are: 0[T] 1[E: cursor "c" does not exist]
-</pre>
-    <p>
-    Pgpool-II waits for responses from the DB nodes after sending an SQL command  to them.
-    This message indicates that not all DB nodes returned the same kind of response.
-    You'll get the SQL statement which possibly caused the error after "Possible last query was:".
-    Then the kind of response follows. If the response indicates an error, the
-    error message from PostgreSQL is shown.
-    Here you see "0[T]" displaying the DB node responses: "0[T]"
-    (starting to send row description), and "1[E" indicates that DB node 1 returns an error
-    with message "cursor "c" does not exist", while DB node 0 sends a row description.
-    </p>
-    <p>
-    Caution: You will see this error when operating in master/slave mode as well.
-    For example, even in the master/slave mode, SET command will be basically sent to all DB nodes
-    to keep all the DB nodes in the same state.
-    </p>
-    <p>
-    Check the databases and re-sync them using online recovery if you find
-    that they are out of sync.
-    </p>
-    </dd>
-
-<dt id="difference_of_number">Pgpool detected difference of the number of inserted, updated or deleted tuples
-    <dd>
-    <p>
-    In replication mode, pgpool-II detects a different number of
-    INSERT/UPDATE/DELETE rows on affected nodes.
-    </p>
-<pre>
-2010-07-22 11:49:28 ERROR: pid 30710: pgpool detected difference of the number of inserted, updated or deleted tuples. Possible last query was: "update t1 set i = 1;"
-2010-07-22 11:49:28 LOG:   pid 30710: ReadyForQuery: Degenerate backends: 1
-2010-07-22 11:49:28 LOG:   pid 30710: ReadyForQuery: Affected tuples are: 0 1
-</pre>
-    <p>
-    In the example above, the returned number of updated rows by "update t1 set i = 1"
-    was different among DB nodes.
-    The next line indicates that DB 1 got degenerated (disconnected) as a consequence,
-    and that the number of affected rows for DB node 0 was 0,
-    while for DB node 1 that was 1.
-    </p>
-    <p>
-    Stop the DB node which is suspected of having wrong data and do an online recovery.
-    </p>
-    </dd>
-</dl>
-
-<p class="top_link"><a href="#Top">back to top</a></p>
-
-
-<!-- ================================================================================ -->
-
-<h1>Restrictions<a name="restriction"></a></h1>
-
-<p>
-<h2>Functionality of PostgreSQL</h2>
-<p>
-<ul>
-<li>If you use pg_terminate_backend() to stop a backend, this will trigger
-     a failover.
-     The reason why this happens is that PostgreSQL sends exactly the same
-     message for a terminated backend as for a full postmaster shutdown.
-     There is no workaround as of today. Please do not use this function.
-</li>
-</ul>
-
-<p>
-<h2><a name="md5"></a>Authentication / Access Controls</h2>
-
-<p>
-<ul>
-    <li>In the replication mode or master/slave mode, trust, clear text password,
-        and pam methods are supported. md5 in also supported since pgpool-II 3.0.
-        md5 is supported by using a authencitaion file ("pool_passwd").
-        "pool_passwd" is default name of the authentication file.
-        You can change the file name using <a href="#POOL_PASSWD">pool_passwd</a>.
-        Here are the steps to enable md5 authentication:
-        <ol>
-            <li>Login as the database's operating system user and type
-                "pg_md5 --md5auth --username=<your_username> <your_passwd>"
-                 user name and md5 encrypted password are registered into pool_passwd.
-                 If pool_passwd does not exist yet, pg_md5 command will
-                 automatically create it for you.</li>
-            <li>The format of pool_passwd is "username:encrypted_passwd".</li>
-            <li>You also need to add an appropriate md5 entry to pool_hba.conf.
-                See <a href="#hba">Setting up pool_hba.conf for client authentication (HBA)</a>
-                for more details.</li>
-            <li>Please note that the user name and password must be
-                 identical to those registered in PostgreSQL.</li>
-            <li>After changing md5 password(in both pool_passwd and PostgreSQL of course),
-                you need to execute "pgpool reload" or restart pgpool(if your pgpool is 3.1 or before).</li>
-       </ol>
-    </li>
-    <li>In all the other modes, trust, clear text password, crypt, md5,
-        and pam methods are supported.</li>
-    </ul>
-
-<h2>Large objects</h2>
-<p>
-pgpool-II 2.3.2 or later supports large object replication if the backend is
-PostgreSQL 8.1 or later.
-For this, you need to
-enable <a href="#lobj_lock_table">lobj_lock_table</a> directive in pgpool.conf.
-Large object replication using backend function lo_import is not supported, however.
-</p>
-
-<h2 id="temp_table_in_master_slave_mode">Temporary tables in master/slave mode</h2>
-<p>
-Creating/inserting/updating/deleting temporary tables are always executed on the
-master(primary).
-With pgpool-II 3.0 or later, SELECT on these tables is executed on master as well.
-However if the temporary table name is used as a literal in SELECT, there's no
-way to detect it, and the SELECT will be load balanced.
-That will trigger a "not found the table" error or will find another table
-having same name.
-To avoid the problem, use /*NO LOAD BALANCE*/ SQL comment.
-</p>
-
-<pre>
-Sample SELECT which causes a problem:
-SELECT 't1'::regclass::oid;
-</pre>
-
-<p>
-psql's \d command uses literal table names.
-pgpool-II 3.0 or later checks if the SELECT includes any access to system
-catalogs and always send these queries to the master.
-Thus we avoid the problem.
-</p>
-
-<h2 id="caution_in_replication_mode">Functions, etc. In Replication Mode</h2>
-
-<p>There is no guarantee that any data provided using a context-dependent
-mechanism (e.g. random number, transaction ID, OID, SERIAL, sequence), will be
-replicated correctly on multiple backends.</p>
-<p>For SERIAL, enabling insert_lock will help replicating data.
-insert_lock also helps SELECT setval() and SELECT nextval().</p>
-
-<p>In pgpool-II 2.3 or later, INSERT/UPDATE using CURRENT_TIMESTAMP,
-CURRENT_DATE, now() will be replicated correctly. INSERT/UPDATE for tables
-using CURRENT_TIMESTAMP, CURRENT_DATE, now() as their DEFAULT values will also
-be replicated correctly.
-This is done by replacing those functions by constants fetched from master at
-query execution time.
-There are a few limitations however:
-</p>
-
-<ul>
-    <li>In pgpool-II 3.0 or before, the calculation of temporal data in table default value is not accurate
-        in some cases. For example, the following table definition:
-<pre>
-CREATE TABLE rel1(
-  d1 date DEFAULT CURRENT_DATE + 1
-)
-</pre>
-    is treated the same as:
-<pre>
-CREATE TABLE rel1(
-  d1 date DEFAULT CURRENT_DATE
-)
-</pre>
-    <p>
-    pgpool-II 3.1 or later handles these cases correctly.
-    Thus the column "d1" will have tomorrow as the default value.
-    However this enhancement does not apply if extended protocols(used in JDBC,
-    PHP PDO for example) or PREPARE are used.
-    </p>
-    <p>
-    Please note that if the column type is not a temporal one, rewriting is
-    not performed. Such example:
-    </p>
-<pre>
-foo bigint default (date_part('epoch'::text,('now'::text)::timestamp(3) with time zone) * (1000)::double precision)
-</pre>
-    </li>
-
-    <li>Suppose we have the following table:
-<pre>
-CREATE TABLE rel1(
-  c1 int,
-  c2 timestamp default now()
-)
-</pre>
-
-    We can replicate
-<pre>
-INSERT INTO rel1(c1) VALUES(1)
-</pre>
-
-    since this turn into
-<pre>
-INSERT INTO rel1(c1, c2) VALUES(1, '2009-01-01 23:59:59.123456+09')
-</pre>
-
-    However,
-<pre>
-INSERT INTO rel1(c1) SELECT 1
-</pre>
-    cannot to be transformed, thus cannot be properly replicated in the current implementation.
-    Values will still be inserted, with no transformation at all.
-    </li>
-</ul>
-
-<p>Tables created by <code>CREATE TEMP TABLE</code> will be deleted at the end of
-the session by specifying DISCARD ALL in reset_query_list if you are using
-PostgreSQL 8.3 or later.
-</p>
-<p>
-For 8.2.x or earlier, <code>CREATE TEMP TABLE</code> will not be
-deleted after exiting a session. It is because of the connection
-pooling which, from PostgreSQL's backend point of view, keeps the
-session alive. To avoid this, you must explicitly drop the
-temporary tables by issuing <code>DROP TABLE</code>, or use <code>CREATE TEMP
-TABLE ... ON COMMIT DROP</code> inside the transaction block.</p>
-
-<h2 id="ng_queries">Queries</h2>
-
-<p>Here are the queries which cannot be processed by pgpool-II</p>
-
-<h3 id="ng_multibyte_chars">Multi-byte Characters (for all modes)</h3>
-
-<p>pgpool-II does not translate between different multi-byte
-characters. The encoding for the client, backends must be
-the same.</p>
-
-<h3 id="ng_multi_statement">Multi-statement Query (for all modes)</h3>
-<p>
-pgpool-II cannot process multi-statement queries.
-</p>
-
-<h2>Environment Requirements</h2>
-
-<h3>libpq</h3>
-
-<p><code>libpq</code> is linked while building pgpool-II. libpq
-version must be 3.0. Building pgpool-II with libpq version 2.0 will
-fail.</p>
-
-<p class="top_link"><a href="#Top">back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1>Tutorial</h1>
-<p>
-<a href="tutorial-en.html">A tutorial for pgpool-II</a> is available.
-</p>
-
-<p class="top_link"><a href="#Top">back to top</a></p>
-
-</div>
-
-<div class="copyright" style="clear: both">
-<hr>
-<copyright>
-Copyright &copy; 2003 &ndash; 2016 pgpool Global Development Group
-</copyright>
-</div>
-</body>
-</html>
diff --git a/doc/pgpool-fr.html b/doc/pgpool-fr.html
deleted file mode 100644
index b56548235..000000000
--- a/doc/pgpool-fr.html
+++ /dev/null
@@ -1,4118 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">
-  <head>
-    <title>Manuel de l'utilisateur pgpool-II</title>
-    <meta http-equiv="Content-Type" content="text/HTML; charset=utf-8" />
-  </head>
-
-<!-- hhmts start -->
-Last modified: Sun Jan 30 09:14:28 JST 2011
-<!-- hhmts end -->
-
-<body bgcolor="#ffffff">
-<a name="top"></a>
-<table border="0" cellpadding="2" cellspacing="1">
-  <tr>
-    <td colspan="2" valign="top"><div class="header_text">Bienvenue sur la page de pgpool-II</div></td>
-  </tr>
-  <tr>
-    <td valign="top" style="border-right:1px dotted #cccccc;">
-	<br />
-
-	<div id="navcontainer">
-      <ul id="navlist">
-        <li id="active"><a href="#Whatis" id="current">pgpool-II</a></li>
-        <li><a href="#platform">Plates-formes</a></li>
-        <li><a href="#install">Installation de pgpool-II</a></li>
-        <li><a href="#config">Configuration de pgpool-II</a></li>
-        <li><a href="#common">Configuration des options communes</a></li>
-        <li><a href="#connection_pool_mode">Mode pooling de connexions</a></li>
-        <li><a href="#replication_mode">Mode Réplication</a></li>
-        <li><a href="#master_slave_mode">Mode Maître-Esclave</a></li>
-        <li><a href="#start">Arrêter/Démarrer pgpool-II</a></li>
-        <li><a href="#reload">Recharger les fichiers de configuration de pgpool-II</a></li>
-        <li><a href="#show-commands">Commandes SHOW</a></li>
-        <li><a href="#online-recovery">Online recovery</a></li>
-        <li><a href="#troubleshooting">Que faire en cas d'erreur</a></li>
-        <li><a href="#restriction">Restrictions</a></li>
-        <li><a href="#reference">Références</a></li>
-	<li><a href="#internal">Fonctionnement interne</a></li>
-      </ul>
-    </div>
-	<br />
-
-		<div class="header_small" align="center">
-
-			[<a href="pgpool-ja.html">Page Japonaise</a>]		</div>	</td>
-    <td valign="top" style="border-left:1px dotted #cccccc;">
-	
-
-
-
-<h1>pgpool-II<a name="whatis"></a></h1>
-
-<p>pgpool-II est un middleware qui se place entre les serveurs PostgreSQL
-et les clients de ces derniers. Voici ses différentes fonctionalités:</p>
-<p>
-<ul>
-
-<li>Pooling de connexions</li>
-    <p>pgpool-II maintient les connexions établies aux serveurs PostgreSQL
-    et les réutilise dès qu'une nouvelle connexion partageant les mêmes propriétés
-    (c'est-à-dire même utilisateur, même base de données et même version de
-    protocole) arrive. Il réduit ainsi le coût de la connexion et améliore
-    les performances générales du système.</p>
-
-<li>Réplication</li>
-    <p>pgpool-II peut gérer plusieurs serveurs PostgreSQL. En activant le
-    mode réplication, il devient possible de créer une sauvegarde continue sur
-    d'autres instances PostgreSQL, afin que le service puisse continuer sans
-    interruption si l'une de ces instances était défaillante.</p>
-
-<li>Répartition de charge</li>
-    <p>Si une base de données est répliquée, exécuter une requête en SELECT
-    sur n'importe lequel de ceux-ci retournera le même résultat. pgpool-II
-    profite ainsi avantageusement de la réplication pour réduire la charge
-    sur chacun des serveurs PostgreSQL. Il parvient à cela en distribuant
-    les requêtes SELECT entre tous les serveurs disponibles, ce qui qui 
-    améliore les performances générales du système. Dans un scénario
-    idéal, les performances en lecture s'améliorent proportionnellement au
-    nombre de serveurs PostgreSQL. La répartition de charge avec pgpool-II 
-    fonctionne au mieux dans un scénario où il y a beaucoup d'utilisateurs
-    qui exécutent beaucoup de requêtes en lecture au même moment.</p>
-
-<li>Limitation des connexions excédentaires</li>
-    <p>Dans PostgreSQL, il y a une limite maximum du nombre de connexions 
-    concurrentes au serveur (NDT: paramètre max_connections), et toutes les
-    nouvelles connexions sont rejettées une fois que ce nombre est atteint.
-    Augmenter ce nombre est possible mais accroît la consommation de 
-    ressources par le serveur et a un impact négatif sur les performances
-    générales du système. Bien que pgpool-II ait aussi une limite sur le
-    nombre de connexions maximum, il va mettre toute connexion excédentaire
-    dans une file d'attente au lieu de retourner immédiatement une erreur.</p>
-
-<li>Requêtes parallèlisées</li>
-    <p>En utilisant la fonctionalité des requêtes parallèlisées, les données
-    peuvent être réparties sur plusieurs serveurs afin que les requêtes
-    puissent être exécutées sur tous les serveurs à la fois, en réduisant
-    ainsi le temps d'exécution global de la requête. Cette fonctionalité 
-    donne les meilleurs résultats lorsqu'on cherche à extraire un très grand ensemble de 
-    données.</p>
-
-</ul>
-</p>
-
-<p>
-pgpool-II utilise le même protocole que le serveur et les clients 
-PostgreSQL, et relaie les messages entre les deux. Ainsi, une application
-cliente va prendre pgpool-II pour le serveur, et ce dernier va voir 
-pgpool-II comme une application cliente. Puisque pgpool-II est 
-complètement transparent, il peut-être utilisé pour une application
-sans pratiquement rien changer de son code source.</p>
-
-<p>
-<strong>Il y a cependant quelques restrictions à l'utilisation du SQL via
-pgpool-II. Veuillez vous reporter à la section <a href="#restriction">Restrictions</a> pour
-plus de détails.</strong>
-</p>
-
-<h1>Plates-formes supportées<a name="platform"></a></h1>
-
-<p>pgpool-II fonctionne sous Linux, Solaris, FreeBSD et la
-plupart des architectures UNIX. <b>Windows n'est pas supporté</b>.
-Les versions 6.4 et ultérieures de PostgreSQL sont supportées.
-Cependant, pour utiliser la fonctionalité de requêtage en 
-parallèle, vous devez avoir un serveur en version 7.4 ou 
-supérieure.</p>
-
-<p>Si vous utilisez PostgreSQL en version 7.3 ou inférieure, certaines
-fonctionnalités de pgpool-II ne seront pas disponibles. Cependant, vous
-ne devriez pas utiliser une si vieille version de toute façons.</p>
-
-<p>
-Vous devez aussi être certain que vos serveurs PostgreSQL sont tous dans la même 
-version majeure. De plus, les architectures matérielles et logicielles (systèmes
-d'exploitation) doivent-être identiques si vous voulez utiliser la technologie
-« online recovery ».
-</p>
-
-<h1>Installation de pgpool-II<a name="install"></a></h1>
-
-<p>
-pgpool-II est téléchargeable sur la <a href="http://pgfoundry.org/projects/pgpool/">page de développement 
-de pgpool</a>. Plusieurs packages sont aussi fournis pour diverses plates-formes incluant
-CentOS, RedHat Enterprise Linux, Fedora et Debian.
-</p>
-
-<p>
-Le code source de pgpool-II est téléchargeable sur la <a href="http://pgfoundry.org/projects/pgpool/">page de développement de pgpool</a>.
-</p>
-
-<p>Pour installer pgpool-II depuis son code source, vous aurez besoin de gcc,
-en version 2.9 ou supérieure, et de GNU make. pgpool-II utilisant la
-bibliothèque libpq de PostgreSQL, celle-ci doit aussi être installée ainsi 
-que les fichiers d'en-tête sur la machine utilisée pour compiler
-pgpool-II. Si vous souhaitez activer le support d'OpenSSL dans pgpool-II,
-il vous faudra aussi avoir cette bibliothèque ainsi que les fichiers d'en-tête
-relatifs installés sur la machine de compilation.</p>
-
-<dl>
-<dt>Configuration</dt>
-<dd>
-<p>
-Après avoir extrait les sources depuis l'archive, exécutez le script de 
-configuration comme suit.
-<pre>
-./configure
-</pre>
-
-Plusieurs options de configuration ont des valeurs par défaut,
-mais vous pouvez cependant les surcharger comme suit&nbsp;:
-
-<ul>
-  <li><code>--prefix=path</code><br/>
-      Les binaires de pgpool-II ainsi que sa documentation seront 
-      installés dans ce répertoire. La valeur par défaut est <code>/usr/local</code>.</li>
-  <li><code>--with-pgsql=path</code><br/>
-      Répertoire sous lequel les bibliothèques de PostgreSQL
-      sont installées. La valeur par défaut est fournie par
-      l'utilitaire <code>pg_config</code>.</li>
-  <li><code>--with-openssl</code><br/>
-      Avec cette option, les binaires de pgpool-II seront compilés
-      avec le support d'OpenSSL. Par défaut, le support d'OpenSSL
-      est désactivé.</li>
-</ul>
-</p>
-</dd>
-
-<dt>Compilation</dt>
-<dd>
-<p>
-<pre>
-make
-make install
-</pre>
-Ces deux commandes suffisent pour compiler et installer pgpool-II. Si vous
-utilisez Solaris ou FreeBSD, remplacez make par gmake.
-</p>
-</dd>
-
-<dt>Installation de pgpool_regclass</dt>
-<dd>
-<p>
-Si vous utilisez PostgreSQL 8.0 ou supérieur, l'installation des 
-fonctions pgpool_regclass, utiles à pgpool-II, est fortement
-recommandée. Sans celles-ci, le support de tables homonymes mais
-figurant dans des schémas différents pourrait ne pas fonctionner
-correctement (pour les tables temporaires, il n'y a aucun 
-problème).
-</p>
-<p>
-<pre>
-cd pgpool-II-x.x.x/sql/pgpool-regclass
-make
-make install
-psql -f pgpool-regclass.sql template1
-</pre>
-</p>
-<p>
-L'exécution du script pgpool-regclass.sql doit être faite sur toutes les
-bases qui sont accédées via pgpool-II.
-
-Vous n'avez pas besoin de le faire pour toutes les bases de données
-créées après l'exécution des commandes ci-dessus car la base template1
-est la base utilisée comme modèle par défaut pour les nouvelles bases
-de données sous PostgreSQL.
-</p>
-
-<dt>Installation de pgpool_walrecrunning</dt>
-<dd>
-<p>
-Si vous utilisez PostgreSQL 9.0 ou supérieur avec le « streaming replication »,
-vous aurez besoin d'installer la fonction pgpool_walrecrunning sur tous les
-serveurs PostgreSQL accedées par pgpool-II.
-</p>
-<p>
-<pre>
-cd pgpool-II-x.x.x/sql/pgpool-walrecrunning
-make
-make install
-psql -f pgpool-walrecrunning.sql template1
-</pre>
-</p>
-<p>
-L'exécution du script pgpool-walrecrunning.sql doit-être faite sur 
-toutes les bases de données accedées par pgpool-II.
-
-Comme précedemment, vous n'avez pas besoin de le faire pour toutes les bases de données
-créées après l'exécution des commandes ci-dessus car la base template1
-est la base utilisée comme modèle par défaut pour les nouvelles bases
-de données sous PostgreSQL.
-
-</p>
-
-</dl>
-
-<h1>Configuration de pgpool-II<a name="config"></a></h1>
-
-<p>Les fichiers de configuration par défaut de pgpool-II sont
-<code>/usr/local/etc/pgpool.conf</code> et
-<code>/usr/local/etc/pcp.conf</code>. Plusieurs modes de fonctionnement 
-sont disponibles sous pgpool-II. Chaque mode a des fonctionnalités 
-associées qui peuvent être activées ou désactivées, mais aussi configurées
-pour contrôler leur comportement.</p>
-
-<table border>
-
-  <tr>
-    <th>Fonction/Mode</th>
-    <th>Raw Mode (*3)</th>
-    <th>Mode réplication</th>
-    <th>Mode maître/esclave</th>
-    <th>Mode de requêtage en parallèle</th>
-  </tr>
-
-  <tr>
-    <td>Pooling de connexions</td>
-	<td align="center">X</td>
-	<td align="center">O</td>
-	<td align="center">O</td>
-	<td align="center">O</td>
-  </tr>
-
-  <tr>
-    <td>Réplication</td>
-	<td align="center">X</td>
-	<td align="center">O</td>
-	<td align="center">X</td>
-	<td align="center">(*1)</td>
-  </tr>
-
-  <tr>
-    <td>Répartition de charge</td>
-	<td align="center">X</td>
-	<td align="center">O</td>
-	<td align="center">O</td>
-	<td align="center">(*1)</td>
-  </tr>
-
-  <tr>
-    <td>Failover</td>
-	<td align="center">O</td>
-	<td align="center">O</td>
-	<td align="center">O</td>
-	<td align="center">X</td>
-  </tr>
-
-  <tr>
-    <td>Online recovery</td>
-	<td align="center">X</td>
-	<td align="center">0</td>
-	<td align="center">(*2)</td>
-	<td align="center">X</td>
-  </tr>
-
-  <tr>
-    <td>Requêtage en parallèle</td>
-	<td align="center">X</td>
-	<td align="center">X</td>
-	<td align="center">X</td>
-	<td align="center">O</td>
-  </tr>
-
-  <tr>
-    <td>Nombre de serveurs requis</td>
-	<td align="center">1 ou plus</td>
-	<td align="center">2 ou plus</td>
-	<td align="center">2 ou plus</td>
-	<td align="center">2 ou plus</td>
-  </tr>
-
-  <tr>
-    <td>Base de donnée système requise?</td>
-	<td align="center">non</td>
-	<td align="center">non</td>
-	<td align="center">non</td>
-	<td align="center">oui</td>
-  </tr>
-
-</table>
-
-<p>
-<ul>
- <li>0 signifie 'disponible' et X 'indisponible'
- <li>(*1) Le mode de requêtage en parallèle nécessite que la réplication et la
-     répartition de charge soient activés, cependant la réplication et la
-     répartition de charge ne peuvent pas être utilisés pour les tables distribuées en
-     mode de requêtage parallèlisé.
- <li>(*2) Le online recovery peut-être utilisé en mode maître/esclave avec
-     la « Streaming Replication ».
- <li>(*3) Les clients se connectent simplement aux serveurs PostgreSQL via 
-     pgpool-II. Ce mode est utile pour limiter simplement les connexions 
-     excédentaires aux serveurs, ou activer le failover avec de multiples
-     serveurs.
-</ul>
-</p>
-
-<h2>Configuration de <code>pcp.conf</code></h2>
-
-<p>Une interface de contrôle est fournie avec pgpool-II et permet à 
-l'administrateur de vérifier l'état de pgpool-II et d'arrêter les processus
-de pgpool-II à distance. <code>pcp.conf</code> est le fichier contenant 
-la définition des utilisateurs et de leurs mots de passe pour accéder
-à cette interface. Tous les modes d'utilisation de pgpool-II nécessitent
-que le fichier <code>pcp.conf</code> soit renseigné. Un fichier d'exemple
-<code>$prefix/etc/pcp.conf.sample</code> est créé lors de l'installation
-de pgpool-II. Renommez ce fichier en <code>pcp.conf</code>, ajoutez-y votre
-nom d'utilisateur ainsi que votre mot de passe.
-</p>
-
-<pre>
-cp $prefix/etc/pcp.conf.sample $prefix/etc/pcp.conf
-</pre>
-<p>
-Une ligne vide ou commençant par un dièse (<code>#</code>) est traitée comme un 
-commentaire et sera ignorée. Un nom d'utilisateur et son mot de passe
-doivent être écrits sur une seule ligne et respecter le format suivant&nbsp;:
-</p>
-<pre>
-nom_d_utilisateur:[mot de passe crypté en md5]
-</pre>
-<p>
-Le <code>[mot de passe crypté en md5]</code> peut être obtenu avec la 
-commande <code>$prefix/bin/pg_md5</code>.
-</p>
-
-<pre>
-pg_md5 -p
-password: &lt;votre mot de passe&gt;
-</pre>
-<p>
-ou
-</p>
-<pre>
-./pg_md5 foo
-acbd18db4cc2f85cedef654fccc4a4d8
-</pre>
-<p>
-Le fichier <code>pcp.conf</code> doit être lisible par l'utilisateur qui 
-exécute pgpool-II.</p>
-
-<h2>Configuration de <code>pgpool.conf</code></h2>
-
-<p>Comme cela a déjà été expliqué, chaque mode de pgpool-II a ses propres
-paramètres de configuration dans le fichier <code>pgpool.conf</code>. Un fichier
-d'exemple <code>$prefix/etc/pgpool.conf.sample</code> est créé lors de
-l'installation de pgpool-II. Renommez ce fichier en <code>pgpool.conf</code>
-et éditez son contenu.
-
-<pre>
-cp $prefix/etc/pgpool.conf.sample $prefix/etc/pgpool.conf
-</pre>
-<p>
-Toute ligne vide ou commençant par "#" sera traitée comme un commentaire et sera
-donc ignorée.</p>
-</p>
-<h3><a name="common"></a>Paramètres communs</h3>
-
-<dl>
-  <dt>listen_addresses</dt>
-  <dd>
-      <p>Spécifie le nom de la machine ou son adresse IP, sur laquelle
-      pgpool-II acceptera les connexions TCP/IP. <code>'*'</code> accepte
-      toutes les connexions. <code>''</code> empêchera toute connexion
-      TCP/IP. La valeur par défaut est <code>'localhost'</code>. Les connexions 
-      via les sockets UNIX sont toujours acceptées. Ce paramètre ne peut être
-      modifié qu'au démarrage du serveur.
-  </dd>
-      
-  <dt>port</dt>
-  <dd>
-      <p>Spécifie le numéro de port sur lequel pgpool-II écoute les 
-      connexions. La valeur par défaut est <code>9999</code>. Ce paramètre
-      ne peut être modifié qu'au démarrage du serveur.
-  </dd>
-
-  <dt>socket_dir</dt>
-  <dd>
-      <p>Répertoire dans lequel sera créé le socket UNIX de pgpool-II
-      pour les connexions entrantes. La valeur par défaut est
-      <code>'/tmp'</code>. Faites attention au fait que ce socket
-      pourrait être effacé par une tâche programmée en <code>cron</code>.
-      Aussi, nous vous recommandons de configurer cette valeur à 
-      <code>'/var/run'</code> ou un répertoire de ce type. Ce paramètre ne 
-      peut être modifié qu'au démarrage du serveur.</p>
-  </dd>
-
-  <dt>pcp_port</dt>
-  <dd>
-      <p>Numéro de port sur lequel le processus PCP accepte les connexions.
-      La valeur par défaut est <code>9898</code>. Ce paramètre ne peut être
-      modifié qu'au démarrage du serveur.</p>
-  </dd>
-
-  <dt>pcp_socket_dir</dt>
-  <dd>
-      <p>Chemin du répertoire UNIX où le socket UNIX acceptant les connexions
-      pour les commandes PCP est créé. La valeur par défaut est
-      <code>'/tmp'</code>. Faites attention au fait que cet socket
-      pourrait être effacé par une tâche programmée en <code>cron</code>.
-      Aussi, nous vous recommandons de configurer cette valeur à 
-      <code>'/var/run'</code> ou un répertoire de ce type. Ce paramètre ne 
-      peut être modifié qu'au démarrage du serveur.</p>
-  </dd>
-      
-  <dt>backend_socket_dir</dt>
-  <dd>
-      <p><font color="red"><em>À NE PLUS UTILISER</em>
-      Ce paramètre n'est présent que pour garantir la cohérence avec la
-      politique par défaut de la bibliothèque libpq. Reportez-vous à la définition du 
-      paramètre <code>backend_hostname</code> pour adapter votre configuration.
-      </font></p>
-      <p>Ce paramètre permettait de définir le répertoire UNIX servant au 
-      serveur PostgreSQL.</p>
-  </dd>
-
-  <dt>pcp_timeout</dt>
-  <dd>
-      <p>Délai maximum en secondes pour l'établissement d'une connexion PCP.
-      Si un client ne répond plus
-      au bout de cette valeur en secondes, le processus PCP ferme la connexion
-      avec le client. La valeur par défaut est de 10 secondes. 0 signifie que la
-      vérification du délai est désactivée. Ce paramètre est pris en compte lors
-      du rechargement des fichiers de configuration.</p>
-  </dd>
-
-  <dt>num_init_children</dt>
-  <dd>
-      <p>Nombre de processus pré-forkés de pgpool-II. La valeur par défaut
-      est de 32. <code>num_init_children</code> est aussi la limite du nombre
-      de connexions clientes concurrentes à pgpool-II. Si plus de
-      <code>num_init_children</code> clients essaient de se connecter à
-      pgpool-II, ceux-ci sont bloqués (mais pas rejettés), jusqu'à ce qu'une
-      connexion à l'un des processus de pgpool-II soit fermé. On peut avoir
-      ansi jusqu'à <b>deux fois <code>num_init_children</code></b> clients 
-      dans la queue de connexion.
-	  <p>Quelques précisions et astuces&nbsp;:</p>
-	   <p>
-	   <ul>
-		<li>L'annulation d'une requête crée une autre connexion au 
-                processus serveur PostgreSQL&nbsp;; ainsi, une requête ne
-                peut pas être annulée si toutes les
-                connexions sont utilisées. Si vous voulez vous assurer que les
-                requêtes puissent être annulées, positionnez cette valeur au 
-                double des connexions attendues.</li>
-
-		<li>PostgreSQL permet un certain nombre de connexions pour les
-                utilisateurs qui ne sont pas superutilisateurs. On le calcule
-                ainsi&nbsp;:<code>max_connections - superuser_reserved_connections</code></li>
-	   </ul>
-	   </p>
-	   <p>Pour résumer, <code>max_pool</code>,<code>num_init_children</code>,
-              <code>max_connections</code> et
-              <code>superuser_reserved_connections</code> doivent satisfaire
-              la formule suivante&nbsp;:
-	   </p>
-           <ul>
-	   <li>Si on n'a pas besoin de l'annulation de requêtes&nbsp;:
-	   <pre>max_pool*num_init_children <= (max_connections - superuser_reserved_connections)</pre></li>
-           <li>Si on a besoin de l'annulation de requêtes&nbsp;:
-<pre>max_pool*num_init_children*2 <= (max_connections - superuser_reserved_connections)</pre>
-	   </li>
-           </ul>
-           Ce paramètre ne peut être modifié qu'au démarrage du serveur.</p>
-	   </dd>
-
-  <dt>child_life_time</dt>
-  <dd>
-      <p>Durée de vie en secondes d'un processus fils de pgpool-II. Lorsqu'un 
-      processus fils est sans activité depuis ce nombre de secondes, il se
-      termine et un nouveau processus fils est créé. Ce paramètre est une
-      mesure pour prévenir tout problème de mémoire et autres erreurs 
-      inattendues. La valeur par défaut est 300 (5 minutes). Cette
-      fonctionalité est désactivée si cette option a une valeur de 0. Notez
-      que cela ne s'applique qu'aux processus qui n'ont
-      pas encore été utilisés ou qui n'ont pas encore accepté de connexions.
-      Vous devez recharger le fichier de configuration <code>pgpool.conf</code>
-      si vous changez cette valeur.
-      </p>
-  </dd>
-
-  <dt>child_max_connections</dt>
-  <dd>
-      <p>Un processus fils de pgpool-II sera terminé après avoir accepté ce
-      nombre de connexions clientes. Ce paramètre est 
-      utile sur un serveur à ce point chargé que ni
-      <code>child_life_time</code>, ni <code>connection_life_time</code>
-      ne sont déclenchés. Vous devez recharger pgpool-II si vous
-      changez cette valeur.
-      </p>
-  </dd>
-
-  <dt>client_idle_limit
-  <dd>
-  <p>Déconnecte un client s'il est resté inactif pendant ce nombre de secondes
-     après que la dernière requête ne se soit terminée. Ceci est utile pour
-     empêcher qu'un processus fils de pgpool-II ne soit occupé par un 
-     client inactif ou une connexion TCP/IP rompue entre le client et 
-     pgpool-II. La valeur par défaut de <code>client_idle_limit</code> est 
-     de 0, ce qui signifie que cette fonctionalité est désactivée. Ce paramètre
-     est ignoré dans la seconde phase d'un online recovery. Vous aurez besoin
-     de recharger pgpool-II si vous modifiez <code>client_idle_limit</code>.</p>
-
-  <dt>authentication_timeout
-  <dd>
-  <p>Spécifie le délai maximum en secondes pour terminer une authentification. 0 désactive 
-  cette fonctionnalité. Vous aurez besoin de redémarrer pgpool-II si vous changez cette
-  valeur.</p>
-
-  <dt>logdir</dt>
-  <dd>
-      <p>Répertoire utilisé pour les logs. <code>pgpool_status</code>
-         est écrit dans ce répertoire.</p>
-       </p>
-  </dd>
-  <dt>log_destination</dt>
-  <dd>
-      <p>pgpool-II utilise plusieurs méthodes pour écrire les messages du
-         serveur. Cela inclut stderr et syslog. La valeur par défaut est 
-         d'envoyer les messages à stderr.</p>
-      <p>Note: vous aurez besoin de modifier la configuration du serveur
-         syslog de votre système pour que l'écriture des messages vers 
-         syslog fonctionne. pgpool-II peut envoyer les traces à syslog en
-         utilisant les niveaux LOCAL0 à 
-         LOCAL7 (voir la documentation de syslog), mais la valeur par 
-         défaut de syslog sur la plupart des plates-formes ignorera de 
-         tels messages. Vous aurez donc besoin d'ajouter quelque-chose
-         comme
-	</p>
-	<pre>
-	local0.*    /var/log/pgpool.log
-	</pre>
-      <p>au fichier de configuration de votre démon syslog pour le faire
-         fonctionner.
-	</p>
-  </dd>
-
-  <dt>syslog_facility</dt>
-  <dd>
-      <p>Lorsque la sortie des messages vers syslog est configurée, ce paramètre
-         détermine le niveau syslog à utiliser. Vous pouvez choisir 
-         toute valeur entre LOCAL0 et LOCAL7. La valeur par défaut est LOCAL0.
-         Veillez à vous reporter à la documentation système au sujet de syslog.
-	</p>
-  </dd>
-
-  <dt>syslog_ident</dt>
-  <dd>
-      <p>Lorsque la sortie vers syslog est configurée, ce paramètre permet de
-         déterminer le nom du programme utilisé pour identifier les messages
-         de pgpool-II dans les traces enregistrées par syslog. La valeur par défaut est pgpool.
-	</p>
-  </dd>
-
-  <dt>pid_file_name</dt>
-  <dd>
-      <p>Chemin complet vers le fichier qui contient le numéro
-         d'identifiant du processus pgpool. La valeur par défaut
-         est "/var/run/pgpool/pgpool.pid".
-         Vous aurez besoin de redémarrer pgpool-II pour changer
-         cette valeur.
-       </p>
-  </dd>
-
-  <dt>print_timestamp</dt>
-  <dd>
-      <p>Ajoute un horodatage dans les traces lorsque cette valeur
-         est à true. La valeur par défaut est true. Vous aurez
-         besoin de recharger pgpool-II si vous changez cette valeur
-         afin qu'elle soit prise en compte.
-      </p>
-  </dd>
-
-  <dt>connection_cache</dt>
-  <dd>
-      <p>Cache les connexions à PostgreSQL lorsque 
-         cette valeur est configurée à true. La valeur par défaut 
-         est true.</p>
-  </dd>
-
-  <dt>health_check_timeout</dt>
-  <dd>
-      <p>pgpool-II essaie périodiquement de se connecter à PostgreSQL
-         afin de détecter toute erreur sur les serveurs
-         ou sur le réseau. Cette procédure de vérification d'erreurs
-         est appelée « health check ». Si une erreur est détectée, 
-         pgpool-II essaie d'exécuter un failover ou une dégénération.
-
-         Ce paramètre permet d'empêcher qu'un "health check" n'attende 
-         trop longtemps dans les cas où un câble réseau est débranché
-         par exemple. La valeur du paramètre est en secondes. La valeur
-         par défaut est de 20 secondes. 0 désactive cette fonctionnalité
-         (dans ce cas, pgpool-II attend jusqu'à la fin du délai maximum
-         configuré au niveau TCP/IP).
-
-         Cette vérification nécessite une connexion supplémentaire à 
-         chacun des serveurs PostgreSQL. Du coup, il faut le prendre en
-         compte dans la configuration du paramètre <code>max_connections</code>
-         de chaque serveur PostgreSQL. 
-
-         Vous aurez besoin de recharger pgpool-II après toute modification
-         de ce paramètre.
-     </p>
-  </dd>
-
-  <dt>health_check_period</dt>
-  <dd>
-      <p>Ce paramètre précise l'intervalle de temps entre deux
-       vérifications en secondes. La valeur par défaut est de 0,
-       ce qui a pour effet de désactiver la vérification. 
-       Vous aurez besoin de recharger pgpool-II après tout changement
-       de ce paramétrage. 
-       </p>
-  </dd>
-      
-  <dt>health_check_user</dt>
-  <dd>
-      <p>Nom de l'utilisateur PostgreSQL utilisé pour 
-         exécuter la vérification. Cet utilisateur doit exister
-         dans tous les serveurs PostgreSQL. Vous aurez besoin de 
-         recharger pgpool-II après tout changement de la valeur de 
-         ce paramètre.
-       </p>
-  </dd>
-
-<dt>failover_command
-<dd>
-<p>
-Ce paramètre spécifie la commande à exécuter lorsqu'un nœud est détaché. 
-pgpool-II remplace les caractères spéciaux suivants avec les informations 
-associées.
-</p>
-
-<blockquote>
-<table border>
-<tr><td>Caractère spécial</td><td>Description</td></tr>
-<tr><td>%d</td><td>ID du processus serveur correspondant au nœud détaché</td></tr>
-<tr><td>%h</td><td>Nom d'hôte du nœud détaché</td></tr>
-<tr><td>%p</td><td>Numéro de port du nœud détaché</td></tr>
-<tr><td>%D</td><td>Répertoire de l'instance PostgreSQL du nœud détaché</td></tr>
-<tr><td>%M</td><td>ID du nœud de l'ancien maître</td></tr>
-<tr><td>%m</td><td>ID du nœud du nouveau maître</td></tr>
-<tr><td>%H</td><td>Nom d'hôte du nouveau nœud maître</td></tr>
-<tr><td>%P</td><td>ID de l'ancien nœud primaire</td></tr>
-<tr><td>%%</td><td>Caractère '%'</td></tr>
-</table>
-</blockquote>
-<p>
-Vous devez recharger pgpool.conf si vous changez la valeur de 
-<code>failover_command</code>.
-</p>
-
-<p>
-Lorsqu'une commande failover est exécutée, pgpool tue tous ses processus fils,
-ce qui fermera toutes les sessions actives à pgpool. Alors, pgpool invoque la
-commande <code>failover_command</code> et attend son exécution complète. Après
-cela, pgpool démarre de nouveaux processus fils et est alors à nouveau
-disponible pour accepter des connexions depuis les clients.
-</p>
-
-<dt>failback_command
-<dd>
-<p>
-Ce paramètre contient une commande à exécuter lors qu'un nœud est attaché.
-pgpool-II remplace les caractères spéciaux suivants avec les informations
-associées.
-</p>
-<blockquote>
-<table border>
-<tr><td>Caractère spécial</td><td>Description</td></tr>
-<tr><td>%d</td><td>ID du processus serveur d'un nœud attaché</td></tr>
-<tr><td>%h</td><td>Nom d'hôte d'un nœud attaché</td></tr>
-<tr><td>%p</td><td>Numéro de port d'un nœud attaché</td></tr>
-<tr><td>%D</td><td>Répertoire de l'instance PostgreSQL d'un nœud attaché</td></tr>
-<tr><td>%M</td><td>Ancien nœud maître</td></tr>
-<tr><td>%m</td><td>Nouveau nœud maître</td></tr>
-<tr><td>%H</td><td>Nom d'hôte du nouveau nœud maître</td></tr>
-<tr><td>%P</td><td>ID de l'ancien nœud primaire</td></tr>
-<tr><td>%%</td><td>Caractère '%'</td></tr>
-</table>
-</blockquote>
-<p>
-Vous devez recharger pgpool.conf si vous changez le contenu de la
-commande <code>failback_command</code>.
-</p>
-
-  <dt>fail_over_on_backend_error</dt>
-  <dd>
-      <p>
-Si ce paramètre est à true et qu'une erreur apparaît lors d'une écriture sur le
-canal de communication d'un processus serveur, pgpool-II déclenchera une procédure de 
-failover. C'est le même comportement qu'avec les versions 2.2.x ou précédentes
-de pgpool-II. Si ce paramètre est à false, pgpool reportera une erreur dans ses
-fichiers de traces et déconnectera la session.
-Notez cependant que si ce paramètre est activé, pgpool effectuera aussi un
-failover lorsque la connexion à un processus serveur échoue ou lorsqu'il détecte l'arrêt
-du serveur PostgreSQL par un administrateur. Vous devez recharger pgpool.conf si vous
-changez cette valeur.
-</p>
-</dd>
-
-  <dt>ignore_leading_white_space</dt>
-  <dd>
-      <p>Si ce paramètre est activé, pgpool-II ignorera les espaces en début
-      de requête SQL lorsqu'il 
-      est dans le mode de répartition de charge. C'est 
-      particulièrement intéressant lorsqu'il est utilisé avec des API
-      comme DBI/DBD::Pg qui ajoutent des espaces sans que l'utilisateur
-      le demande. Vous aurez besoin de demander à pgpool-II de recharger
-      sa configuration pour que ce paramètre soit pris en compte.
-       </p>
-  </dd>
-
-  <dt>log_statement</dt>
-  <dd>
-      <p>Lorsque ce paramètre est activé, pgpool-II tracera les
-      requêtes SQL qu'il reçoit dans son fichier de traces. Cela va
-      produire des traces même si l'option debug n'est pas passée 
-      à pgpool-II au démarrage. Vous aurez besoin de recharger 
-      pgpool.conf pour que ce paramètre soit pris en compte.
-       </p>
-  </dd>
-
-  <dt>log_per_node_statement</dt>
-  <dd>
-      <p>Similaire à log_statement, à l'exception qu'il écrit les traces
-      de manière séparée par nœud. Cela peut se révéler très utile si vous
-      voulez vous assurer, par exemple, que votre réplication fonctionne. 
-      Vous aurez besoin de recharger pgpool.conf pour que ce paramètre
-      soit pris en compte.
-       </p>
-  </dd>
-
-  <dt>log_hostname</dt>
-  <dd>
-    <p>
-    Si ce paramètre est positionné à true, le nom de la commande affichée
-    dans la sortie de ps sera le nom de l'hôte plutôt que son IP. De même, si
-    log_connections est activé, le nom de l'hôte sera écrit dans les fichiers 
-    de trace plutôt que son IP. Ce paramètre est pris en compte au 
-    rechargement de pgpool.conf.
-    </p>
-  </dd>
-    
-  <dt>log_connections</dt>
-  <dd>
-    <p>
-    Si ce paramètre est à true, toutes les connexions entrantes seront
-    tracées dans les journaux applicatifs. Ce paramètre est pris en compte
-    au rechargement de pgpool.conf.
-    </p>
-  </dd>
-    
-  <dt>enable_pool_hba</dt>
-  <dd>
-    <p>
-    Si ce paramètre est à vrai, on utilisera le fichier pool_hba.conf pour 
-    l'authentification des clients. Voir la <a href="#hba">configuration
-de pool_hba.conf pour l'authentification des clients</a>. Ce paramètre 
-    est pris en compte au rechargement de pgpool-II. 
-    </p>
-  </dd>
-
-  <dt>backend_hostname</dt>
-  <dd>
-      <p>Permet de spécifier à quel serveur PostgreSQL on se connecte.
-      C'est utilisé par pgpool-II pour communiquer avec le serveur.
-      Ce paramètre n'est lu qu'au démarrage du serveur pgpool-II.    
-      </p>
-      <p>
-      Pour les communications TCP/IP, ce paramètre accepte soit un nom
-      d'hôte, soit une adresse IP. Si ce dernier commence avec un slash,
-      il spécifie un socket Unix plutôt qu'une adresse IP&nbsp;; la valeur est
-      alors le nom du répertoire dans lequel le fichier de socket UNIX est
-      stocké. Si ce paramètre est vide (<code>''</code>), le comportement par
-      défaut de pgpool-II est de se connecter à un socket UNIX stocké dans le
-      répertoire <code>/tmp</code>.
-      </p>
-      <p>
-      On peut spécifier ici plusieurs serveurs en ajoutant un nombre à la
-      fin du nom du paramète (par exemple <code>backend_hostname0</code>).
-      Ce nombre est l'identifiant du nœud au sein de pgpool-II. Le premier
-      nœud est toujours le nœud 0. Le serveur PostgreSQL qui se voit
-      attribuer l'identifiant 0 sera appelé le serveur maître. Lorsque plusieurs
-      serveurs sont définis et seulement pour certains modes, le service peut
-      continuer même si le serveur maître est arrêté. Dans ce
-      cas, c'est toujours le serveur qui a le plus petit identifiant de nœud
-      et qui est encore disponible qui est alors promu serveur maître.</p>
-
-      <p>Si vous pensez n'utiliser qu'un seul serveur PostgreSQL, spécifiez-le
-      avec <code>backend_hostname0</code>.</p>
-      <p>
-      De nouveaux serveurs PostgreSQL peuvent être ajoutés grâce à ce paramètre
-      mais Vous devez recharger le fichier de configuration. Par contre, les 
-      valeurs de ces paramètres ne pouvant être mises à jour, si vous les
-      changez, vous devrez alors redémarrer pgpool-II.
-      </p>
-  </dd>
-
-  <dt>backend_port</dt>
-  <dd>
-      <p>Spécifie le numéro de port des serveurs. Comme précédemment, on peut
-      spécifier le port de plusieurs serveurs en ajoutant à la fin du nom du 
-      paramètre l'identifiant du nœud (par exemple <code>backend_port0</code>).
-      Si vous n'utilisez qu'un seul serveur, vous devrez le spécifier par
-      <code>backend_port0</code>.</p>
-
-      <p>
-      Comme précédemment, vous pouvez ajouter de nouveaux paramètres concernant
-      de nouveaux nœuds, et alors, un rechargement de la configuration suffira.
-      Cependant, si vous mettez à jour des valeurs de paramètres existant, vous 
-      devrez redémarrer le serveur pgpool-II. 
-      </p>
-  </dd>
-
-  <dt>backend_weight</dt>
-  <dd>
-      <p>Spécifie le poids des serveurs pour la répartition de charge. 
-      On peut indiquer une valeur pour chacun des serveurs. Il suffit
-      pour cela d'ajouter le numéro du serveur à la fin du nom du 
-      paramètre (par exemple <code>backend_weight0</code>). Si vous 
-      n'utilisez qu'un seul serveur PostgreSQL, utilisez le paramètre
-      <code>backend_weight0</code>. Si vous êtes dans le mode RAW de pgpool-II,
-      mettez toujours cette valeur à 1.</p>
-      <p>
-      De nouveaux poids pour les backends peuvent être ajoutés pour de nouveaux
-      nœuds. Cependant, si vous mettez à jour des valeurs de paramètres existant, vous 
-      devrez redémarrer le serveur pgpool-II. 
-      </p>
-      <p>
-      À partir de pgpool-II 2.2.6/2.3, vous pouvez changer cette valeur par 
-      rechargement du fichier de configuration.
-      Le nouveau paramétrage prendra alors effet uniquement pour les nouvelles 
-      sessions clientes.
-      C'est très pratique si vous voulez empêcher toute requête envoyée aux 
-      serveurs esclaves de réaliser des tâches administratives en mode 
-      maître/esclave.
-      </p>
-  </dd>
-
-  <dt>backend_data_directory</dt>
-  <dd>
-      <p>Précise le répertoire des données des serveurs PostgreSQL.
-      Plusieurs serveurs peuvent être spécifiés en ajoutant
-      un nombre à la fin du nom de paramètre (par exemple 
-      <code>backend_data_directory0</code>).
-      Si vous ne pensez pas utiliser « online recovery », vous n'avez pas
-      besoin de spécifier ce paramètre.
-      </p>
-
-      <p>
-      Des spécifications de répertoires de données PostgreSQL additionnels 
-      peuvent être ajoutés par rechargement du fichier de configuration.
-      En revanche, leur valeur ne peut pas être mise à jour de cette façon.
-      Du coup, vous devrez redémarrer pgpool-II si vous modifiez la valeur d'un
-      paramètre déjà configuré.
-      </p>
-  </dd>
-
-  <dt><a name="ssl">ssl</a></dt>
-  <dd>
-      <p>
-      Si ce paramètre est à "true", le support de SSL est activé à la fois pour
-      les connexions clientes et les connexions aux serveurs PostgreSQL.
-      Notez que <code>ssl_key</code> et <code>ssl_cert</code>
-      doivent être renseignés pour que les connexions clientes puissent
-      fonctionner en SSL.
-      </p>
-
-      <p>
-      SSL est désactivé par défaut. Notez que le support d'OpenSSL doit
-      aussi avoir été configuré au moment de la compilation, comme c'est
-      mentionné dans la section <a href="#install">installation</a>.
-      </p>
-
-      <p>
-      Le démon de pgpool-II doit être redémarré lorsqu'on met à jour les
-      paramètres relatifs à SSL.
-      </p>
-  </dd>
-
-  <dt>ssl_key</dt>
-  <dd>
-      <p>
-      Chemin du fichier de clé privée pour les connexions clientes entrantes.
-      </p>
-
-      <p>
-      Il n'y a aucune valeur par défaut pour ce paramètre. S'il n'est pas modifié,
-      le support de SSL sera désactivé pour les connexions clientes
-      entrantes.
-      </p>
-  </dd>
-
-  <dt>ssl_cert</dt>
-  <dd>
-      <p>
-      Chemin complet vers le certificat public x509 à utiliser pour les 
-      connexions clientes entrantes.
-      </p>
-
-      <p>
-      Il n'y a aucune valeur par défaut pour ce paramètre. S'il n'est pas modifié,
-      le support de SSL sera désactivé pour les connexions clientes
-      entrantes.
-      </p>
-  </dd>
-
-  <dt>debug_level</dt>
-  <dd>
-      <p>
-      Niveau de verbosité des messages de débogage. 0 signifie aucun message,
-      plus grand que 1 engendre des messages plus verbeux. La valeur par défaut
-      est 0.
-      </p>
-  </dd>
-
-  <dt>relcache_expire</dt>
-  <dd>
-      <p>
-      Durée de vie en secondes d'une relation en cache. 0 signifie qu'il n'y 
-      a pas d'expiration (valeur par défaut).
-      Ce cache de relations est utilisé pour cacher le résultat de requêtes effectuées
-      sur le catalogue système de PostgreSQL pour obtenir diverses informations
-      comme la structure des tables ou pour savoir si telle ou telle table est temporaire.
-      Ce cache est maintenu dans une mémoire locale au processus fils de pgpool
-      et est gardé aussi longtemps que le processus est en vie.
-      Si un utilisateur modifie une table avec un ALTER TABLE, par exemple,
-      ce cache n'est alors plus cohérent.
-      À cet effet, le paramète relcache_expiration contrôle la durée de vie du 
-      cache.
-      </p>
-  </dd>
-  </dl>
-</dl>
-
-<h4>Génération de certificats SSL</h4>
-<p>
-La manipulation des certificats n'est pas couvert dans ce document. La page
-<a href="http://developer.postgresql.org/pgdocs/postgres/ssl-tcp.html">
-Secure TCP/IP Connections with SSL</a> (en anglais) sur le site 
-PostgreSQL.org référence des documents qui expliquent en détail
-les commandes à taper pour engendrer des certificats auto-signés.
-</p>
-
-<h4>Failover dans le mode Raw</h4>
-
-<p>Le failover peut être accompli dans le mode Raw si plusieurs serveurs
-sont définis. pgpool-II accède en général au serveur spécifié par
-<code>backend_hostname0</code> pendant son fonctionnement normal.
-Si le backend_hostname0 est en échec, quel que soit la raison, pgpool-II
-essaie d'accéder au serveur spécifié par backend_hostname1. En cas d'échec,
-pgpool-II essaie alors backend_hostname2, et ainsi de suite.
-</p>
-
-<h3><a name="connection_pool_mode"></a>Mode pooling de connexions</h3>
-
-<p>Dans le mode pooling de connexions, toutes les fonctions du mode 
-raw et du mode pooling de connexions peuvent être utilisées. Pour activer ce
-mode, configurez les paramètres du mode raw ainsi que les autres
-paramètres ci-après.</p>
-
-<dl>
-  <dt>max_pool</dt>
-  <dd>
-      <p>Nombre maximum de connexions en cache dans les processus
-      fils de pgpool-II. pgpool-II réutilise les connexions en cache si une 
-      connexion entrante se connecte à la même base de données avec le
-      même nom d'utilisateur. Sinon, pgpool-II crée une nouvelle connexion
-      au serveur PostgreSQL. Si le nombre de connexions en cache dépasse
-      max_pool, la plus vieille des connexions sera supprimée et on utilisera
-      cet emplacement ainsi libéré pour la nouvelle connexion.
-      
-      La valeur par défaut est 4. Faites bien attention au fait que le nombre
-      total de connexions des processus pgpool-II aux serveurs PostgreSQL
-      pourraient atteindre ainsi&nbsp;:
-      <code>num_init_children</code> * <code>max_pool</code>.
-      
-      Ce paramètre n'est pris en compte qu'au démarrage du serveur 
-      pgpool-II.
-      </p>
-  </dd>
-
-  <dt>connection_life_time</dt>
-  <dd>
-      <p>
-      Durée de vie en seconde d'une connexion en cache. Une 
-      connexion en cache dont la durée de vie expire sera alors déconnectée.
-      La valeur par défaut est 0, ce qui signifie que les connexions en cache 
-      ne seront jamais déconnectées.</p>
-  </dd>
-
-  <dt>reset_query_list</dt>
-  <dd>
-      <p>Spécifie les requêtes SQL envoyées à la connexion au serveur 
-      PostgreSQL lorsqu'une session se termine, côté client de pgpool-II.
-      Plusieurs commandes peuvent être spécifiées en les séparant par
-      un point-virgule. La valeur ci-dessous est la valeur par défault, 
-      mais elle peut être adaptée pour satisfaire vos besoins.
-
-      <pre>
-      reset_query_list = 'ABORT; DISCARD ALL'
-      </pre>
-
-<p>
-      Les commandes diffèrent dans chaque version de PostgreSQL. Voici les 
-      paramètres recommandés par version.
-      </p>
-<p>
-<table border>
-<tr><th>Version de PostgreSQL</th><th>reset_query_list value</th></tr>
-<tr><td>7.1 ou précédentes</td><td>ABORT</td></tr>
-<tr><td>7.2 à 8.2</td><td>ABORT; RESET ALL; SET SESSION AUTHORIZATION DEFAULT</td></tr>
-<tr><td>8.3 et suivantes</td><td>ABORT; DISCARD ALL</td></tr>
-</table>
-</p>
-<ul>
-<li>"ABORT" n'est pas envoyé en dehors d'un bloc de transactions à partir de la 7.4.
-</ul>
-
-<p>
-Vous aurez besoin de recharger pgpool.conf après toute modification de
-ce paramètre pour que sa nouvelle valeur soit prise en compte.
-</p>
-</dd>
-</dl>
-
-<h4><p>Le failover dans le mode pooling de connexions</p></h4>
-
-<p>Le failover dans le mode pooling de connexions est identique à celui du
-mode raw.</p>
-
-<h3><a name="replication_mode"></a>Mode réplication</h3>
-
-<p>Ce mode permet la réplication des données entre les serveurs PostgreSQL.
-Les paramètres de configuration ci-dessous doivent être renseignés, en plus
-de tout ce qui a été vu plus haut.
-</p>
-
-<dl>
-  <dt>replication_mode
-  <dd>
-      <p>Mettre ce paramètre à <code>true</code> active le mode de 
-      réplication. La valeur par défaut est <code>false</code>.
-      </p>
-  </dd>
-
-  <dt>load_balance_mode</dt>
-  <dd>
-      <p>Lorsque ce paramètre est à <code>true</code>, les requêtes de 
-      type SELECT sont distribuées à chaque serveur PostgreSQL pour 
-      obtenir une répartition de la charge entre les serveurs. La valeur
-      par défaut est  <code>false</code>.
-      </p>
-  </dd>
-
-  <dt>failover_if_affected_tuples_mismatch</dt>
-  <dd>
-	  <p>Lorsque ce paramètre est positionné à <code>true</code>,
-	  si les serveurs PostgreSQL ne retournent pas le même nombre de 
-	  lignes affectées lors d'un INSERT, UPDATE ou DELETE, les serveurs
-	  qui diffèrent de la valeur la plus fréquente sont « dégénérés »
-	  (NDT: ils ne sont alors plus jamais utilisés par pgpool-II, qui les 
-	  considère comme incohérents).
-	  Si ce paramètre est à <code>false</code>, la session est terminée
-	  et les serveurs PostgreSQL ne sont pas « dégénérés ». La valeur par
-	  défaut est à <code>false</code>.
-	  </p>
-  </dd>
-
-  <dt>replication_stop_on_mismatch</dt>
-  <dd>
-	  <p>Si ce paramètre est à <code>true</code> et si tous les serveurs
-	  PostgreSQL ne retournent pas le même type de paquet, les serveurs
-	  dont la valeur diffère du résultat le plus fréquent sont « dégénérés ».
-	  Un cas d'utilisation typique est une requête SELECT dans une
-	  transaction, avec replicate_select à <code>true</code>, qui 
-	  retournerait un nombre d'enregistrements différent suivant les 
-	  serveurs PostgreSQL.
-	  Les requêtes qui ne sont pas en SELECT pourraient aussi déclencher
-	  cette action. Par exemple, si un serveur PostgreSQL réussit un 
-	  UPDATE alors que les autres échouent.
-	  Notez que pgpool-II n'examine <b>pas</b> le contenu des
-	  enregistrements retournés par un SELECT.
-	  Si ce paramètre est à <code>false</code>, la session est terminée
-	  et les serveurs PostgreSQL ne sont pas « dégénérés ». La valeur par
-	  défaut est <code>false</code>.
-	  </p>
-  </dd>
-
-<a name="white_function_list"></a>
-<dt>white_function_list
-<dd>
-<p>
-Permet de spécifier une liste de noms de fonctions, séparées par des virgules,
-qui ne font <strong>pas</strong> d'écritures dans la base de données.
-Tous les SELECTs qui font appel à des fonctions qui ne sont pas spécifiées 
-dans cette liste ne seront ainsi jamais répartis entre les serveurs PostgreSQL,
-ni même répliqués dans le mode réplication.
-Dans le mode maître/esclave, de tels SELECTs sont envoyés au maître
-(ou primaire) uniquement.
-</p>
-<p>
-Vous pouvez utiliser des expressions régulières dans la liste pour établir
-une correspondance à une famille de fonctions. Par exemple, si vous avez eu la
-bonne idée de préfixer toutes les fonctions de votre base qui ne font que
-des lectures avec 'get_' ou 'select_' par exemple, vous pourrez ainsi vous
-limiter à n'écrire que les deux expressions régulières dans ce paramètre&nbsp;:
-
-</p>
-<pre>
-white_function_list = 'get_.*,select_.*'
-</pre>
-</dd>
-
-<a name="black_function_list"></a>
-<dt>black_function_list
-<dd>
-<p>
-Permet de spécifier une liste de noms de fonctions, séparées par des virgules,
-qui <strong>font</strong> des écritures dans la base de données.
-Les SELECT qui utilisent les fonctions spécifiées dans cette liste ne seront 
-jamais répartis entre les serveurs PostgreSQL, ni répliqués dans le mode
-de réplication.
-Dans le mode maître/esclave, de tels SELECT sont envoyés uniquement au 
-maître.
-</p>
-<p>
-Vous pouvez utiliser des expressions régulières dans la liste pour établir une 
-correspondance avec une famille de fonctions. Par exemple, si vous avez eu la
-bonne idée de préfixer toutes les fonctions de votre base qui font 
-des écritures avec 'set_','update_','delete_' ou 'insert_' 
-par exemple, vous pourrez ainsi vous limiter à n'écrire que les
-expressions régulières suivantes dans ce paramètre&nbsp;:
-</p>
-<pre>
-black_function_list = 'nextval,setval,set_.*,update_.*,delete_.*,insert_.*'
-</pre>
-<p>
-<b>Attention</b>, une seule de ces deux listes ne peut être renseignée
-dans la configuration de pgpool-II. Autrement dit, vous devez opter pour l'un ou
-l'autre des paramètres&nbsp;: autoriser de manière explicite, ou interdire
-de manière explicite. De préférence, optez pour la sécurité d'autoriser
-explicitement, c'est-à-dire utiliser le paramètre white_function_list.
-En effet, en cas 
-d'oubli d'une fonction en écriture dans le paramètre black_function_list,
-vous risquez de  demander l'exécution d'une fonction en écriture sur un serveur 
-en lecture seule, dans le mode maître/esclave par exemple.
-</p>
-<p>
-Avant la version 3.0 de pgpool-II, les fonctions nextval() et setval() 
-étaient connues pour leurs écritures dans la base de données.
-Vous pouvez émuler ce comportement en utilisant les deux paramètres vus
-précédemment de la façon suivante&nbsp;:
-</p>
-<p>
-<pre>
-white_function_list = ''
-black_function_list = 'nextval,setval,lastval,currval'
-</pre>
-</p>
-<p>
-Notez que l'on a lastval() et currval() en plus des nextval() et setval().
-Bien que lastval() et currval() ne soient pas des fonctions qui provoquent des
-écritures, il vaux mieux les ajouter pour éviter toute erreur dans le cas où
-ces fonctions seraient accidentellement réparties entre les différents nœuds.
-Ainsi, les ajouter à la black_function_list permettra d'éviter qu'elles soient
-réparties.
-</p>
-</dd>
-
-<a name="replicate_select"></a>
-  <dt>replicate_select</dt>
-  <dd>
-      <p>Lorsque ce paramètre est à <code>true</code>, pgpool-II va répliquer
-      les SELECT dans le mode de réplication. Si c'est à <code>false</code>,
-      pgpool-II va les envoyer uniquement au serveur maître (primaire). La valeur
-      par défaut est <code>false</code>.</p>
-
-<p>
-Si une requête SELECT est à l'intérieur d'un bloc de transaction explicite, 
-replicate_select et load_balance_mode auront un effet sur le fonctionnement de
-la réplication. Les détails sont expliqués ci-dessous.
-</p>
-
-<p>
-<table border>
-
-<tr>
-<td>Le SELECT est à l'intérieur d'un bloc de transaction</td>
-<td>O</td>
-<td>O</td>
-<td>O</td>
-<td>N</td>
-<td>N</td>
-<td>N</td>
-<td>O</td>
-<td>N</td>
-</tr>
-
-<tr>
-<td>replicate_select = true</td>
-<td>O</td>
-<td>O</td>
-<td>N</td>
-<td>N</td>
-<td>O</td>
-<td>O</td>
-<td>N</td>
-<td>N</td>
-</tr>
-
-<tr>
-<td>load_balance_mode = true</td>
-<td>O</td>
-<td>N</td>
-<td>N</td>
-<td>N</td>
-<td>O</td>
-<td>N</td>
-<td>O</td>
-<td>O</td>
-</tr>
-
-<tr>
-<td>resultats (R:réplication, M:envoyé au maître uniquement, L:réparti)</td>
-<td>R</td>
-<td>R</td>
-<td>M</td>
-<td>M</td>
-<td>R</td>
-<td>R</td>
-<td>M</td>
-<td>L</td>
-</tr>
-</table>
-</p>
-  </dd>
-
-  <dt>insert_lock</dt>
-  <dd>
-      <p>Si on réplique une table qui utilise le type de données SERIAL,
-      la valeur du SERIAL pourrait être différente entre les serveurs
-      PostgreSQL. On peut éviter ce problème en verrouillant la table
-      de manière explicite (bien que le parallélisme des transactions sera
-      alors sévèrement dégradé). Pour arriver à cela, les 
-      changements suivants doivent être faits&nbsp;:
-
-      <pre>
-      INSERT INTO ...
-      </pre>
-      <p>
-      à
-      </p>
-      <pre>
-      BEGIN;
-      LOCK TABLE ...
-      INSERT INTO ...
-      COMMIT;
-      </pre>
-
-      <p>Lorsque <code>insert_lock</code> est à 
-      <code>true</code>, pgpool-II ajoute automatiquement
-      les requêtes ci-dessus à chaque fois qu'un INSERT est 
-      exécuté. Si on est alors déjà dans une transaction, il ajoute
-      alors simplement un LOCK TABLE.
-	</p>
-      <p>À partir de pgpool-II 2.2, la détection des tables qui ont 
-      un SERIAL ou non est automatique. Ainsi, seules les tables qui
-      ont un SERIAL sont verrouillées de manière exclusive.
-	</p>
-	   <p>
-	   pgpool-II 3.0 utilise désormais un verrou de ligne sur la relation
-	   de la séquence, plutôt qu'un verrou de table exclusif. Cela
-	   minimise les conflits sur les verrous, comme par exemple
-	   VACUUM (direct ou via autovacuum).
-	   </p>
-	   <p>
-	   Si vous souhaitez un contrôle plus fin (par 
-	   requête)&nbsp;:
-      </p>
-
-      <ol>
-	<li>positionnez <code>insert_lock</code> à <code>true</code>,  et 
-	    ajoutez <code>/*NO INSERT LOCK*/</code> au début d'une requête
-	    INSERT pour laquelle vous ne voulez pas qu'un verrou exclusif de 
-	    table ne soit ajouté.</li>
-
-	<li>positionnez <code>insert_lock</code> à <code>false</code>, et
-	     ajoutez <code>/*INSERT LOCK*/</code> au début d'une requête
-	     INSERT pour laquelle vous voulez provoquer un verrouillage 
-	     exclusif de la table.</li>
-      </ol>
-
-      <p>
-      La valeur par défaut est <code>false</code>. Si 
-      <code>insert_lock</code> est activé, les tests de régression pour
-      PostgreSQL 8.0 échoueront dans les transactions, droits, règles 
-      (rules) et ALTER TABLE. La raison en est que pgpool-II essaie de 
-      verrouiller une vue pour le test sur les règles, ce qui a pour conséquence
-      l'erreur suivante&nbsp;:</p>
-      <pre>
-      ! ERROR: current transaction is aborted, commands ignored until
-      end of transaction block
-      </pre>
-
-      <p>Par exemple, le test sur les transactions essaie un INSERT dans une
-      table qui n'existe pas, et pgpool-II essaie d'acquérir un verrou
-      exclusif avant cela. La transaction sera alors interrompue et la requête
-      d'INSERT qui suit produira le message ci-dessus.</p>
-
-<dt>recovery_user
-<dd>
-<p>
-Ce paramètre permet de spécifier l'utilisateur PostgreSQL à utiliser pour 
-le « online recovery ». Il peut être changé sans avoir besoin de redémarrer
-pgpool-II.
-</p>
-
-<dt>recovery_password
-<dd>
-<p>
-Ce paramètre permet de spécifier le mot de passe de l'utilisateur spécifié dans
-le paramètre ci-dessus, à savoir <code>recovery_user</code>, qui est utilisé
-lors du « online recovery ». Comme le paramètre précédent, il peut être changé 
-sans avoir à redémarrer le serveur pgpool-II.
-</p>
-
-<dt>recovery_1st_stage_command
-<dd>
-<p>
-Ce paramètre permet de préciser une commande à exécuter pour la première
-phase du « online recovery ». Le fichier de commandes spécifié ici doit être placé
-à la racine du répertoire des données de l'instance PostgreSQL, pour des
-raisons de sécurité.
-
-Par exemple, si <code>recovery_1st_stage_command = 'sync-command'</code>, 
-alors pgpool-II exécute <code>$PGDATA/sync-command</code>.
-
-Notez que pgpool-II <b>accepte</b> les connexions et les requêtes alors que
-<code>recovery_1st_stage command</code> est en cours d'exécution. On peut 
-ainsi lire et écrire dans la base de données pendant cette première phase du 
-« online recovery ».
-</p>
-<p>
-Ce paramètre peut être changé sans avoir à redémarrer pgpool-II.
-</p>
-
-<dt>recovery_2nd_stage_command
-<dd>
-<p>
-Ce paramètre spécifie une commande à exécuter lors de la deuxième phase
-du « online recovery ». Ce fichier de commandes doit être placé à la racine
-du répertoire des données de l'instance PostgreSQL pour des raisons de sécurité.
-
-Par exemple, si <code>recovery_2nd_stage_command = 'sync-command'</code>,
-alors pgpool-II exécute <code>$PGDATA/sync-command</code>.
-
-Notez que pgpool-II <b>n'accepte pas</b> de connexions ou d'exécution de
-requêtes pendant que <code>recovery_2nd_stage_command</code> est en
-cours d'exécution. Ainsi, si un client reste connecté pendant une longue période,
-rien ne sera exécuté. En effet, pgpool-II attends que tous les clients aient
-fermé leurs connexions pour exécuter cette seconde phase du « online recovery ».
-La commande n'est donc exécutée que lorsqu'il n'y a plus aucun client de
-connecté.
-</p>
-<p>
-Ce paramètre peut être changé sans redémarrer pgpool-II.
-</p>
-
-<dt>recovery_timeout
-<dd>
-<p>
-pgpool n'accepte plus de nouvelle connexion pendant la seconde phase du
-« online recovery ». Si un client essaie de se connecter à pgpool-II pendant un 
-« online recovery », il devra attendre la fin de ce dernier.
-</p>
-<p>
-Ce paramètre spécifie un délai au terme duquel le « online recovery » sera annulé
-s'il n'est pas terminé. Après l'annulation, pgpool-II acceptera alors de nouveau
-les connexions. La valeur <code>0</code> désactive cette fonctionnalité.
-</p>
-<p>
-Ce paramètre peut être changé sans avoir à redémarrer pgpool-II.
-</p>
-
-  <dt>client_idle_limit_in_recovery
-  <dd>
-  <p>Similaire à <code>client_idle_limit</code>. Cependant, il n'agit 
-         que lors de la seconde phase du « online recovery ». Un client qui aura 
-	 été inactif pendant <code>client_idle_limit_in_recovery</code> 
-	 secondes depuis sa dernière requête sera déconnecté.
-	 Ce paramètre permet d'éviter que le « online recovery » ne soit perturbé
-	 par un client inactif, ou si la connexion TCP/IP entre le client et 
-	 pgpool tombe de manière accidentelle (un câble réseau défectueux
-	 par exemple). Si ce paramètre est à <code>-1</code>, le client 
-	 est déconnecté immédiatement. La valeur par défaut de ce paramètre
-	 est <code>0</code>, ce qui signifie que cette fonctionalité est 
-	 désactivée.
-  </p>
-  <p>  Si vos clients sont très actifs, pgpool-II ne pourra jamais entrer dans
-           la seconde phase du « online recovery », quelle que soit la valeur de 
-	   <code>client_idle_limit_in_recovery</code> que vous aurez choisie.
-	   Dans ce cas, vous pouvez paramétrer <code>client_idle_limit_in_recovery</code>
-	   à <code>-1</code> afin que pgpool-II puisse déconnecter immédiatement
-	   des clients aussi actifs avant de passer à la seconde phase du « online
-	   recovery ».
-  </p>
-  <p>
-   Vous devez recharger la configuration de pgpool-II si vous changer la
-   valeur de <code>client_idle_limit_in_recovery</code>.</p>
-
-<dt><a name="lobj_lock_table"></a>lobj_lock_table
-<dd>
-<p>
-Ce paramètre spécifie un nom de table utilisé pour le contrôle de la
-réplication des « large objects ». Si elle est spécifiée, pgpool-II verrouillera
-cette table, et génèrera un identifiant de « large object » en regardant
-dans la table pg_largeobject du catalogue système, et enfin, appellera 
-lo_create pour créer le « large object ».
-Cette procédure garantie que pgpool-II obtiendra le même identifiant de
-« large object » sur tous les serveurs PostgreSQL lorsque pgpool-II est dans
-le mode réplication. Notez que PostgreSQL 8.0 et ultérieur n'a plus de fonction
-lo_create. Du coup, cette fonctionalité est pas utilisable pour ces versions.
-</p>
-<p>
-Un appel à la fonction de la libpq lo_creat() utilisera cette fonctionalité. De
-même, la création de « large objects » via l'API Java (driver JDBC) devrait
-fonctionner, tout comme l'API PHP (pg_lo_create, ou API similaire dans 
-la bibliothèque de PHP, comme PDO), et ce genre d'API similaires dans 
-plusieurs langages de programmation qui sont réputées pour utiliser un 
-protocole similaire.
-</p>
-<p>
-Les opérations suivantes de création d'un « large object » ne fonctionneront pas&nbsp;:
-<p>
-<ul>
-<li>lo_create de la libpq
-<li>l'API d'un langage qui utilise lo_create
-<li>la fonction lo_import dans le serveur PostgreSQL
-<li>SELECT lo_creat
-</ul>
-</p>
-<p>
-Peu importe le schéma où est stockée la table <code>lobj_lock_table</code>, 
-celle-ci doit en revanche être accessible en écriture à tous les utilisateurs.
-Voici un exemple de création d'une telle table&nbsp;:
-</p>
-<p>
-<pre>
-CREATE TABLE public.my_lock_table ();
-GRANT ALL ON public.my_lock_table TO PUBLIC;
-</pre>
-</p>
-<p>
-La table spécifiée par <code>lobj_lock_table</code> doit être créée à 
-l'avance. Vous pouvez par exemple la créer dans la base <code>template1</code>
-afin que toute base de données créée par la suite en dispose.
-</p>
-<p>
-Si <code>lobj_lock_table</code> contient une chaîne vide (<code>''</code>),
-la fonctionalité est désactivée. Du coup, la réplication des « large objects »
-ne fonctionnera pas.
-
-La valeur par défaut de ce paramètre est justement la chaîne vide (<code>''</code>).
-</p>
-
-</dl>
-
-<h4><p>Pré-requis pour la répartition de charge</p></h4>
-<p>
-Pour qu'une requête soit répartie, les pré-requis suivants 
-doivent être respectés&nbsp;:
-<ul>
-	<li>Version 7.4 ou ultérieure de PostgreSQL</li>
-	<li>La requête ne doit pas être déclarée explicitement 
-	(c'est-à-dire qu'on ne doit pas être dans un bloc
-	BEGIN ~ END)</li>
-    <li>Il ne s'agit pas d'un SELECT nextval ou d'un SELECT setval
-    <li>Il ne s'agit pas d'un SELECT INTO
-    <li>Il ne s'agit pas d'un SELECT FOR UPDATE ou FOR SHARE
-    <li>La requête commence par un SELECT ou COPY TO STDOUT, EXPLAIN, EXPLAIN ANALYZE SELECT...
-    le paramètre <code>ignore_leading_white_space = true</code> permettra 
-    d'ignorer tous les éventuels espaces présents avant la requête.
-</ul>
-</p>
-<p>
-Notez que vous pouvez interdire de manière explicite la répartition d'une charge sur
-une requête SELECT en ajoutant un commentaire au début de la requête SELECT (quel que ce
-soit ce commentaire). Par exemple&nbsp;:
-<pre>
-  /*REPLICATION*/ SELECT ...
-</pre>
-</p>
-
-<p>
-Merci de lire attentivement la page 
-<a href="#replicate_select">replicate_select</a> au sujet de la réplication.
-De même, étudiez attentivement ce 
-<a href="where_to_send_queries.pdf">schéma</a> qui explique comment
-pgpool-II détermine à quel serveur PostgreSQL envoyer telle ou telle requête.
-</p>
-
-<p>
-<font color="red">
-Attention&nbsp;: le connecteur JDBC a une option autocommit. Si autocommit est à
-<code>false</code>, le connecteur JDBC envoie un BEGIN et un COMMIT
-lui-même. Ainsi, pgpool-II ne pourra faire aucune répartition de charge. Vous devez
-alors appeler <code>setAutoCommit(true)</code> pour activer 
-l'autocommit.
-</font>
-</p>
-
-<h4><p>Failover dans le mode Réplication</p></h4>
-
-<p> pgpool-II désactive un serveur « mort » et le service continue,  à condition
-qu'il y ait au moins un serveur PostgreSQL en vie.
-</p>
-
-<h3><a name="master_slave_mode"></a>Mode Maître-Esclave</h3>
-
-<p>Ce mode est utilisé lorsque pgpool-II est couplé avec un autre outil
-de réplication de type maître/esclave(s) (comme Slony-I ou le Streaming
-Réplication intégré à PostgreSQL). Cet outil est alors responsable de la 
-réplication des données.
-
-L'information sur les serveurs PostgreSQL doit être renseignée (les paramètres
-backend_hostname, backend_port, backend_weight et backend_data_directory), 
-de la même façon que dans le mode réplication.
-
-De plus, il faut paramétrer <code>master_slave_mode</code> et 
-<code>load_balance_mode</code> à <code>true</code>.
-
-pgpool-II enverra alors les requêtes qui doivent être répliquées au serveur
-PostgreSQL maître, et les autres requêtes seront réparties parmi les différents
-serveurs lorsque c'est possible.
-
-L'algorithme de pgpool-II prend bien sûr en compte les requêtes qui ne peuvent être
-réparties&nbsp;; elles sont alors systématiquement envoyées au serveur maître.</p>
-
-<p>Dans le mode maître-esclave, les DDL et DML pour une table temporaire ne
-peuvent être exécutées que sur le serveur maître.
-
-Vous pouvez forcer un SELECT à ne s'exécuter que sur le maître en ajoutant un 
-commentaire <code>/*NO LOAD BALANCE*/</code> devant le SELECT.</p>
-
-<p>Dans le mode maître-esclave, vous devez positionner 
-<code>replication_mode</code> à <code>false</code> et 
-<code>master_slave_mode</code> à <code>true</code>.</p>
-
-<p>Le mode maître-esclave a un sous-mode piloté par le paramètre
-<code>'master_slave_sub_mode'</code>. Il vaut par défaut
-<code>slony</code> et convient si vous utilisez Slony-I.
-
-Vous pouvez aussi le paramétrer à <code>stream</code> si 
-vous utilisez le système de réplication intégré à PostgreSQL (le 
-Streaming Replication).
-
-Le fichier de configuration d'exemple pour le sous-mode Slony-I
-est <code>pgpool.conf.sample-master-slave</code>, et celui
-concernant la Streaming Replication est 
-<code>pgpool.conf.sample-stream</code>.
-</p>
-<p>
-Vous devez redémarrer pgpool-II si vous changez l'un des paramètres
-vu précédemment.
-</p>
-<p>
-Vous devrez probablement aussi renseigner les paramètres
-<code>white_function_list</code> et 
-<code>black_function_list</code> si vous voulez contrôler plus finement
-la répartition de charge dans le mode maître-esclave.
-Reportez-vous à <a href="#white_function_list">white_function_list</a> 
-pour plus de détails.
-</p>
-
-<h4>Streaming Replication</h4>
-<p>
-Comme nous l'avons vu précédemment, pgpool-II peut fonctionner de pair avec
-la Streaming Replication, qui est disponible depuis la version 9.0 de PostgreSQL.
-Pour l'utiliser, il faut activer le paramètre master_slave et positionner le
-paramètre master_slave_sub_mode1 à stream. pgpool-II suppose que le Streaming
-Replication fonctionne et que les serveurs PostgreSQL esclaves sont en Hot
-Standby, ce qui signifie que les bases de données sont ouvertes en lecture
-seule sur ces derniers.
-
-Les directives suivantes peuvent être utilisées dans ce mode&nbsp;:
-</p>
-<p>
-<ul>
-<li>delay_threshold
-<p>
-Permet de spécifier le décalage maximum toléré entre le serveur maître et 
-un serveur esclave dans une réplication, exprimé en octets de journaux de
-transactions.
-Si le décalage dépasse <code>delay_threshold</code>, pgpool-II n'envoie
-alors plus de SELECT au serveur(s) esclave(s). Tout est alors envoyé au serveur
-maître, même si la répartition de charge est activée, jusqu'à ce que le(s) serveur(s) 
-esclave(s) soit(soient) en deçà du décalage maximum autorisé.
-
-Si <code>delay_threshold</code> est à <code>0</code> ou si le test 
-de vie est désactivé, ce test de décalage n'est jamais fait. Ce dernier est 
-effectué tous les <code>health_check_period</code>. La valeur par défaut
-pour <code>delay_threshold</code> est <code>0</code>.
-
-Vous devez recharger la configuration de pgpool-II si vous changez cette 
-directive.
-</p>
-
-<li>log_standby_delay
-<p>
-Permet de spécifier comment le décalage de réplication est tracé dans le 
-journal applicatif de pgpool-II. Si <code>none</code> est spécifié ici, 
-rien n'est écrit. Si <code>always</code> est spécifié, alors le décalage 
-sera tracé à chaque fois que le test est effectué.
-Si <code>if_over_threshold</code> est spécifié, alors le décalage est 
-tracé uniquement lorsqu'il dépasse le <code>delay_threshold</code>.
-La valeur par défaut pour <code>log_standby_delay</code> est 
-<code>none</code>.
-
-Vous devez recharger la configuration de pgool-II si vous changez ce 
-paramètre.
-</p>
-<p>
-Vous pouvez aussi superviser le décalage éventuel de la réplication en 
-utilisant la commande "show pool_status".
-</p>
-</ul>
-</p>
-
-<h4>Le failover avec la Streaming Replication</h4>
-<p>
-Dans le mode maître/esclave avec la Streaming Replication, si le 
-nœud primaire ou le nœud en attente s'arrête, pgpool-II peut être 
-configuré pour exécuter un Failover.
-Les nœuds peuvent alors être attachés automatiquement sans 
-configuration ou opérations complémentaires.
-Alors qu'il est en pleine réplication [~], le nœud en attente vérifie 
-régulièrement si un fichier de déclenchement existe. S'il le trouve,
-le nœud en attente sort de son mode réplication et s'ouvre en mode 
-lecture/écriture. En utilisant ce mécanisme, on peut avoir une base 
-de données en attente qui prends le relais quand le nœud primaire
-tombe.
-</p>
-<p>
-<strong>Attention&nbsp;: si vous pensez utiliser plusieurs nœuds en mode
-standby, il est recommandé de définir le paramètre delay_threshold pour 
-empêcher tout requête dirigée vers d'autres nœuds en standby de
-récupérer des données plus vieilles.</strong>
-</p>
-<p>
-Si un second nœud en standby prends le relais quand le premier
-nœud en standby avait déjà pris le relais, vous pourriez avoir 
-des données erronnées en provenance du second standby. 
-Nous vous recommandons de ne pas utiliser ce genre de configuration.
-</p>
-<p>
-Voici commment configurer un mécanisme de Failover.
-</p>
-<p>
-<ol>
- <li>Il faut créer un script de Failover quelque part sur le système,
- par exemple dans /usr/local/pgsql/bin, puis le rendre exécutable.
- 
-<pre>
-$ cd /usr/loca/pgsql/bin
-$ cat failover_stream.sh
-#! /bin/sh
-# Commandes pour faire un Failover en mode Streaming Replication
-# Ce script suppose que le nœud Maitre est le 0 et 1 le standby
-# 
-# Si le Standby s'arrête, ne rien faire. Si le Primaire s'arrête, créer
-# un fichier de déclenchement afin que le standby prenne le relais sur le 
-# nœud Primaire.
-#
-# Arguments: 
-#   $1: identifiant du nœud qui ne répond plus
-#   $2: nom d'hôte du nouveau maître 
-#   $3: chemin vers le fichier trigger 
-
-failed_node=$1
-new_master=$2
-trigger_file=$3
-
-# Ne rien faire si c'est le standby qui tombe
-if [ $failed_node = 1 ]; then
-	exit 0;
-fi
-
-# Créer un fichier de déclenchement
-/usr/bin/ssh -T $new_master /bin/touch $trigger_file
-
-exit 0;
-
-chmod 755 failover_stream.sh
-</pre>
-<li>Il faut à présent définir la commande failover_commmand 
-dans le fichier pgpool.conf&nbsp;:
-<pre>
-failover_command = '/usr/local/src/pgsql/9.0-beta/bin/failover_stream.sh %d %H /tmp/trigger_file0'
-</pre>
-
-<li>Et créer le fichier recovery.conf sur le nœud en standby. Un
-<a href="recovery.conf.sample">exemple de fichier recovery.conf</a> 
-est disponible dans le répertoire d'installation de PostgreSQL. 
-Son nom complet est "share/recovery.conf.sample".
-Copier recovery.conf.sample en recovery.conf dans le répertoire de base
-de PostgreSQL et l'éditer comme suit.
-<pre>
-standby_mode = 'on'
-primary_conninfo = 'host=nom_du_nœud_primaire user=postgres'
-trigger_file = '/tmp/trigger_file0'
-</pre>
-
-<li>Ajuster le postgresql.conf sur le nœud primaire. La configuration
-ci-dessous est donneé à titre indicatif, vous devrez probablement
-l'ajuster pour votre environnement.
-<pre>
-wal_level = hot_standby
-max_wal_senders = 1
-</pre>
-
-<li>Définir pg_hba.conf sur le nœud Primaire. La configuration
-ci-dessous est donnée à titre indicatif, vous devrez probablement
-l'ajuster pour votre environnement.
-<pre>
-host	replication	postgres		192.168.0.10/32		trust
-</pre>
-
-</ol>
-
-<p>
-Démarrez PostgreSQL sur les nœuds primaire et secondaire pour initialiser
-la réplication. Si le nœud primaire venait à tomber, le nœud secondaire
-prendra automatiquement le relais, en tant que nouveau nœud primaire, et
-sera alors prêt à recevoir les requêtes en écriture.
-</p>
-
-<h4>Streaming Replication</h4>
-<p>
-Lorsqu'on utilise la Streaming Replication et le Hot Standby, il est important
-de déterminer les requêtes pouvant être envoyées sur le nœud principal ou 
-sur le nœud en standby (secondaire), et les requêtes qui ne peuvent pas l'être.
-Le mode Streaming Replication de pgpool-II se charge complètement de
-cette problématique.
-Dans ce chapitre, nous expliquerons comment pgpool-II parvient à cela.
-</p>
-<p>
-Nous distinguons les requêtes qui devraient être envoyées à tel ou tel
-nœud en les examinant.
-</p>
-<p>
-<ul>
- <li>Les requêtes suivantes devraient être envoyées au nœud primaire uniquement&nbsp;:
-	  <ul>
-	   <li>INSERT, UPDATE, DELETE, COPY FROM, TRUNCATE, CREATE, DROP, ALTER, COMMENT
-	   <li>SELECT ... FOR SHARE | UPDATE
-	   <li>SELECT dans un niveau d'isolation transactionnel de type SERIALIZABLE
-	   <li>LOCK, commande plus stricte que ROW EXCLUSIVE MODE
-	   <li>Quelques commandes transactionnelles&nbsp;:
-			<ul>
-			 <li>BEGIN READ WRITE, START TRANSACTION READ WRITE
-			 <li>SET TRANSACTION READ WRITE, SET SESSION CHARACTERISTICS AS TRANSACTION READ WRITE
-			 <li>SET transaction_read_only = off
-			</ul>
-	   <li>Les commandes relatives à la validation en deux phases&nbsp;: PREPARE TRANSACTION, COMMIT PREPARED, ROLLBACK PREPARED
-	   <li>LISTEN, UNLISTEN, NOTIFY
-	   <li>VACUUM
-	   <li>Quelques fonctions liées aux séquences (nextval et setval)
-	   <li>Les commandes de création de « Large Objects »
-	  </ul>
- <li>Ces requêtes peuvent être envoyées à la fois au nœud primaire et au
- nœud en standby. Si la répartition de charge est activée, ce type de requêtes
- peut être envoyé au nœud en standby.
- Cependant, si le paramètre delay_threshold est défini et que le délai dans la 
- réplication est supérieur au delay_threshold, les requêtes sont envoyées au
- nœud primaire.
-	  <ul>
-	   <li>tout SELECT non listé ci-dessus
-	   <li>COPY TO
-	   <li>DECLARE, FETCH, CLOSE
-	   <li>SHOW
-	  </ul>
- <li>Les requêtes suivantes sont envoyées à la fois au nœud primaire et secondaire&nbsp;:
-	  <ul>
-	   <li>SET
-	   <li>DISCARD
-	   <li>DEALLOCATE ALL
-	  </ul>
-</ul>
-</p>
-
-<p>
-Dans une transaction explicite&nbsp;:
-<ul>
- <li>Toute transaction commençant par une commande comme BEGIN est envoyée
- au nœud primaire.
- <li>Tout SELECT qui survient immédiatement après, ainsi que toutes les requêtes
- qui peuvent être envoyées aussi bien au primaire qu'au secondaire, sont réparties
- entre les nœuds.
- <li><p>
- Toute commande qui ne peut être exécutée sur un nœud en standby (secondaire)
- comme un INSERT sont envoyées uniquement au primaire.
- Après toute commande de ce type, absolument tous les ordres SQL sont envoyés
- au nœud primaire. En effet, les SELECT suivant pourraient vouloir voir les 
- résultats d'un INSERT immédiatement. 
-Ce comportement continue jusqu'à ce que la transaction se ferme ou soit 
-interrompue.
-</p>
-</ul>
-</p>
-
-<p>
-Dans le protocole étendu, il est possible de déterminer si la requête
-peut être envoyée au nœud en standby ou pas dans le mode de répartition de charge
-au moment où on analyse la requête. Les rêgles sont les mêmes que dans le
-protocole non-étendu.
-Par exemple, les INSERT sont envoyés au primaire, ainsi que toute requête
-qui suivra.
-</p>
-
-<p>
-Note&nbsp;: si l'analyse d'une requête en SELECT est envoyée sur le standby à 
-cause de la répartition de charge et qu'une requête en modification de données, comme
-un INSERT est envoyé à pgpool-II, alors le SELECT analysé devra être exécuté
-sur le nœud primaire. Cependant, on analyse de nouveau le SELECT sur le nœud primaire.
-
-<p>
-Enfin, les requêtes qui semblent douteuses ou possiblement en erreur sont 
-envoyées sur le nœud primaire.
-</p>
-
-<h4>Online recovery avec la Streaming Replication</h4>
-<p>
-Dans le mode maître/esclave avec la Streaming Replication, on peut procéder à une
-restauration à chaud (« Online recovery »).
-Cependant, seul un nœud en standby peut être ainsi récupéré. On ne peut pas
-reconstruire un nœud primaire. Pour ce faire, il faudra stopper toutes les
-bases de données, ainsi que pgpool-II, puis restaurer le nœud primaire à 
-partir d'une sauvegarde.
-</p>
-
-<p>
-Voici les étapes.
-<ol>
- <li>Définir le paramètre recovery_user. C'est souvent postgres.
-<pre>
-recovery_user = 'postgres'
-</pre>
-<li>Définir le paramètre recovery_password pour que le recovery_user 
-puisse se connecter à la base.
-<pre>
-recovery_password = 't-ishii'
-</pre>
-
-<li> Définir le paramètre recovery_1st_stage_command.
-Le script pour cette étape doit procéder à une sauvegarde 
-du nœud primaire et à sa restauration sur le nœud en standby.
-Placez ce script à l'intérieur du répertoire de données du nœud primaire
-et donnez-lui les droits nécessaires pour être exécutable.
-Un script d'exemple est disponible&nbsp;: <a href="basebackup.sh">basebackup.sh</a>,
-avec une configuration simple d'un primaire et d'un standby.
-Il faut configurer SSH pour que l'utilisateur indiqué dans le paramètre
-recovery_user puisse se connecter depuis le primaire vers le standby sans
-qu'un mot de passe ne soit demandé.
-<pre>
-recovery_1st_stage_command = 'basebackup.sh'
-</pre>
-<li>Laisser le paramètre recovery_2nd_stage_command vide.
-<pre>
-recovery_2nd_stage_command = ''
-</pre>
-
-<li>Installer à présent les fonctions C et SQL nécessaires dans chacune 
-des bases de données pour que le « online recovery » fonctionne.
-</p>
-
-<pre>
-# cd pgpool-II-x.x.x/sql/pgpool-recovery
-# make
-# make install
-# psql -f pgpool-recovery.sql template1
-</pre>
-
-<li>Après avoir terminé le « online recovery », pgpool-II démarre PostgreSQL
-sur le nœud standby.
-À cet effet, il faut installer un script sur chacun des nœuds.
-Un <a href="pgpool_remote_start">script d'exemple</a> est inclus dans le
-répertoire sample du répertoire des sources.
-Ce script utilise SSH. Il faudra permettre à l'utilisateur indiqué dans
-le paramètre recovery_user de se connecter depuis le primaire vers le standby
-sans qu'un mot de passe ne soit demandé.
-</ol>
-</p>
-
-<p>
-C'est tout.
-On peut à présent utiliser pcp_recovery_node (dès qu'un nœud en standby
-s'arrête) ou alors cliquer sur le bouton « recovery » dans l'interface de 
-pgpoolAdmin pour exécuter un « Online Recovery ».
-</p>
-
-<h3>Mode parallèle</h3>
-
-<p>Ce mode permet l'exécution en parallèle de requêtes. Les tables 
-peuvent être découpées, et les données distribuées sur chaque nœud. De plus,
-les fonctionnalités de réplication et de répartition de charge peuvent être utilisées
-avec ce mode, en même temps. Dans le mode parallèle, replication_mode et 
-load_balance_mode sont positionnés à true dans le fichier pgpool.conf, alors
-que master_slave est positionné à false, et que parallel_mode est positionné
-à true. Si ce paramètre est changé, il faut redémarrer pgpool-II pour qu'il
-soit pris en compte. 
-</p>
-
-<h4><p>Configuration de la base système</p></h4>
-
-<p>Pour utiliser le mode parallèle, la base système doit être configurée
-correctement. La base système contient des règles, stockées dans une table,
-pour choisir le nœud PostgreSQL approprié auquel envoyer les données.
-La base de données système n'a pas besoin d'être créée sur le même nœud que
-pgpool-II. La configuration de cette dernière est faite dans
-<code>pgpool.conf</code>.</p>
-
-<dl>
-  <dt>system_db_hostname</dt>
-  <dd>
-      <p>Nom de l'hôte où la base de données système réside. Une chaîne vide
-      dans ce paramètre ('') signifie que celle-ci est sur le même nœud que
-      pgpool-II, et sera alors accédée via un socket UNIX.</p>
-  </dd>
-
-  <dt>system_db_port</dt>
-  <dd>
-      <p>Numéro de port de la base de données système</p>
-  </dd>
-
-  <dt>system_dbname</dt>
-  <dd>
-      <p>Les règles de partitionnement et autres informations seront définies
-      dans la base de données spécifiée ici. La valeur par défaut est
-      <code>'pgpool'</code>.</p>
-  </dd>
-
-  <dt>system_db_schema</dt>
-  <dd>
-      <p>Les règles de partitionnement et autres informations seront stockées
-      dans le schéma spécifié ici. La valeur par défaut est
-      <code>'pgpool_catalog'</code>.</p>
-  </dd>
-
-  <dt>system_db_user</dt>
-  <dd>
-      <p>Nom de l'utilisateur qui se connecte à la base de données système.</p>
-  </dd>
-
-  <dt>system_db_password</dt>
-  <dd>
-      <p>Mot de passe pour l'utilisateur de la base de données système. Si aucun mot de passe
-      n'est nécessaire, laissez une chaîne vide dans ce paramètre ('').</p>
-  </dd>
-
-  <dt>ssl_ca_cert</dt>
-  <dd>
-      <p>
-      Chemin complet vers un fichier au format PEM contenant un ou plusieurs
-      certificats CA, qui doivent être utilisés pour vérifier le certificat du 
-      serveur. C'est analogue à l'option <code>-CAfile</code> de la
-      commande <code>verify(1)</code> d'OpenSSL.
-      </p>
-
-      <p>
-      Il n'y a pas de valeur par défaut pour cette option. Du coup, aucune
-      vérification n'a lieu par défaut. Par contre, une vérification sera réalisée
-      si une valeur a été définie pour <code>ssl_ca_cert_dir</code>.
-      </p>
-  </dd>
-
-  <dt>ssl_ca_cert_dir</dt>
-  <dd>
-      <p>
-      Chemin vers un répertoire qui contient les certificats CA au format PEM,
-      qui peuvent être utilisés pour vérifier le certificat du serveur. 
-      C'est analogue à l'option <code>-CAfile</code> de la commande
-      <code>verify(1)</code> d'OpenSSL.
-      </p>
-
-      <p>
-      Il n'y a pas de valeur par défaut pour cette option. Du coup, aucune
-      vérification n'a lieu par défaut. Par contre, une vérification sera réalisée
-      si une valeur a été définie pour <code>ssl_ca_cert</code>.
-      </p>
-  </dd>
-
-</dl>
-
-<h4><p>Configuration initiale de la base de données système</p></h4>
-
-<p>Il faut d'abord créer la base de données et le schéma spécifiés dans le
-fichier <code>pgpool.conf</code>. Un script d'exemple peut être trouvé dans
-<code>$prefix/share/system_db.sql</code>. Si vous avez indiqué un nom
-différent pour la base de données ou le schéma, adaptez ce script en 
-conséquence.
-<pre>
-psql -f $prefix/share/system_db.sql pgpool
-</pre>
-
-</p>
-
-<h4><p>Enregistrement d'une règle de partitionnement</p></h4>
-
-<p>Les règles pour le partitionnement des données doivent être enregistrées
-dans la table <code>pgpool_catalog.dist_def</code>.</p>
-
-<pre>
-CREATE TABLE pgpool_catalog.dist_def(
-dbname TEXT,                                              -- nom de la base
-schema_name TEXT,                                         -- nom du schéma
-table_name TEXT,                                          -- nom de la table
-col_name TEXT NOT NULL CHECK (col_name = ANY (col_list)), -- nom de la colonne 
-de la clé de partitionnement
-col_list TEXT[] NOT NULL,                                 -- noms des
-attributs de la table
-type_list TEXT[] NOT NULL,                                -- types de
-données de la table des attributs
-dist_def_func TEXT NOT NULL,                              -- nom de la
-fonction pour la règle de partitionnement
-PRIMARY KEY (dbname,schema_name,table_name)
-);
-</pre>
-
-
-<h4><p>Enregistrement d'une règle de réplication</p></h4>
-<p>
-Les tables qui ne sont pas distribuées doivent être répliquées. Lorsqu'une 
-requête fait la jointure d'une table distribuée avec une autre table, pgpool
-récupère l'information de réplication dans la table  pgpool_catalog.replicate_def.
-Ainsi, une table est soit répliquée, soit ditribuée.
-</p>
-
-<pre>
-CREATE TABLE pgpool_catalog.replicate_def(
-	dbname TEXT,	    --nom de la base
-	schema_name TEXT,	--nom du schéma
-	table_name TEXT,	--nom de la table
-	col_list TEXT[] NOT NULL,	-- nom des attributs de la table
-	type_list TEXT[] NOT NULL,	-- types de données des attributs de
-la table
-	PRIMARY KEY (dbname,schema_name,table_name)
-);
-</pre>
-
-<h4><p>Exemple basé sur le partitionnement des tables de pgbench</p></h4>
-
-<p>pgbench est un outil simple de tests de performance de PostgreSQL, disponible 
-dans le répertoire contrib de PostgreSQL.</p>
-
-<p>
-Dans cet exemple, la table accounts est partitionnée, les tables
-branches et tellers sont répliquées.
-Les tables accounts et branches sont jointes sur la colonne bid.
-La table branches est enregistrée dans la table de réplication.
-Si les trois tables (accounts, branches et tellers) doivent être jointes,
-il est nécessaire d'enregistrer aussi une règle de réplication pour la table 
-tellers.
-</p>
-
-<pre>
-INSERT INTO pgpool_catalog.dist_def VALUES (
-	'pgpool',
-	'public',
-	'accounts',
-	'aid',
-	ARRAY['aid','bid','abalance','filler'],
-	ARRAY['integer','integer','integer','character(84)'],
-	'pgpool_catalog.dist_def_accounts'
-);
-
-INSERT INTO pgpool_catalog.replicate_def VALUES (
-	'pgpool',
-	'public',
-	'branches',
-	ARRAY['bid','bbalance','filler'],
-	ARRAY['integer','integer','character(84)']
-);
-</pre>
-
-<p>La règle de partitionnement (ici, pgpool_catalog.dist_def_accounts) prends
-une valeur pour la colonne qui sert de clé de partitionnement, et retourne le
-numéro du nœud de la base de données correspondante. Notez que l'identifiant
-des nœuds doit commencer par 0. Voici un exemple de cette fonction pour 
-pgbench.
-</p>
-<pre>
-CREATE OR REPLACE FUNCTION pgpool_catalog.dist_def_accounts (val ANYELEMENT) RETURNS INTEGER AS '
-SELECT CASE WHEN $1 >= 1 and $1 <= 30000 THEN 0
-WHEN $1 > 30000 and $1 <= 60000 THEN 1
-ELSE 2
-</pre>
-
-<h2><a name="hba"></a>Configuration de pool_hba.conf pour l'authentification
-des clients (HBA)</h2>
-<p>
-  Tout comme le fichier pg_hba.conf pour PostgreSQL, pgpool a la même 
-  fonctionnalité d'authentification des clients, qui est basée sur un fichier 
-  appelé pool_hba.conf.
-</p>
-<p>
-  Lorsque pgpool est installé, le fichier pool_hba.conf.sample est installé 
-  dans /usr/local/etc, qui est le répertoire par défaut des fichiers de 
-  configuration. Il faut copier pool_hba.conf.sample en pool_hba.conf puis
-  l'éditer si nécessaire. Par défaut, l'authentification par pool_hba est 
-  activée. Se reporter à « 6. Configuration de pgpool.conf » pour plus de détails.
-</p>
-<p>
-  Le format du fichier pool_hba.conf est très similaire à celui du fichier
-  pg_hba.conf de PostgreSQL.
-</p>
-<pre>
-    local      DATABASE  USER  METHOD  [OPTION]
-    host       DATABASE  USER  CIDR-ADDRESS  METHOD  [OPTION]
-</pre>
-<p>
-  Voir pool_hba.conf.sample pour une explication détaillée de chaque champ.
-</p>
-<p>
-  Voici les limitations de pool_hba.
-<ul>
-<li>la connexion de type hostssl n'est pas supportée</li>
-<p>
-    Bien que hostssl soit invalide, pgpool-II 2.3 et supérieur supporte
-    SSL. Voir <a href="#ssl">SSL</a> pour plus de détails.
-</p>
-<li>samegroup dans la colonne DATABASE n'est pas supporté</li>
-<p>
-    Comme pgpool ne sait rien à propos des utilisateurs déclarés dans le 
-    serveur PostgreSQL, le nom de la base de données est testé simplement 
-    par rapport aux entrées de la colonne DATABASE dans le fichier 
-    pool_hba.conf.
-</p>
-<li>les noms de groupes suivis du signe + pour la colonne USER ne sont pas
-supportés</li>
-<p>  
-    Cela est dû à la même raison que pour samegroup décrit ci-dessus. 
-    Un nom d'utilisateur est testé simplement par rapport aux entrées
-    dans la colonne USER du fichier pool_hba.conf.
-</p>
-<li>l'IPv6 pour l'adresse/masque dans la colonne IP n'est pas supporté</li>
-<p>
-    À ce jour, pgpool ne supporte pas l'IPv6.
-</p>
-<li>Seules les méthodes trust, reject, md5 et pam sont supportées
-dans la colonne METHOD</li>
-<p>
-    Encore une fois, c'est pour la même raison que pour samegroup (décrit
-    ci-dessus)&nbsp;: pgpool n'a pas accès aux informations sur les utilisateurs et 
-    mots de passes stockés dans le serveur PostgreSQL.
-</p>
-<p>
-Pour utiliser l'authentification md5, il faudra enregistrer votre nom 
-d'utilisateur et son mot de passe dans pool_passwd.
-Voir <a href="#md5">Authentification / Contrôle d'accès</a> pour plus de 
-détails.
-</ul>
-<p>
-  Notez que tout ce qui est décrit dans cette section concerne
-  l'authentification entre un client et pgpool&nbsp;; un client doit toujours 
-  passer à travers le processus d'authentification de PostgreSQL. Bien que 
-  pool_hba soit concerné, cela n'a pas d'importance si un nom d'utilisateur
-  et/ou de base de données donné par un client (i.e. psql -U testuser testdb)
-  existe ou non dans le serveur. pool_hba ne regarde en effet que si une 
-  correspondance est trouvée dans le fichier pool_hba.conf.
-</p>
-
-<p>
-  L'authentification PAM fonctionne grâce à l'information sur l'utilisateur
-  trouvée sur le serveur où pgpool est exécuté. Pour activer le support de PAM
-  dans pgpool, spécifier l'option "--with-pam" lors de la phase de configuration
-  de la compilation&nbsp;:
-</p>
-<pre>
-    configure --with-pam
-</pre>
-<p>
-  Pour activer l'authentification PAM, on a besoin de créer un fichier de 
-  configuration du service pour pgpool dans le répertoire de configuration de
-  PAM sur le système (qui est en général /etc/pam.d). Un fichier d'exemple
-  nommé share/pgpool.pam est présent dans le répertoire d'installation.
-</p>
-
-<h2>Configuration de la méthode de cache de requêtes</h2>
-<p>Le cache de requêtes est utilisable dans tous les modes de pgpool-II.
-Son activation dans le fichier pgpool.conf se fait de la manière suivante&nbsp;:
-<pre>
-enable_query_cache = true
-</pre>
-
-<p>
-Cependant, il faut aussi créer la table suivante dans la base de
-données système de pgpool-II&nbsp;:
-</p>
-<pre>
-CREATE TABLE pgpool_catalog.query_cache (
-  hash TEXT,
-  query TEXT,
-  value bytea,
-  dbname TEXT,
-  create_time TIMESTAMP WITH TIME ZONE,
-  PRIMARY KEY(hash, dbname)
-);
-</pre>
-<p>
-Notez qu'il peut aussi être nécessaire de modifier le nom du schéma dans l'exemple
-ci-dessus si pgpool_catalog n'est pas utilisé.
-</p>
-
-<h1>Démarrage et arrêt de pgpool-II<a name="start"></a></h1>
-
-<p>Tous les serveurs PostgreSQL doivent être démarrés, y compris celui qui 
-contient la base de données système de pgpool-II (si le mode utilisé l'impose),
-avant de démarrer pgpool-II.</p>
-
-<pre>
-pgpool [-c][-f config_file][-a hba_file][-F pcp_config_file][-n][-D][-d]
-</pre>
-<p>
-<table>
-  <tr><td>-c<br/>--clear-cache</td><td>vide le cache de requêtes</tr>
-  <tr><td>-f config_file<br/>--config-file config-file</td><td>spécifie
-le fichier pgpool.conf</tr>
-  <tr><td>-a hba_file<br/>--hba-file hba_file</td><td>spécifie le
-fichier pool_hba.conf</tr>
-  <tr><td>-F pcp_config_file<br/>--pcp-password-file</td><td>spécifie
-le fichier pcp.conf</tr>
-  <tr><td>-n<br/>--no-daemon</td><td>ne pas fonctionner en mode démon
-(le terminal n'est alors pas détaché)</tr>
-  <tr><td>-D<br/>--discard-status</td><td>ignore le fichier de statut
-précédent</tr>
-  <tr><td>-d<br/>--debug</td><td>mode de débogage</tr>
-</table>
-pgpool-II peut être arrêté de deux façons. La première est d'utiliser une
-commande PCP (détaillée plus loin dans ce document). La seconde est d'utiliser
-une commande pgpool-II, dont voici un exemple&nbsp;:
-</p>
-
-<pre>
-pgpool [-f config_file][-F pcp_config_file] [-m {s[mart]|f[ast]|i[mmediate]}] stop
-</pre>
-<p>
-<table>
-  <tr><td><code>-m s[mart]</code><br/><code>--mode s[mart]</code></td>
-      <td>attends que les clients se déconnectent avant de s'arrêter (mode par
-défaut)</td></tr>
-  <tr><td><code>-m f[ast]</code><br/><code>--mode f[ast]</code></td>
-      <td>n'attend pas la déconnexion des clients, et s'arrête
-immédiatement</td></tr>
-  <tr><td><code>-m i[mmediate]</code><br/><code>--mode i[mmediate]</code></td>
-      <td>même chose que <code>'-m f'</code></td></tr> </table>
-</p>
-<p>
-pgpool enregistre son état dans le fichier [logdir]/pgpool_status. Lorsque
-pgpool redémarre, il lit ce fichier et restaure le statut de chaque serveur (tel qu'il
-était à l'arrêt de pgpool). Cela permettra d'éviter une différence au niveau
-des données dans les différents nœuds PostgreSQL, qui pourrait être causée
-selon le scénario suivant&nbsp;:
-<ol>
-<li>Un serveur s'arrête inopinément et pgpool exécute la procédure de fail-over
-<li>Une mise à jour est effectuée sur l'une des bases de données actives, via
-pgpool
-<li>L'administrateur décide d'arrêter pgpool
-<li>Quelqu'un d'autre décide de redémarrer la base de données qui est en train
-de s'arrêter, sans en informer l'administrateur
-<li>L'administrateur redémarre pgpool
-</ol>
-</p>
-<p>
-Si, pour une raison quelconque, la base de données arrêtée a été synchronisée
-avec la base de données active d'une autre manière, pgpool_status peut alors
-être supprimé sereinement avant de démarrer pgpool.
-</p>
-
-<h1>Rechargement des fichiers de configuration de pgpool-II<a
-name="reload"></a></h1>
-<p>pgpool-II peut recharger ses fichiers de configuration et se mettre alors à
-jour par rapport à ces derniers, sans avoir à être redémarré.
-</p>
-
-<pre>
-pgpool [-c][-f config_file][-a hba_file][-F pcp_config_file] reload
-</pre>
-<p>
-<table>
-  <tr><td>-f config_file<br/>--config-file config-file</td><td>spécifie
-le fichier pgpool.conf</tr>
-  <tr><td>-a hba_file<br/>--hba-file hba_file</td><td>spécifie le
-fichier pool_hba.conf</tr>
-  <tr><td>-F pcp_config_file<br/>--pcp-password-file</td><td>spécifie
-le fichier pcp.conf</tr>
-</table>
-
-<p>
-Il faut bien faire attention au fait que certains paramètres de configuration
-ne peuvent pas être changés par un rechargement. De plus, la nouvelle
-configuration ne prend effet qu'à partir des nouvelles sessions créées.
-</p>
-
-<h1><a name="show-commands"></a>Commandes SHOW</h1>
-<h2>Aperçu</h2>
-<p>
-pgpool-II donne quelques informations via les commandes SHOW. SHOW est une
-commande SQL existante, mais pgpool-II l'intercepte si la requête concerne des
-informations spécifiques à pgpool-II. Voici les options spécifiques à pgpool-II&nbsp;:
-<ul>
-  <li>pool_status, pour avoir la configuration</li>
-  <li>pool_nodes, pour avoir des informations sur les nœuds</li>
-  <li>pool_processes, pour avoir l'information sur les processus de
-pgpool-II</li>
-  <li>pool_pools, pour avoir l'information sur les pools de pgpool-II</li>
-  <li>pool_version, pour avoir la version de pgpool-II</li>
-</ul>
-<p>
-<u>Note</u>&nbsp;: Le terme 'pool' réfère au nombre de sessions PostgreSQL détenues
-par un processus pgpool, et non le nombre total de sessions détenues par pgpool.
-</p>
-</p>
-<p>L'option pool_status était disponible dans les versions précédentes, mais
-les autres sont apparues avec la version 3.0.</p>
-<h2>pool_status</h2>
-<p>"SHOW pool_status" renvoie la liste des paramètres de configuration avec
-leur nom, leur valeur et leur description. Voici un exemple du résultat obtenu
-avec cette commande&nbsp;:
-<pre>
-benchs2=# show pool_status;
-             item              |              value              |                           description                            
--------------------------------+---------------------------------+------------------------------------------------------------------
- listen_addresses              | 127.0.0.1                       | host name(s) or IP address(es) to listen to
- port                          | 9999                            | pgpool accepting port number
- socket_dir                    | /tmp                            | pgpool socket directory
- num_init_children             | 5                               | # of children initially pre-forked
- child_life_time               | 300                             | if idle for this seconds, child exits
-</pre>
-</p>
-<h2>pool_nodes</h2>
-<p>"SHOW pool_nodes" renvoie une liste de nœuds configurés. Il affiche
-l'identifiant du nœud, son nom d'hôte (ou son adresse IP), son port, son statut et le
-poids (qui n'a d'intérêt que si on utilise le mode de répartition de charge des
-requêtes en lecture). Les valeurs possibles pour la colonne status
-sont explicitées dans la <a href="#pcp_node_info">partie dédiée à
-pcp_node_info</a>.
-
-<pre>
-benchs2=# show pool_nodes;
-  id  |  hostname   | port | status | lb_weight     
-------+-------------+------+--------+-----------
-   0  | 127.0.0.1   | 5432 | 2      | 0.5
-   1  | 192.168.1.7 | 5432 | 3      | 0.5
-(2 lignes)
-</pre>
-</p>
-<h2>pool_processes</h2>
-<p>"SHOW pool_processes" renvoie une liste de tous les processus qui attendent
-une connexion ou interagissent avec une connexion.
-</p>
-<p>
-Cette liste a 6 colonnes&nbsp;:
-<ul>
-<li>pool_pid est le PID du processus pgpool affiché</li>
-<li>start_time est l'horodatage correspondant au démarrage du processus</li>
-<li>database est le nom de la base de données où le serveur est actuellement
-connecté</li>
-<li>username est le nom de l'utilisateur utilisé dans la connexion au serveur
-pour ce processus</li>
-<li>create_time est l'horodatage correspondant à la création de la
-connexion</li>
-<li>pool_counter compte le nombre de fois que ce pool de connexions (le
-processus) a été utilisé par les clients</li>
-</ul>
-</p>
-<p>Cette vue retournera toujours un nombre de lignes
-équivalent à num_init_children.</p>
-<pre>
-benchs2=# show pool_processes;
-   pool_pid |     start_time      | database | username  |     create_time     | pool_counter 
-----------+---------------------+----------+-----------+---------------------+--------------
- 8465     | 2010-08-14 08:35:40 |          |           |                     | 
- 8466     | 2010-08-14 08:35:40 | benchs   | guillaume | 2010-08-14 08:35:43 | 1
- 8467     | 2010-08-14 08:35:40 |          |           |                     | 
- 8468     | 2010-08-14 08:35:40 |          |           |                     | 
- 8469     | 2010-08-14 08:35:40 |          |           |                     | 
-(5 lines)
-</pre>
-<h2>pool_pools</h2>
-<p>"SHOW pool_pools" renvoie une liste de pools détenus par pgpool-II, avec
-leurs noms, valeurs et description. Voici un exemple de résultat&nbsp;:
-</p>
-<p>
-Cette liste a 11 colonnes&nbsp;:
-<ul>
-<li>pool_pid est le PID du processus pgpool-II</li>
-<li>start_time est l'horodatage qui correspond au lancement du processus</li>
-<li>pool_id est l'identifiant du pool (qui doit être entre 0 et
-max_pool-1)</li>
-<li>backend_id est l'identifiant du serveur (qui doit être entre 0 et le
-nombre de serveurs configurés moins un).</li>
-<li>database est le nom de la base de données utilisée dans cette connexion</li>
-<li>username est le nom d'utilisateur utilisé dans cette connexion</li>
-<li>create_time est l'horodatage de création de cette connexion</li>
-<li>majorversion et minorversion sont les versions de protocole utilisées par
-cette connexion</li>
-<li>pool_counter compte le nombre de fois que cette connexion a été utilisée
-par les clients</li>
-<li>pool_backendpid et le PID du processus PostgreSQL</li>
-<li>pool_connected et à vrai (1) si un client utilise actuellement cette
-connexion</li>
-</ul>
-</p>
-<p>Cette vue retournera toujours le même nombre de lignes que
-num_init_children * max_pool</p>
-<pre>
-  pool_pid |     start_time      | pool_id | backend_id | database | username  |     create_time     | majorversion | minorversion | pool_counter | pool_backendpid | pool_connected 
-----------+---------------------+---------+------------+----------+-----------+---------------------+--------------+--------------+--------------+-----------------+----------------
- 8465     | 2010-08-14 08:35:40 | 0       | 0          |          |           |                     |              |              |              |                 | 
- 8465     | 2010-08-14 08:35:40 | 1       | 0          |          |           |                     |              |              |              |                 | 
- 8465     | 2010-08-14 08:35:40 | 2       | 0          |          |           |                     |              |              |              |                 | 
- 8465     | 2010-08-14 08:35:40 | 3       | 0          |          |           |                     |              |              |              |                 | 
- 8466     | 2010-08-14 08:35:40 | 0       | 0          | benchs   | guillaume | 2010-08-14 08:35:43 | 3            | 0            | 1            | 8473            | 1
- 8466     | 2010-08-14 08:35:40 | 1       | 0          |          |           |                     |              |              |              |                 | 
- 8466     | 2010-08-14 08:35:40 | 2       | 0          |          |           |                     |              |              |              |                 | 
- 8466     | 2010-08-14 08:35:40 | 3       | 0          |          |           |                     |              |              |              |                 | 
- 8467     | 2010-08-14 08:35:40 | 0       | 0          |          |           |                     |              |              |              |                 | 
- 8467     | 2010-08-14 08:35:40 | 1       | 0          |          |           |                     |              |              |              |                 | 
- 8467     | 2010-08-14 08:35:40 | 2       | 0          |          |           |                     |              |              |              |                 | 
- 8467     | 2010-08-14 08:35:40 | 3       | 0          |          |           |                     |              |              |              |                 | 
- 8468     | 2010-08-14 08:35:40 | 0       | 0          |          |           |                     |              |              |              |                 | 
- 8468     | 2010-08-14 08:35:40 | 1       | 0          |          |           |                     |              |              |              |                 | 
- 8468     | 2010-08-14 08:35:40 | 2       | 0          |          |           |                     |              |              |              |                 | 
- 8468     | 2010-08-14 08:35:40 | 3       | 0          |          |           |                     |              |              |              |                 | 
- 8469     | 2010-08-14 08:35:40 | 0       | 0          |          |           |                     |              |              |              |                 | 
- 8469     | 2010-08-14 08:35:40 | 1       | 0          |          |           |                     |              |              |              |                 | 
- 8469     | 2010-08-14 08:35:40 | 2       | 0          |          |           |                     |              |              |              |                 | 
- 8469     | 2010-08-14 08:35:40 | 3       | 0          |          |           |                     |              |              |              |                 | 
-(20 lines)
-</pre>
-</p>
-<h2>pool_version</h2>
-<p>"SHOW pool_version" affiche la version de pgpool-II. En voici un exemple&nbsp;:
-<pre>
-benchs2=# show pool_version;
-      pool_version      
-------------------------
- 3.0-dev (umiyameboshi)
-(1 line)
-</pre>
-</p>
-<h1><a name="online-recovery"></a>Online Recovery</h1>
-<h2>Aperçu</h2>
-<p>
-pgpool-II, alors qu'il est en mode réplication, peut synchroniser une base de
-données et attacher un nœud tout en continuant à répondre aux clients. Cette
-fonctionnalité est appelée « online recovery ».
-</p>
-
-<p>
-Le nœud cible de cette restauration doit être dans l'état détaché avant de
-lancer le « online recovery ».
-
-Si on veut ajouter un serveur PostgreSQL dynamiquement, ajoutez un
-paramètre backend_hostname et ces paramètres associés, et rechargez pgpool.conf.
-pgpool-II va alors enregistrer ce nouveau serveur et l'afficher dans l'état
-détaché.
-</p>
-
-<p>
-<font color="red">Attention&nbsp;: Penser à arrêter l'autovacuum sur le nœud maître
-(autrement dit le premier qui est ouvert et en fonctionnement). En effet, autovacuum
-pourrait changer le contenu d'une base de données et alors causer une
-incohérence après un « online recovery ». Cela s'applique uniquement si on fait
-la restauration avec un mécanisme simple tel que la
-technique rsync détaillée plus bas. Cela ne s'applique bien sûr pas si on
-utilise la technique basée sur le PITR de PostgreSQL.</font>
-</p>
-
-<p>
-   Si le serveur PostgreSQL a déjà été démarré, il faut l'arrêter.
-</p>
-
-<p>
-pgpool-II effectue le « online recovery » en deux phase séparées. Il y a quelques
-secondes ou minutes pendant lesquelles un client sera en attente de connexion à
-pgpool-II, lorsque la restauration et la synchronisation du nœud a lieu. Ce
-mécanisme suit les étapes suivantes&nbsp;:
-  <ol>
-    <li> CHECKPOINT
-    <li> Première phase du « online recovery »
-    <li> Attendre que tous les clients soient déconnectés
-    <li> CHECKPOINT
-    <li> Seconde phase du « online recovery »
-    <li> Démarrage du nouveau postmaster (effectué par pgpool_remote_start)
-    <li> Attachement du nœud
-  </ol>
-</p>
-
-<p>
-   La première étape de la synchronisation des données est appelée première 
-   phase. Les données sont en effet synchronisées pendant cette étape. 
-   Pendant cette dernière, les données <b>peuvent</b> être mises à jour ou 
-   récupérées par les clients, sur toutes les tables, de manière concurrente.
-</p>
-
-<p>
-  On peut spécifier un script qui sera exécuté pendant cette première phase.
-  pgpool-II passe alors trois arguments à ce dernier&nbsp;:
-
-  <ol>
-    <li> le chemin complet vers le répertoire des données de l'instance PostgreSQL du nœud maître 
-    <li> le nom d'hôte (ou IP) du serveur à restaurer
-    <li> le chemin complet vers le répertoire des données de l'instance PostgreSQL du serveur à restaurer
-  </ol>
-</p>
-
-<p>
-  La synchronisation des données est finalisée dans ce qui est appelé la
-  seconde phase. Avant d'entrer dans cette dernière, pgpool-II attend que 
-  tous les clients soient déconnectés. Il bloque alors toute nouvelle connexion
-  jusqu'à ce que cette seconde phase soit terminée.
-
-  Après que toutes les connexions soient terminées, pgpool-II applique toutes les
-  données mises à jour pendant la première et la seconde phase sur le nœud en 
-  cours de restauration. Cela achève ainsi la dernière phase de synchronisation
-  des données.
-</p>
-
-<p>
- <font color="red">
-  Il est à noter qu'il y a une restriction sur le « online recovery ». Si pgpool-II
-  lui-même est installé sur plusieurs serveurs, le « online recovery » ne 
-  fonctionnera pas correctement car pgpool-II doit arrêter tous les clients
-  pendant la seconde phase du « online recovery ». Ainsi, s'il y a plusieurs 
-  serveurs pgpool, un seul aura reçu la commande de « online recovery » et bloquera
-  les connexions.
-</font>
-</p>
-
-<h2>Configuration du « online recovery »</h2>
-<p>
-Il convient de configurer les paramètres suivants pour le « online recovery »
-dans le fichier pgpool.conf.
-   <ul>
-    <li> backend_data_directory
-    <li> recovery_user
-    <li> recovery_password
-    <li> recovery_1st_stage_command
-    <li> recovery_2nd_stage_command
-   </ul>
-</p>
-
-
-<h2><a name="installing-c-functions"></a>Installation des fonctions en
-langage C</h2>
-<p>
-Les fonctions en langage C suivantes doivent être installées dans la base
-template1 de tous les serveurs PostgreSQL pour que le « online recovery »
-fonctionne.
-
-Leur code source est dans le répertoire suivant de l'archive de pgpool-II&nbsp;:
-</p>
-
-<pre>
-  pgpool-II-x.x.x/sql/pgpool-recovery/
-</pre>
-
-<p>
-Il convient de changer le nom du répertoire ci-dessus pour l'ajuster à votre
-version précise de pgpool-II.
-
-On se place dans ce dernier et on lance la commande « make install »&nbsp;:
-
-</p>
-
-<pre>
-  % cd pgpool-II-x.x.x/sql/pgpool-recovery/
-  % make install
-</pre>
-
-<p>
-À présent, il faut installer les fonctions SQL correspondantes&nbsp;:
-</p>
-
-<pre>
-  % cd pgpool-II-x.x.x/sql/pgpool-recovery/
-  % psql -f pgpool-recovery.sql template1
-</pre>
-
-
-<h2>Déploiement du script de restauration</h2>
-<p>
-Des scripts de synchronisation de données doivent être déployés ainsi qu'un
-script qui permet de démarrer PostgreSQL à distance, et tout ceci, dans le
-répertoire des données de l'instance de PostgreSQL ($PGDATA). Plusieurs scripts d'exemple sont
-disponibles dans le répertoire pgpool-II-x.x.x/sample. 
-</p>
-
-<h3>« Online recovery » grâce au PITR</h3>
-<p>
-Voici comment faire un « online recovery » grâce au Point In Time Recovery (PITR),
-qui est disponible à partir de la version 8.2 de PostgreSQL.
-Attention, tous les serveurs impliqués doivent avoir le PITR d'activé et correctement
-configuré.
-</p>
-
-<p>
-Il est nécessaire d'avoir un script qui se charge d'effectuer une
-sauvegarde complète du serveur PostgreSQL sur un nœud maître et de l'envoyer sur
-un nœud cible pour la restauration lors de la première phase. Ce script
-peut être nommé copy-base-backup par exemple. Voici un exemple de ce script&nbsp;:
-</p>
-
-<pre>
-  #! /bin/sh
-  DATA=$1
-  RECOVERY_TARGET=$2
-  RECOVERY_DATA=$3
-
-  psql -c "select pg_start_backup('pgpool-recovery')" postgres
-  echo "restore_command = 'scp $HOSTNAME:/data/archive_log/%f %p'" > /data/recovery.conf
-  tar -C /data -zcf pgsql.tar.gz pgsql
-  psql -c 'select pg_stop_backup()' postgres
-  scp pgsql.tar.gz $RECOVERY_TARGET:$RECOVERY_DATA
-</pre>
-
-<p>
-Ce script place le serveur maître en mode sauvegarde à chaud, puis génère le
-fichier recovery.conf suivant&nbsp;:
-</p>
-<pre>
-restore_command = 'scp master:/data/archive_log/%f %p'
-</pre>
-Ensuite, il effectue la sauvegarde, puis sort le serveur maître du mode sauvegarde à chaud
-et copie enfin la sauvegarde sur le nœud désiré.
-</p>
-
-<p>
-La seconde phase de cette procédure est un script qui va forcer un changement
-de journal de transactions (XLOG). Ce script est nommé pgpool_recovery_pitr ici.
-Il utilise pg_switch_xlog. Cependant, il pourrait rendre la main <b>avant</b>
-que le changement de journal ne soit fait, ce qui pourrait alors provoquer un
-échec de la procédure d'« online recovery ».
-
-pgpool-II fournit une méthode plus sûre avec la fonction pgpool_swich_xlog,
-qui attend que le changement effectif de journal de transaction
-ait eu lieu.
-
-Cette fonction est installée avec la procédure explicitée dans la section
-<a href="#installing-c-functions">Installation des fonctions en
-langage C</a>.
-</p>
-<p>
-Voici un script d'exemple&nbsp;:
-</p>
-<p>
-<pre>
-#! /bin/sh
-# Online recovery 2nd stage script
-#
-datadir=$1		  # master dabatase cluster
-DEST=$2			  # hostname of the DB node to be recovered
-DESTDIR=$3		  # database cluster of the DB node to be recovered
-port=5432		  # PostgreSQL port number
-archdir=/data/archive_log # archive log directory
-
-# Force to flush current value of sequences to xlog 
-psql -p $port -t -c 'SELECT datname FROM pg_database WHERE NOT datistemplate AND datallowconn' template1|
-while read i
-do
-  if [ "$i" != "" ];then
-    psql -p $port -c "SELECT setval(oid, nextval(oid)) FROM pg_class WHERE relkind = 'S'" $i
-  fi
-done
-
-psql -p $port -c "SELECT pgpool_switch_xlog('$archdir')" template1
-</pre>
-</p>
-
-<p>
-Cette mise à jour des séquences est uniquement utile dans le mode réplication&nbsp;:
-dans ce cas, les séquences doivent avoir le même numéro de démarrage sur tous
-les nœuds. Ça n'est pas utile dans le mode maître-esclave.
-
-La boucle dans ce script force PostgreSQL à émettre la valeur courante de toutes
-les séquences dans toutes les bases du nœud maître dans le journal de
-transactions afin que celles-ci soient propagées au nœud en cours de
-restauration.
-</p>
-
-<p>
-Ces scripts doivent être déployés dans le répertoire des données de l'instance PostgreSQL
-(autrement dit $PGDATA).
-</p>
-<p>
-Enfin, on édite le fichier pgpool.conf.
-
-<pre>
-recovery_1st_stage_command = 'copy-base-backup'
-recovery_2nd_stage_command = 'pgpool_recovery_pitr'
-</pre>
-
-</p>
-
-<p>
-Cette opération termine la préparation du « online recovery » via le PITR.
-</p>
-
-<h4><p>pgpool_remote_start</p></h4>
-<p>
-Ce script démarre le processus postmaster sur les nœuds distants.
-pgpool-II l'exécute de la manière suivante.
-</p>
-
-<pre>
-  % pgpool_remote_start remote_host remote_datadir
-  remote_host:    Nom d'hôte de la machine cible à restaurer
-  remote_datadir: Chemin vers le répertoire des données de l'instance PostgreSQL sur une machine en
-restauration
-</pre>
-
-<p>
-Dans ce script d'exemple, on démarre le processus postmaster via ssh.
-Afin qu'il fonctionne, on doit pouvoir se connecter via ssh sans mot de passe.
-</p>
-
-<p>
-Si la restauration se fait avec PITR, il faut déployer le script de sauvegarde de
-base. PostgreSQL démarrera alors automatiquement en effectuant une restauration
-via le PITR. Il acceptera ensuite les connexions.
-</p>
-
-<pre>
-#! /bin/sh
-DEST=$1
-DESTDIR=$2
-PGCTL=/usr/local/pgsql/bin/pg_ctl
-
-# Déploiement du script de backup
-ssh -T $DEST 'cd /data/; tar zxf pgsql.tar.gz' 2>/dev/null 1>/dev/null &lt; /dev/null
-# Démarrage du serveur PostgreSQL
-ssh -T $DEST $PGCTL -w -D $DESTDIR start 2>/dev/null 1>/dev/null &lt; /dev/null &
-</pre>
-
-<h3>« Online recovery » avec rsync</h3>
-<p>
-PostgreSQL 7.4 n'a pas le PITR, qui n'est apparu qu'en version 8.0. rsync peut alors être
-utilisé pour effectuer le « online recovery ». Dans le script d'exemple disponible
-dans les sources de pgpool-II, il y a un script de restauration qui est
-nommé pgpool_recovery. Ce dernier utilise la commande rsync. pgpool-II
-appelle ce script avec trois arguments.
-</p>
-
-<pre>
-  % pgpool_recovery datadir remote_host remote_datadir
-  datadir:        Répertoire des données de l'instance PostgreSQL sur un serveur maître
-  remote_host:    Nom d'hôte (ou IP) du serveur cible à restaurer
-  remote_datadir: Répertoire des données de l'instance PostgreSQL du serveur cible à
-restaurer
-</pre>
-
-<p>
-Ce script copie les fichiers de manière physique grâce à rsync et via ssh.
-Comme précédemment, on doit pouvoir se connecter via ssh sans mot de passe.
-</p>
-
-<p>
-Note à propos de rsync&nbsp;:
-<ul>
- <li>-c (ou --checksum) : cette option est requise pour assurer une
-transmission fiable
-
- <li>-z (ou --compress) : cette option fait de la compression des fichiers lors
-de leur transmission. Cela sera fort utile pour les connexions réseau lentes,
-mais pourrait ajouter une grosse surcharge inutile sur le CPU (à cause de la
-compression) pour des réseaux à 100 Mbits voire supérieurs. Dans ces derniers
-cas, il sera préférable de ne pas utiliser la compression.
-
- <li>rsync 3.0.5 a d'excellentes améliorations de performances en vitesse (près
-de 50% plus rapide d'après les discussions qui ont eu lieu sur la liste de
-discussion pgpool-general)
-</ul>
-
-</p>
-
-<p>
-Si on utilise pgpool_recovery, il convient d'ajouter les lignes suivantes au
-ficher pgpool.conf&nbsp;:
-
-<pre>
-recovery_1st_stage_command = 'pgpool_recovery'
-recovery_2nd_stage_command = 'pgpool_recovery'
-</pre>
-</p>
-
-<h2>Comment effectuer un « online recovery »</h2>
-<p>
-Afin de réaliser un « online recovery », on peut utiliser la commande
-pcp_recovery_node ou bien pgpoolAdmin.
-</p>
-
-<p>
-Il est à noter qu'on doit positionner un nombre important dans le tout premier
-argument de pcp_recovery_node. Il s'agit d'un délai maximum en secondes. Si on
-utilise pgpoolAdmin, il convient aussi de mettre un grand nombre au paramètre
-"_PGPOOL2_PCP_TIMEOUT" dans le fichier de configuration pgmgt.conf.php.
-</p>
-
-<h1><a name="troubleshooting"></a>Que faire en cas d'erreur</h1>
-<p>
-Cette section décrit quelques problèmes qui peuvent survenir lors de
-l'utilisation de pgpool-II, ainsi que leur solutions.
-</p>
-<p>
-<ul>
-
-<dt>Health check failed
-<dd>
-<p>
-pgpool-II vérifie périodiquement que tous les serveurs configurés fonctionnent
-correctement.
-</p>
-<p>
-<pre>
-2010-07-23 16:42:57 ERROR: pid 20031: health check failed. 1 th host foo at port 5432 is down
-2010-07-23 16:42:57 LOG:   pid 20031: set 1 th backend down status
-2010-07-23 16:42:57 LOG:   pid 20031: starting degeneration. shutdown host foo(5432)
-2010-07-23 16:42:58 LOG:   pid 20031: failover_handler: set new master node: 0
-2010-07-23 16:42:58 LOG:   pid 20031: failover done. shutdown host foo(5432)
-</pre>
-</p>
-<p>
-Ici, la trace montre que le serveur 1 (nom d'hôte "foo") s'arrête puis est
-déconnecté (shutdown) de pgpool. Ensuite, le serveur 0 devient le nouveau
-maître.
-
-Il convient donc de vérifier le serveur 1 et corriger la cause de l'erreur.
-Ensuite, il faudra effectuer un « online recovery » sur le serveur 1 si c'est
-possible.
-</p>
-
-<dt>Failed to read kind from frontend
-<dd>
-<p>
-<pre>
-2010-07-26 18:43:24 LOG:   pid 24161: ProcessFrontendResponse: failed to read kind from frontend. frontend abnormally exited
-</pre>
-<p>
-Cette trace indique simplement que le programme client ne s'est pas connecté
-correctement à pgpool-II.
-
-Les causes possibles sont&nbsp;: un bug dans les applications clientes, la
-déconnexion forcée d'une application cliente (un "kill" par exemple) ou bien
-une erreur réseau temporaire.
-
-Ce genre d'évènements ne mène pas à la destruction d'une base de données ou
-même à une corruption de données. Il s'agit juste d'un avertissement sur le
-fait qu'il y a eu une violation du protocole utilisé par pgpool-II.
-
-Il est cependant recommandé d'investiguer plus en avant si ce message arrive
-trop souvent.
-</p>
-
-<dt>Kind mismatch errors
-<dd>
-<p>
-Cette erreur peut survenir si pgpool-II fonctionne en mode réplication.
-</p>
-<pre>
-2010-07-22 14:18:32 ERROR: pid 9966: kind mismatch among backends. Possible last query was: "FETCH ALL FROM c;" kind details are: 0[T] 1[E: cursor "c" does not exist]
-</pre>
-<p>
-pgpool-II attend les réponses des serveurs PostgreSQL après leur avoir envoyé
-une commande SQL.
-Ce message indique que tous les serveurs de données ne retournent pas le même
-type de réponse.
-
-La requête SQL qui a causé l'erreur se trouve après « Possible last query was: ».
-
-Ensuite, le type de réponse suit.
-
-Ici, on peut lire que « 0[T] » affiche la réponse du serveur de données:
-« 0[T] » (renvoi de la description de l'enregistrement), et que « 1[E » affiche que
-le serveur 1 retourne une erreur avec le message « cursor c does not exist »,
-alors que le serveur 0 renvoie bien la description de l'enregistrement.
-<p>
-Attention, on pourrait aussi avoir cette erreur dans le mode maître-esclave.
-
-Par exemple, même dans le mode maître-esclave, la commande SET sera envoyée à
-tous les serveurs de données pour qu'ils soient dans le même état.
-</p>
-<p>
-Il convient de vérifier alors les serveurs de données et éventuellement les
-resynchroniser en utilisant le « online recovery », quand c'est possible et si
-nécessaire.
-</p>
-
-<p>
-<dt>Pgpool detected difference of the number of inserted, updated or deleted tuples
-<dd>
-<p>
-Dans le mode réplication, pgpool-II a détecté un nombre différent
-d'enregistrements mis à jour (en INSERT, UPDATE ou DELETE) sur les différents
-serveurs.
-</p>
-<p>
-<pre>
-2010-07-22 11:49:28 ERROR: pid 30710: pgpool detected difference of the number of inserted, updated or deleted tuples. Possible last query was: "update t1 set i = 1;"
-2010-07-22 11:49:28 LOG:   pid 30710: ReadyForQuery: Degenerate backends: 1
-2010-07-22 11:49:28 LOG:   pid 30710: ReadyForQuery: Affected tuples are: 0 1
-</pre>
-<p>
-Dans l'exemple ci-dessus, le nombre d'enregistrements mis à jour grâce à
-« UPDATE t1 SET i = 1 » est différent à travers les différents serveurs de
-données.
-
-La ligne qui suit indique que le serveur 1 a été dégénéré (déconnecté)&nbsp;:
-c'est la conséquence du fait que pour le serveur 0 le nombre d'enregistrement
-mis à jours a été de 0, alors que pour le serveur 1 le nombre d'enregistrements
-modifiés a été de 1.
-</p>
-<p>
-Il convient alors d'arrêter le serveur que l'on suspecte être désynchronisé (ou
-simplement ne pas avoir les bonnes données), puis de procéder à un « online
-recovery ».
-</ul>
-
-
-<h1>Restrictions<a name="restriction"></a></h1>
-
-<p>
-<h2>Fonctionnalités de PostgreSQL</h2>
-<p>
-<ul>
-<li>Si on utilise pg_terminate_backend() pour arrêter un processus serveur PostgreSQL,
-cela provoquera un failover. La raison de ce comportement est que PostgreSQL
-envoie alors exactement le même message que si c'était le postmaster lui-même
-qui s'arrêtait complètement. Il n'existe pas de contournement à ce problème à ce
-jour. Aussi, il faut veiller à ne pas utiliser cette fonction pour le moment.
-</ul>
-
-<p>
-<h2><a name="md5"></a>Authentification / Contrôle d'accès</h2>
-
-<p>
-<ul>
-  <li>Dans le mode réplication ou maître-esclave, les méthode
-d'authentification supportées sont trust, mot de passe en clair et pam. md5 est
-aussi supporté depuis la version 3.0 de pgpool-II.
-md5 est supporté en utilisant pool_passwd. Voici les étapes à respecter pour
-autoriser l'authentification md5&nbsp;:
-	   <ol>
-		<li>Se connecter au système d'exploitation du serveur de
-données, avec l'utilisateur qui a les droits (postgres) et entrer&nbsp;:
-		   pg_md5 --md5auth &lt;mot_de_passe&gt;<br/>
-                    le nom d'utilisateur et son mot de passe chiffré en md5 sont
-alors enregistrés dans pool_passwd. Si ce dernier n'existe pas encore, la
-commande pg_md5 va le créer automatiquement.</li>
-		<li>Le format utilisé par pool_passwd est
-"nom_d_utilisateur:mot_de_passe_encrypté_md5"</li>
-		<li>Il faudra aussi une entrée appropriée md5 dans le
-fichier pool_hba.conf. À cet effet, voir <a href="#hba">Configuration de pool_hba.conf
-pour l'authentification des clients</a> pour plus de détails</li>
-		<li>Il faut bien veiller à ce que le nom d'utilisateur et son
-mot de passe soient strictement identiques à ce qui se trouvent dans le serveur
-PostgreSQL pour que cela fonctionne</li>
-	   </ol>
-
-	   </li>
-  <li>Dans tous les autres modes, les méthodes trust, mot de passe en clair,
-crypt, md5 et pam sont supportées.</li>
-  <li>pgpool-II ne supporte pas les contrôles d'accès comme pg_hba.conf de
-PostgreSQL. Par exemple, si les connexions TCP/IP sont activées, pgpool-II
-accepte toutes les connexions TCP/IP, quel que soient leurs origines. Si
-c'est absolument requis dans le contexte, il convient d'utiliser un programme
-comme iptables afin de contrôler les accès TCP/IP. Bien sûr, les serveurs
-PostgreSQL qui acceptent les connexions pgpool-II peuvent utiliser leur
-configuration pg_hba.conf propre.</li>
-	   </ul>
-</p>
-
-<h2>Large objects</h2>
-<p>
-pgpool-II 2.3.2 et suivants supportent la réplication des « large objects » si le
-serveur PostgreSQL est au moins en version 8.1.
-
-Pour que cela fonctionne, il faut activer la directive de configuration <a
-href="#lobj_lock_table">lobj_lock_table</a> dans le fichier pgpool.conf.
-
-Cependant, la réplication des « large objects » utilisant la fonction PostgreSQL
-lo_import n'est pas supportée.
-</p>
-
-<h2>Tables temporaires en mode maître-esclave</h2>
-<p>
-Tout ce qui concerne les tables temporaires est toujours exécuté sur le maître.
-
-À partir de la version 3.0 de pgpool-II, les SELECT sur ces tables sont
-eux-aussi exécutés sur le maître.
-
-Cependant, si le nom de la table temporaire est utilisé comme un littéral dans
-le SELECT, il n'y a aucun moyen de le détecter. Du coup, les SELECT seront
-répartis entre les serveurs PostgreSQL.
-
-Cela amènera à une erreur, la table n'existant que sur le maître ("not found
-the table...").
-
-Pour éviter ce problème, il faut utiliser le commentaire « /*NO LOAD BALANCE*/ »
-dans le corps de la requête SQL contenant l'appel en SELECT sur la table
-temporaire.
-</p>
-<p>
-<pre>
-Voici en uxemple de SELECT qui pose problème&nbsp;:
-SELECT 't1'::regclass::oid;
-</pre>
-</p>
-<p>
-La commande "\d" de psql utilise les tables de nom en littéral. À partir de la
-version 3.0 de pgpool-II, ce dernier va tester si le SELECT contient un accès
-au catalogue système et enverra alors les requêtes au maître dans
-l'affirmative.
-
-Cela permet de contourner le problème.
-</p>
-
-<h2>Fonctions et autres en mode réplication</h2>
-
-<p>
-Il n'y a aucune garantie que toute donnée obtenue via un mécanisme dépendant du
-contexte (par exemple un nombre au hasard, un numéro de transaction, un OID,
-un SERIAL ou une sequence) sera répliquée correctement sur plusieurs serveurs
-PostgreSQL.
-</p>
-<p>Pour SERIAL, l'activation de la directive de configuration insert_lock
-permettra de répliquer correctement la donnée. Cela permettra aussi un bon
-fonctionnement de "SELECT setval()" et "SELECT nextval()".</p>
-
-<p>
-À partir de la version 2.3 de pgpool, les INSERT et UPDATE qui utilisent
-CURRENT_TIMESTAMP, CURRENT_DATE et now() seront répliqués correctement. De
-même, les INSERT et UPDATE pour les tables qui utilisent CURRENT_TIMESTAMP,
-CURRENT_DATE et now() comme leur valeur par défaut (DEFAULT valeur) seront aussi
-répliqués correctement.
-
-Cela est obtenu en remplaçant ces fonctions par des constantes qui sont
-récupérées sur le maître au moment de l'exécution de la requête.
-
-Il y a cependant quelques limitations&nbsp;:
-<ul>
-<li>Le calcul de la donnée temporelle n'est pas correct dans quelques cas. Par
-exemple, voici une définition de table&nbsp;:
-<pre>
-CREATE TABLE rel1(
-  d1 date DEFAULT CURRENT_DATE + 1
-)
-</pre>
-Ceci est traité de la même façon que&nbsp;:
-<pre>
-CREATE TABLE rel1(
-  d1 date DEFAULT CURRENT_DATE
-)
-</pre>
-<p>
-Il est à noter que si le type de la colonne n'est pas temporel, la réécriture
-n'est pas effectuée. En voici un exemple&nbsp;:
-<pre>
-foo bigint default (date_part('epoch'::text,('now'::text)::timestamp(3) with time zone) * (1000)::double precision)
-</pre>
-</p>
-<li>Supposons à présent que nous ayons la table suivante&nbsp;:
-<pre>
-CREATE TABLE rel1(
-  c1 int,
-  c2 timestamp default now()
-)
-</pre>
-On peut répliquer&nbsp;:
-<pre>
-INSERT INTO rel1(c1) VALUES(1) 
-</pre>
-puis que cela se transforme en&nbsp;:
-<pre>
-INSERT INTO rel1(c1, c2) VALUES(1, '2009-01-01 23:59:59.123456+09')
-</pre>
-Cependant&nbsp;:
-<pre>
-INSERT INTO rel1(c1) SELECT 1
-</pre>
-ne peut pas être transformé. Il ne sera donc pas correctement répliqué avec
-l'implémentation actuelle. Les valeurs seront cependant insérées, mais sans
-aucune transformation.
-</ul>
-</p>
-<p>
-Les tables créées avec <code>CREATE TEMP TABLE</code> seront supprimées à la
-fin de la session en spécifiant DISCARD ALL dans le paramètre de configuration
-reset_query_list si on utilise la version 8.3 ou supérieure de PostgreSQL.
-</p>
-<p>
-Pour les version 8.2.X et précédentes, <code>CREATE TEMP TABLE</code> ne
-sera pas supprimé à la sortie de la session.
-
-Ceci est dû au pooling de connexion, qui, du point de vue du serveur
-PostgreSQL, garde la session en vie.
-
-Pour éviter cela, on doit supprimer explicitement la table dans le bloc de
-transaction, soit en ajoutant un <code>DROP TABLE</code>, soit en créant la
-table temporaire avec <code>CREATE TEMP TABLE ... ON COMMIT DROP</code>.
-
-<h2>Requêtes</h2>
-
-<p>Voici les requêtes qui ne peuvent pas être traitées par pgpool-II&nbsp;:</p>
-
-<h3>INSERT (en mode parallèle)</h3>
-
-<p>On ne peut pas utiliser <code>DEFAULT</code> avec la colonne qui sert de clé
-de partitionnement. Par exemple, si la colonne x dans la table t est la colonne
-qui sert de clé de partitionnement&nbsp;:
-
-<pre>
-INSERT INTO t(x) VALUES (DEFAULT);
-</pre>
-<p>
-est invalide. De même, les fonctions ne peuvent pas être utilisées pour cette
-valeur non plus.</p>
-
-<pre>
-INSERT INTO t(x) VALUES (func());
-</pre>
-<p>
-Les valeurs constantes doivent être utilisées pour un INSERT avec la clé de
-partitionnement.
-
-<code>SELECT INTO</code> et <code>INSERT INTO ... SELECT</code>
-ne sont pas supportés non plus.
-</p>
-
-<h3>UPDATE (en mode parallèle)</h3>
-
-<p>La cohérence des données entre les serveurs pourrait être perdue si la
-colonne qui sert de clé de partitionnement subit des mises à jour. En effet,
-pgpool-II ne re-partitionne pas les données ainsi mises à jour.</p>
-
-<p>Une transaction ne peut pas être annulée (ROLLBACK) si la requête qui a
-causé l'erreur sur un ou plusieurs serveurs PostgreSQL est due à une violation
-de contrainte.</p>
-
-<p>
-Si une fonction est appelée dans la clause <code>WHERE</code>, la requête
-pourrait ne pas être correctement exécutée. Par exemple&nbsp;:
-<pre>
-UPDATE branches set bid = 100 where bid = (select max(bid) from beances);
-</pre>
-</p>
-
-<h3>SELECT ... FOR UPDATE (en mode parallèle)</h3>
-
-<p>Si une fonction est appelée dans la clause <code>WHERE</code>, la requête
-pourrait ne pas être correctement exécutée. Par exemple&nbsp;:
-<pre>
-SELECT * FROM  branches where bid = (select max(bid) from beances) FOR UPDATE;
-</pre>
-</p>
-
-<h3>COPY (en mode parallèle)</h3>
-
-<p><code>COPY BINARY</code> n'est pas supporté.
-
-COPY à partir de fichiers n'est pas non plus supporté. Seuls <code>COPY FROM
-STDIN</code> et <code>COPY TO STDOUT</code> sont supportés.</p>
-
-<h3>ALTER/CREATE TABLE (en mode parallèle)</h3>
-
-<p>Pour mettre à jour une règle de partitionnement, pgpool-II doit être
-redémarré pour qu'il puisse relire les règles dans sa base de données système.</p>
-
-<h3>Transactions (en mode parallèle)</h3>
-
-<p>Les requêtes <code>SELECT</code> exécutées à l'intérieur d'un bloc
-de transactions seront exécutés dans des transactions séparées. Voici un
-exemple&nbsp;:
-
-<pre>
-BEGIN;
-INSERT INTO t(a) VALUES (1);
-SELECT * FROM t ORDER BY a; &lt;&lt; l'INSERT ci-dessus n'est pas visible pour
-                               cette requête SELECT
-END;
-</pre>
-
-<h3>Vues et règles (en mode parallèle)</h3>
-
-<p>
-La même définition de vue ou de règle (RULE) sera créée sur tous les serveurs.
-</p>
-
-<pre>
-SELECT * FROM a, b where a.i = b.i
-</pre>
-<p>
-Les <code>jointures</code> comme celles ci-dessus seront exécutées sur chaque
-serveur, et le résultat de chaque serveur sera intégré pour être retourné au
-client. Les vues et règles ne peuvent pas faire de jointures à travers les
-différents serveurs.
-
-Cependant, pour faire une jointure entre des tables dont les données sont
-présentes sur un même serveur, une vue peut être utilisée.
-
-Cette vue doit être enregistrée dans la table du catalogue
-pgpool_catalog.dist_def. De même, un col_name et un dist_def_func devront
-être enregistrés. Ces derniers sont utilisés lors qu'une insertion est réalisée
-sur la vue.
-</p>
-
-<h3>Fonctions et triggers (en mode parallèle)</h3>
-
-<p>Pour les fonctions, c'est la même définition qui sera utilisée pour leur
-création dans les différents serveurs de données. Comme précédemment, on ne
-peut pas faire de jointure entre les différents serveurs au sein d'une
-fonction.</p>
-
-<h3>Protocole étendu de requêtage (en mode parallèle)</h3>
-
-<p>Le protocole étendu de requêtage (« extended query protocol ») utilisé par les
-connecteurs JDBC, entre autres, n'est pas supporté.
-
-Le protocole simple doit être utilisé à la place. Cela veut dire, entre autres,
-qu'on ne peut pas utiliser les requêtes préparées.</p>
-
-<h3>Jointure naturelle (en mode parallèle)</h3>
-
-<p>Ce n'est pas supporté non plus. Les clauses ON et USING
-doivent être utilisées à la place.</p>
-
-<h3>Clause USING (en mode parallèle)</h3>
-
-<p>La clause USING est convertie en une clause ON par le processus qui réécrit
-les requêtes. Ainsi, lorsque * est utilisé comme liste cible, les colonnes
-jointes apparaissent deux fois.</p>
-<p>
-Voici un exemple&nbsp;:
-</p>
-<p><pre>
-  =# SELECT * FROM t1 JOIN t2 USING(id);
-   id |  t  |   t
-  ----+-----+-------
-    1 | 1st | first
-  (1 row)
-</pre></p>
-<p>
-Le processus de réécriture de requêtes va réécrire USING en ON. Le résultat
-est alors&nbsp;:
-</p><p><pre>
-  =# SELECT * FROM t1 JOIN t2 ON t1.id = t2.id;
-   id |  t  | id |   t
-  ----+-----+----+-------
-    1 | 1st |  1 | first
-  (1 row)
-</pre>
-</p>
-<p>
-On remarque que la colonne t est dupliquée.
-</p>
-
-<h3>Caractères multi-octets (pour tous les modes)</h3>
-
-<p>pgpool-II n'opère pas de traduction entre les différents caractères
-multi-octets. L'encodage utilisé par le client, le serveur et la base de données
-système doit donc être identique.
-</p>
-
-<h3>Requêtes multiples (tous modes)</h3>
-<p>
-pgpool-II ne peut pas prendre en charge les requêtes multiples (plusieurs requêtes
-séparées par un point-virgule, exécutées en un coup).
-</p>
-
-<h3>Deadlocks (en mode parallèle)</h3>
-
-<p>Les deadlocks à travers plusieurs serveurs ne peuvent pas être
-détectés. Par exemple&nbsp;:
-</p>
-<pre>
-(la table "tellers" est partitionnée avec la règle suivante)
-  tid <= 10  --> node 0
-  tid >= 10  --> node 1
-
-A) BEGIN;
-B) BEGIN;
-A) SELECT * FROM tellers WHERE tid = 11 FOR UPDATE;
-B) SELECT * FROM tellers WHERE tid = 1 FOR UPDATE;
-A) SELECT * FROM tellers WHERE tid = 1 FOR UPDATE;
-B) SELECT * FROM tellers WHERE tid = 11 FOR UPDATE;
-</pre>
-<p>
-Dans le cas ci-dessus, un serveur seul ne peut pas détecter de deadlock. Du coup,
-pgpool-II attendra une réponse indéfiniment. Ce phénomène peut apparaître avec
-toute requête qui acquiert un verrou au niveau de l'enregistrement.
-</p>
-<p>Aussi, si un deadlock arrive sur un serveur, l'état de la transaction sur
-chaque serveur ne sera pas cohérent. Ainsi, pgpool-II arrête le processus si
-un deadlock est détecté.
-</p>
-<pre>
-pool_read_kind: kind does not match between master(84) slot[1] (69)
-</pre>
-
-<h3>Schémas (en mode parallèle)</h3>
-
-<p>Les objets qui se trouve dans un autre schéma que public doivent être
-préfixés par le nom du schéma dans lequel ils se trouvent&nbsp;:
-</p>
-<pre>
-schéma.objet
-</pre>
-<p>
-pgpool-II ne peut pas résoudre le nom de schéma correct lorsque le chemin est
-configuré comme suit&nbsp;:
-</p>
-<pre>
-set search_path = xxx
-</pre>
-<p>
-et que le nom du schéma n'est pas précisé dans la requête.
-</p>
-
-<h3>nom de table - nom de colonne (en mode parallèle)</h3>
-
-<p>
-Une table ou un nom de colonne ne peut pas être préfixé par « pool_ ».
-
-En effet, lors de la réécriture des requêtes, ces noms sont utilisés par des
-processus internes à pgpool-II.
-</p>
-
-<h2>Base de données système</h2>
-
-<h3>Règles de partitionnement</h3>
-
-<p>On ne peut définir qu'une seule clé de partitionnement par règle de
-partitionnement. Les condition comme « x ou y » ne sont pas supportées.
-</p>
-
-<h2>Pré-requis de l'environnement</h2>
-
-<h3>libpq</h3>
-
-<p>La bibliothèque <code>libpq</code> est liée lors de la compilation de
-pgpool-II. La version de la libpq doit être la 3.0.
-
-Toute tentative de compilation de pgpool-II avec la version 2.0 de la libpq
-finira par un échec. De même, la base de données système doit être au minimum dans
-une version 7.4 de PostgreSQL.
-</p>
-
-<h2>Cache de requêtes</h2>
-
-<p>Actuellement, le cache de requêtes doit être supprimé manuellement.
-pgpool-II n'a pas de mécanisme d'invalidation de cache automatique lorsque les
-données sont mises à jour.
-</p>
-
-<h2>Compatibilité avec pgpool</h2>
-
-<h1>Référence<a name="reference"></a></h1>
-<h2>Référence des commandes PCP</h2>
-
-<h3>Liste des commandes PCP</h3>
-
-<p>Les commandes PCP sont des commandes UNIX qui interagissent avec pgpool-II à
-travers le réseau.
-
-<pre>
-* pcp_node_count    - retourne le nombre de nœuds (serveurs PostgreSQL)
-* pcp_node_info     - retourne l'information sur un nœud
-* pcp_proc_count    - retourne la liste des processus
-* pcp_proc_info     - retourne l'information sur un processus
-* pcp_systemdb_info - retourne l'information sur la base de donnée système
-* pcp_detach_node   - détache un nœud de pgpool-II
-* pcp_attach_node   - attache un nœud à pgpool-II
-* pcp_stop_pgpool   - stoppe pgpool-II
-</pre>
-</p>
-
-
-<h2>Arguments communs aux outils en ligne de commande</h2>
-
-<p>Il y a cinq arguments qui sont communs à toutes les commandes PCP. Ils donnent
-l'information relative à l'authentification et à pgpool-II. Des arguments
-complémentaires peuvent être nécessaires pour quelques commandes.
-
-<pre>
-$ pcp_node_count 10 localhost 9898 postgres hogehoge
-
-1er argument  - délai maximum en secondes (PCP se déconnecte si 
-                pgpool-II ne répond pas dans le temps imparti ici)
-2nd argument  - nom d'hôte (ou adresse IP) du serveur pgpool-II
-3ème argument - numéro de port de PCP
-4ème argument - nom d'utilisateur de PCP
-5ème argument - mot de passe de l'utilisateur de PCP
-</pre>
-
-<p>Les noms d'utilisateurs et mot de passe PCP doivent être déclarés
-dans le fichier <code>pcp.conf</code> installé dans le répertoire
-<code>$prefix/etc</code>.
-
-L'option <code>-F</code> peut être utilisée lors du démarrage de pgpool-II si
-le fichier <code>pcp.conf</code> est placé ailleurs. Les mots de passe n'ont pas besoin
-d'être au format md5 lorsqu'on les passe aux commandes PCP.
-</p>
-
-
-<h2>Commandes PCP</h2>
-
-<p>Toutes les commandes PCP renvoie les résultats vers la sortie standard.</p>
-
-
-<h3>pcp_node_count</h3>
-
-<pre>
-Format :
-pcp_node_count  _timeout_  _hôte_  _port_  _userid_ _passwd_
-</pre>
-
-<p>
-Affiche le nombre total de nœuds définis dans le fichier <code>pgpool.conf</code>. Il ne
-fait aucune distinction entre le statut des différents nœuds. Ainsi, tous les nœuds
-sont comptés ici.
-</p>
-
-
-<h3><a name="pcp_node_info"/>pcp_node_info</h3>
-
-<pre>
-Format :
-pcp_node_info  _timeout_  _hôte_  _port_  _userid_  _passwd_  _nodeid_
-</pre>
-
-<p>
-Affiche l'information relative au numéro de nœud donné. Voici un exemple de
-sortie&nbsp;:
-</p>
-
-<pre>
-$ pcp_node_info 10 localhost 9898 postgres hogehoge 0
-host1 5432 1 1073741823.500000
-
-Le résultat est dans l'ordre suivant:
-1. nom d'hôte
-2. numéro de port
-3. statut
-4. poids configuré pour la répartition de charge
-
-Le statut est représenté par un chiffre de 0 à 3 :
-
-0 - Cet état est uniquement utilisé pendant l'initialisation. PCP ne l'affichera jamais
-1 - Le nœud est en ligne, mais aucune connexion n'est encore faite dessus
-2 - Le nœud est en ligne, et les connexions sont poolés
-3 - Le nœud est arrêté 
-</pre>
-<p>
-Le poids configuré pour la répartition de charge est affiché dans un format normalisé.
-</p>
-
-<p>
-L'option --verbose peut permettre une meilleure compréhension. Par exemple&nbsp;:
-</p>
-
-<pre>
-$ pcp_node_info --verbose 10 localhost 9898 postgres hogehoge 0
-Hostname: host1
-Port    : 5432
-Status  : 1
-Weight  : 0.5
-</pre>
-
-<p>La spécification d'un identifiant de nœud invalide résultera dans une erreur
-avec un code de sortie 12, et « BackendError » sera alors affiché.</p>
-
-<h3>pcp_proc_count</h3>
-<p>
-<pre>
-Format :
-pcp_proc_count  _timeout_  _host_  _port_  _userid_  _passwd_
-</pre>
-<p>
-Liste les identifiants des processus fils de pgpool-II. S'il y a plus d'un
-processus, les identifiants seront délimités par un espace.
-</p>
-<h3>pcp_proc_info</h3>
-<p>
-<pre>
-Format:
-pcp_proc_info  _timeout_  _host_  _port_  _userid_  _passwd_  _processid_
-</pre>
-<p>
-Affiche l'information d'un processus fils de pgpool-II, désigné par son identifiant de
-processus. Voici un exemple de retour de cette commande&nbsp;:
-</p>
-<pre>
-$ pcp_proc_info 10 localhost 9898 postgres hogehoge 3815
-postgres_db postgres 1150769932 1150767351 3 0 1 1467 1
-postgres_db postgres 1150769932 1150767351 3 0 1 1468 1
-
-Le résultat est affiché dans l'ordre suivant :
-1. nom de la base de données connectée
-2. nom de l'utilisateur connecté
-3. horodatage correspondant au démarrage du processus
-4. horodatage correspondant au démarrage de la connexion
-5. numéro de version majeure du protocole
-6. numéro de version mineure du protocole
-7. compteur du nombre de réutilisations de cette connexion
-8. numéro d'identifiant du processus serveur PostgreSQL
-9. 1 si le client est connecté, 0 sinon
-</pre>
-<p>
-S'il n'y a aucune connexion aux processus serveurs, rien ne sera affiché. S'il y a
-plusieurs connexions, les informations seront affichées sur plusieurs lignes et
-plusieurs fois. Les horodatages sont affichés au format EPOCH.
-</p>
-
-<p>
-L'option --verbose permet de mieux comprendre la sortie de la commande. Par
-exemple&nbsp;:
-</p>
-
-<pre>
-$ pcp_proc_info --verbose 10 localhost 9898 postgres hogehoge 3815
-Database     : postgres_db
-Username     : postgres
-Start time   : 1150769932
-Creation time: 1150767351
-Major        : 3
-Minor        : 0
-Counter      : 1
-PID          : 1467
-Connected    : 1
-Database     : postgres_db
-Username     : postgres
-Start time   : 1150769932
-Creation time: 1150767351
-Major        : 3
-Minor        : 0
-Counter      : 1
-PID          : 1468
-Connected    : 1
-</pre>
-
-<p>La spécification d'un identifiant de nœud invalide résultera dans une erreur
-avec un code de sortie 12, et « BackendError » sera alors affiché.</p>
-
-<h3>pcp_systemdb_info</h3>
-<p>
-<pre>
-Format :
-pcp_systemdb_info  _timeout_  _host_  _port_  _userid_  _passwd_
-</pre>
-<p>
-Affiche des informations sur la base de données système. Voici un exemple de
-sortie :
-</p>
-<pre>
-$ pcp_systemdb_info 10 localhost 9898 postgres hogehoge
-localhost 5432 yamaguti '' pgpool_catalog pgpool 3
-yamaguti public accounts aid 4 aid bid abalance filler integer integer integer character(84) dist_def_accounts
-yamaguti public branches bid 3 bid bbalance filler integer integer character(84) dist_def_branches
-yamaguti public tellers bid 4 tid bid tbalance filler integer integer integer character(84) dist_def_tellers
-
-L'information sur la base de donnée système sera affichée sur la toute première
-ligne. Voici l'ordre des résultats :
-
-1. nom d'hôte
-2. numéro de port
-3. nom d'utilisateur
-4. mot de passe (une chaîne vide s'il n'y en a pas)
-5. nom de schéma
-6. nom de la base de données
-7. nombre de règles de partitionnement définies
-</pre>
-<p>
-
-Ensuite, les règles de partitionnement sont affichées sur les lignes suivantes.
-S'il y a de multiples définitions, elles seront affichées sur autant de lignes
-que nécessaire. Le résultat s'affiche dans l'ordre suivant&nbsp;:
-</p>
-<pre>
-1. le nom de la base de données cible du partitionnement
-2. le nom du schéma dans cette base
-3. le nom de la table dans ce schéma
-4. le nom de la colonne qui sert de clé de partitionnement
-5. le nombre de colonnes dans la table
-6. le nom de ces colonnes (autant de fois que précisé au 5.)
-7. le nom des types de données de ces colonnes (autant de fois que précisé au 5.)
-8. le nom de la fonction utilisée pour la règle de partitionnement
-</pre>
-<p>
-Si la base de données système n'est pas définie (autrement dit, on n'est pas dans un mode
-pgpool-II, et le cache de requêtes est désactivé), on a une erreur avec un
-statut de sortie à 12, et le message « BackendError » est affiché.</p>
-
-
-<h3>pcp_detach_node</h3>
-<pre>
-Format :
-pcp_detach_node  [-g] _timeout_  _host_  _port_  _userid_  _passwd_  _nodeid_
-</pre>
-<p>
-Détache le nœud spécifié de pgpool-II.
-Si l'option -g est donnée, la commande attend que tous les clients soient
-déconnectés (à moins que le paramètre client_idle_limit_in_recovery soit configuré
-à -1 ou que le paramètre recovery_timeout soit expiré).
-</p>
-
-
-<h3>pcp_attach_node</h3>
-<p>
-<pre>
-Format :
-pcp_attach_node  _timeout_  _host_  _port_  _userid_  _passwd_  _nodeid_
-
-Attache le nœud spécifié à pgpool-II.
-</pre>
-</p>
-
-<h3>pcp_stop_pgpool</h3>
-<pre>
-Format :
-pcp_stop_pgpool  _timeout_  _host_  _port_  _userid_  _passwd_  _mode_
-</pre>
-
-<p>
-Arrête le processus pgpool-II dans le mode d'arrêt spécifié. Les
-différents modes d'arrêt sont les suivants&nbsp;:
-</p>
-
-<pre>
-s	- mode intelligent
-f	- mode rapide
-i	- mode immédiat
-</pre>
-<p>
-Si le processus pgpool-II n'existe pas, on a une erreur avec un statut de
-sortie à 8, et le message « ConnectionError » sera affiché.
-</p>
-<p>
-En fait, il n'y a pas de différence  entre les modes rapide et immédiat.
-pgpool-II arrête tous les processus, qu'il y ait des clients connectés aux
-processus serveurs ou pas.</p>
-
-
-<h2>Statuts de sortie</h2>
-
-<p>Les commandes PCP on un code de sortie à 0 lorsque tout se passe bien. Si
-une erreur arrive, ces dernières ont un code de sortie différent, dont voici
-la liste&nbsp;:
-
-<pre>
-UNKNOWNERR      1      Erreur inconnue (ne devrait pas arriver)
-EOFERR          2      Erreur de fin de fichier
-NOMEMERR        3      Erreur liée à une insuffisance de mémoire disponible
-READERR         4      Erreur alors qu'une lecture sur le serveur était en cours
-WRITEERR        5      Erreur alors qu'une écriture sur le serveur était en cours
-TIMEOUTERR      6      Timeout
-INVALERR        7      Les arguments passés à une commande PCP sont invalides
-CONNERR         8      Erreur de connexion au serveur
-NOCONNERR       9      Aucune connexion n'existe
-SOCKERR         10     Erreur de socket unix
-HOSTERR         11     Erreur de résolution de nom d'hôte
-BACKENDERR      12     Erreur sur le processus PCP sur le serveur 
-AUTHERR         13     Erreur d'autorisation
-</pre>
-</p>
-
-<h1>Fonctionnement interne<a name="internal"></a></h1>
-<p>
-La version 2.0 de pgpool-II amène de nombreuses améliorations, en comparaison à
-la version 1. Attention, ce qui suit ne s'applique pas à la version 1.
-</p>
-
-<h2>Moteur d'exécution parallèle</h2>
-<p>
-Le moteur d'exécution parallèle est implémenté dans pgpool-II.
-Ce moteur exécute la même requête sur tous les nœuds, et pilote le moteur qui
-transmet les résultats au client, en fonction de la réponse des différents
-nœuds. 
-</p>
-
-<h2>Réécriture de requêtes</h2>
-<p>
-Cette partie explique le fonctionnement de la réécriture de requêtes que fait
-pgpool-II en mode parallèle.
-</p>
-<p>
-En mode parallèle, une requête transmise par les clients passe par deux étapes
-de traitements&nbsp;:
-</p>
-<ul>
-<li>analyse de la requête&nbsp;;
-<li>réécriture de la requête&nbsp;;
-</ul>
-<p>
-Ce qui suit détaille ces deux étapes.
-</p>
-<h3>Analyse de la requête</h3>
-<h4><p>Introduction</p></h4>
-<p>
-La récupération de la requête soumise par le client passe par l'analyseur SQL.
-Elle est alors analysée grâce aux informations stockées dans la base de données
-système. Le statut d'exécution stocke alors sur quel(s) nœud(s) la requête
-peut être traitée. Par exemple, si les données d'une table sont distribuées sur
-plusieurs serveurs (comme déclaré dans la table pgpool_catalog.dist_def du
-catalogue), ces dernières doivent être récupérées de plusieurs serveurs. 
-
-Ainsi, cette étape retourne le statut P lors que les données doivent être
-récupérées sur tous les serveurs, L quand elles peuvent être récupérées sur
-un seul serveur. Le statut spécial S intervient dans un cas particulier&nbsp;: ce
-dernier signifie qu'il doit y avoir au moins une autre étape exécutée avant
-de pouvoir récupérer les données de tous les serveurs. Par exemple, trier les
-données en provenance d'une table enregistrée dans la table catalogue
-pgpool_catalog.dist_def.
-</p>
-
-<p>
-La requête est analysée dans l'ordre suivant, et son statut d'exécution change
-alors au cours de cette analyse. Comment et où sera exécutée la requête dépend
-du statut final de la requête principale.
-</p>
-
-<ol>
-  <li>Est-ce que UNION, EXTRACT ou INTERSECT sont utilisées&nbsp;?
-  <li>Quel est le statut d'exécution de la clause FROM&nbsp;?
-  <li>Changer le statut d'exécution par TARGETLIST
-  <li>Changer le statut d'exécution en fonction de la clause WHERE
-  <li>Changer le statut d'exécution en fonction de la clause GROUP BY
-  <li>Changer le statut d'exécution en fonction de la clause HAVING
-  <li>Changer le statut d'exécution en fonction de la clause ORDER BY
-  <li>Changer le statut d'exécution en fonction du prédicat LIMIT OFFSET
-  <li>Acquisition du statut final d'exécution du SELECT
-</ol>
-
-<p>
-La relation entre le statut d'exécution final du SELECT et l'endroit où il est
-exécuté est comme suit&nbsp;:
-</p>
-
-<p>
-<table border>
-		<tr><td>Statut d'exécution</td><td>Lieu d'exécution</td></tr>
-		<tr><td align=center>L</td><td>La requête peut-être
-exécutée sur n'importe quel serveur</td></tr>
-		<tr><td align=center>P</td><td>Retourne les données au client
-en exécutant la même requête sur tous les serveurs en utilisant le moteur
-d'exécution en parallèle.</td></tr>
-		<tr><td align=center>S</td><td>Après traitement dans la base de
-données système, les données sont renvoyées au client.</td></tr>
-</table>
-</p>
-
-<p>
-Ces règles s'appliquent aussi aux sous-requêtes. Dans l'exemple simple
-ci-dessous, si la table P1-table est enregistrée dans la table catalogue
-pgpool_catalog.dist_def sur la base de données système (P1-table est alors
-distribuée), le statut d'exécution final de la sous-requête est alors P, et
-comme résultat, la requête parent du SELECT devient alors obligatoirement P.
-</p>
-
-<pre>
-SELECT * FROM (SELECT * FROM P1-table) as P2-table;
-</pre>
-
-<p>
-Il convient d'expliquer à présent comment le statut d'exécution change
-concrètement. Commençons par un exemple simple, pour expliquer le statut lié à
-la clause FROM.
-</p>
-
-
-
-<h4><p>Statut d'exécution de la clause FROM</p></h4>
-<p>
-Ceci est une requête qui récupère des données (SELECT). L'ensemble de données et
-son statut (P, L et S) sont définis en fonction de la clause FROM.
-
-Le statut d'exécution de la table est comme suit&nbsp;: lorsqu'il n'y a qu'une seule
-table dans la clause FROM, le statut d'exécution de l'ensemble de données entier est le
-même que celui de cette table. Lorsqu'il y a deux ou plusieurs tables ou des
-sous-requêtes dans la clause FROM, l'exécution est décidée en fonction de la
-méthode de jointure et des statuts d'exécutions, comme précisé dans la table
-suivante.
-</p>
-
-<p>
-<table border>
-<tr><td>Type de jointure</td><td align = center colspan = 3> LEFT OUTER JOIN
-</td><td align = center colspan = 3> RIGHT OUTER JOIN </td><td align = center
-colspan = 3>FULL OUTER JOIN</td><td align = center colspan = 3>Other</td></tr>
-		<tr><td align = center>left/right</td><td> P </td><td> L </td><td> S </td><td> P </td><td> L </td><td> S </td><td> P </td><td> L </td><td> S </td><td> P </td><td> L </td><td> S </td></tr>
-
-<tr><td align = center> P </td><td> S </td><td> P </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> P </td><td> S </td></tr>
-
-<tr><td align = center> L </td><td> S </td><td> L </td><td> S </td><td> P </td><td> L </td><td> S </td><td> S </td><td> L </td><td> S </td><td> P </td><td> L </td><td> S </td></tr>
-
-<tr><td align = center> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td></tr>
-
-</td></tr>
-</table>
-</p>
-
-<p>
-Dans les exemple suivants, la table P1-table est en statut P.
-Les tables L1-table et L2-table sont dans le statut L.
-<pre>
-SELECT * FROM P1-table,L1-table,L2-table;
-</pre>
-
-
-P1-table (gauche) et L1-table (droite) sont jointes, et en fonction du tableau
-ci-dessus, prennent le statut P. Avec ce statut P, elles sont jointes avec la
-table L2-table, qui est de statut L et qui devient alors en statut P aussi.
-</p>
-
-
-<h4><p>Changement de statut d'exécution dus aux clause TARGETLIST et
-WHERE</p></h4>
-<p>
-Dans une requête simple, le statut d'exécution est le même que celui de la
-clause FROM. Cependant, s'il y a une TARGETLIST, le statut d'exécution de la
-clause WHERE peut changer dans les cas suivants&nbsp;:
-</p>
-<ol>
-	<li>lorsqu'il y a une sous-requête&nbsp;
-	<li>lorsqu'il y a une fonction d'agrégat ou un DISTINCT dans la
-TARGETLIST marquée P&nbsp;
-	<li>lorsqu'une colonne qui n'existe pas dans la table
-(l'ensemble de données) est utilisée dans la clause FROM.
-</ol>
-<p>
-Dans ces cas, le statut d'exécution final de la sous-requête, le statut
-d'exécution de la TARGETLIST et la clause WHERE passent en statut S si leur
-statut initial était P ou S.
-<p>
-Dans l'exemple suivant, lorsqu'une table de statut P est utilisée par une
-sous-requête, le statut d'exécution final de la sous-requête prend le statut P.
-Ainsi, le statut d'exécution de la clause WHERE passe au statut S, quel que
-soit le statut d'exécution de LA, et cette requête est exécutée dans la base de
-données système. 
-<pre>
-	SELECT * FROM L1-table where L1-table.column IN (SELECT * FROM P1-table);
-</pre>
-<p>
-La clause FROM passe au statut S lorsqu'il y a une fonction d'agrégat marquée P
-dans la TARGETLIST, afin de faire cet agrégat après que toutes les données
-aient été récupérées.
-Certaines optimisations sur la fonction d'agrégat sont faites dans des cas
-spécifiques.</p>
-<p>
-Une colonne qui n'existe pas dans la table peut être utilisée dans la requête.
-Par exemple, dans une sous-requête corrélée&nbsp;:
-</p>
-<pre>
-	SELECT * FROM L1-table WHERE L1-table.col1 IN (SELECT * FROM
-P1-table WHERE P1-table.col = L1-table.col1);
-</pre>
-<p>
-Cette sous-requête fait référence à L1-table.col1, dans la table L1-table. Le
-statut d'exécution de la clause WHERE de la sous-requête est S.
-</p>
-
-<h4><p>Changement de statuts d'exécution provoqués par GROUP BY, HAVING, ORDER
-BY et LIMIT/OFFSET</p></h4>
-
-<p>
-Le statut d'exécution de la cause WHERE est changé à S lorsqu'il y a une
-clause GROUP BY, HAVING, ORDER BY ou bien un prédicat LIMIT/OFFSET avec un
-statut P. Une requête sans la clause GROUP BY prend le statut d'exécution de
-la clause WHERE.
-
-De même, le statut d'exécution de la clause GROUP BY est utilisé lorsqu'il n'y
-a pas de clause HAVING. La clause ORDER BY et le prédicat LIMIT/OFFSET ont
-aussi le même comportement.
-</p>
-
-<h4><p>Lorsque UNION, EXTRACT et INTERSECT sont utilisés</p></h4>
-<p>
-Le statut des requêtes avec UNION, EXTRACT, ou INTERSECT dépend des deux statuts
-d'exécution finaux des requêtes gauche et droite à la fois. Si les deux sont
-en P et que la requête est un UNION ALL, le statut d'exécution combiné est P.
-Dans toutes les autres combinaisons, le statut final sera S.
-</p>
-<h4><p>Acquisition du statut d'exécution final d'une requête SELECT</p></h4>
-<p>
-Si tout ce qui est dans le SELECT est de statut L, alors le statut d'exécution
-final est L. La même règle s'applique pour P. Pour toutes les autres
-combinaisons, le statut final est S. Si le statut est L, la charge est
-distribuée sur tous les serveurs lorsque le paramètre loadbalance_mode vaut true,
-sinon elle est envoyée sur le maître (false). Pour P, un traitement parallèle
-est fait grâce au moteur d'exécution parallèle. Pour S, la réécriture de la
-requête est présentée ci-dessous est effectuée.
-</p>
-
-<h3>Réécriture de requête</h3>
-<p>
-La requête est réécrite ou pas en fonction de son statut d'exécution qui est
-acquis lors de l'analyse de la requête.
-Voici un exemple. La table P1-table est de statut P, la table L1-table est elle
-de statut L.
-
-</p>
-<pre>
-SELECT P1-table.col, L1-table.col 
-FROM P1-table,L1-table 
-WHERE P1-table.col = L1-table.col 
-ORDER BY P1-table.col;
-</pre>
-
-<p>
-Dans cette requête, le statut est S à cause de la clause ORDER BY.
-Les clauses FROM, WHERE et TARGETLIST sont de statut P.
-La requête est alors réécrite en quelque chose ressemblant à ceci&nbsp;:
-</p>
-
-<pre>
-SELECT P1-table.col, L1-table.col FROM
-	dblink(select pool_parallel(SELECT P1-table.col, L1-table.col FROM P1-table,L1-table where P1-table.col = L1-table.col)) 
-  	ORDER BY P1-table.col;
-</pre>
-<p>
-dblink transmet ici la requête à pgpool-II.
-La fonction pool_parallel a la responsabilité de transmettre la requête au
-moteur d'exécution parallèle.
-</p>
-<p>Dans cet exemple, les clauses FROM et WHERE, ainsi que la TARGETLIST, sont
-exécutés en mode parallèle. Ceci n'est pas la requête réellement réécrite, mais
-juste fournie en guise d'exemple, par soucis de lisibilité et de
-compréhension.
-</p>
-<p>
-Voici un autre cas&nbsp;:
-</p>
-
-<pre>
-SELECT L1-table.col FROM L1-table WHERE L1-table.col % 2 = 0 AND L1-table.col IN (SELECT P1-table FROM P1-table) ;
-</pre>
-
-<p>
-Dans cet exemple, les clauses FROM, WHERE et la TARGETLIST sont en statut L, à
-cause de la sous-requête qui est de statut P. La requête elle-même est de
-statut S. En conséquence, une réécrite est effectuée comme suit&nbsp;:
-</p>
-<pre>
-	SELECT L1-table.col 
-	  FROM dblink(SELECT loadbalance(SELECT L1-table.col 
-	              FROM L1-table 
-	              WHERE L1-table.col % 2 = 0 
-	                AND TRUE))
-		WHERE
-			L1-table.col %2 = 0 AND 
-		  L1-table.col IN 
-		  (
-		  	SELECT P1-Table FROM 
-		  	dblink(select pool_parallel(SELECT P1-table FROM P1-table))
-		  ) ;
-</pre>
-<p>
-La fonction pool_loadbalance a la responsabilité de répartir les requêtes
-sur les différents nœuds.
-</p>
-
-
-<h3>Réécriture de requêtes pour les fonctions d'agrégat</h3>
-<p>
-Pour les requêtes d'agrégation (fonctions d'agrégat ainsi que GROUP BY), le
-mécanisme de réécriture tente de réduire la charge sur la base de données
-système en exécutant un premier agrégat sur chacun des serveurs.
-</p>
-<p>
-Voyons tout d'abord comment pgpool-II fait cette réécriture.
-</p>
-<p>
-Cette requête est en statut P dans la clause FROM et possède un count(*) dans
-la TARGETLIST.
-Aussi, la réécriture est faite comme suit.
-</p>
-<pre>
-  SELECT count(*) from P1-table;
-
-	-> réécriture
-
-    SELECT
-        sum(pool_c$1) AS count
-    FROM
-        dblink(select pool_parallel('SELECT count(*) FROM  P1-table'))
-					AS pool_$1g (pool_c$1 bigint);
-</pre>
-<p>
-Une réécriture comme ci-dessus est faite dans les conditions suivantes.
-</p>
-<ol>
-		<li>la clause FROM est de statut P&nbsp;;
-		<li>la colonne spécifiée est dans la fonction d'agrégat
-(seulement COUNT, SUM, MIN, MAX et AVG) et GROUP BY est utilisé dans la
-TARGETLIST&nbsp;;
-		<li>la clause WHERE est de statut P&nbsp;;
-		<li>seules les colonnes définies dans la fonction d'agrégat
-(seulement COUNT, SUM, MIN, MAX et AVG), utilisées dans la clause HAVING et la
-clause FROM, et la colonne spécifiée pour le GROUP BY sont utilisées.
-</ol>
-<h3>Notes sur le mode parallèle</h3>
-<p>
-Le nom des colonnes et leur type de données doivent être connus lorsqu'une
-requête est analysée en mode parallèle. Ainsi, lorsqu'une expression ou une
-fonction est utilisée dans la TARGETLIST d'une sous-requête, l'alias et le type
-(via un CAST) sont nécessaires. Si aucun cast n'est défini explicitement dans
-une expression ou une fonction, le type TEXT sera choisi par défaut. Pour
-count(), le type BIGINT est celui par défaut, et pour sum(), NUMERIC. Pour
-min()/max(), si l'argument est de type DATE, le type de données retournée est
-DATE, sinon NUMERIC est utilisé. avg() est traité comme sum()/count() (sum
-divisé par count).
-
-<h3>À propos des performances du mode parallèle</h3>
-<p>Voici une estimation des performances de la requête en fonction de son
-statut d'exécution</p>
-<p>
-<table border>
-		<tr><td>Statut d'exécution</td><td>Performances</td></tr>
-<tr><td align = center>L</td><td>Il n'y a aucune déterioration de performance
-avec un unique serveur, mis à part la sucharge provoquée par pgpool-II,
-parce qu'aucune exécution en parallèle n'est possible.</td></tr>
-<tr><td align = center>P</td><td>Le traitement parallélisé est rapide, en
-particulier, pour les parcours séquentiels. Il est alors aisé d'avoir de grandes
-améliorations de performances car le parcours séquentiel d'une grosse table devient
-un parcours en parallèle sur des tables bien plus petites, distribuées sur
-plusieurs serveurs.
-<tr><td align = center>S</td><td>Lorsque les fonctions d'agrégat peuvent être
-réécrites pour être compatibles avec une exécution en parallèle, elles
-deviennent rapides.</td></tr>
-</td></tr>
-</table>
-</p>
-
-<h1>Tutoriel</h1>
-<p>
-Un <a href="tutorial-en.html">tutoriel (en anglais) pour pgpool-II</a> est
-disponible.
-</p>
-
-<div class="copyright">
-<hr>
-<copyright>
-Copyright &copy; 2003 &ndash; 2010 pgpool Global Development Group
-</copyright>
-</div>
-</body>
-</html>
diff --git a/doc/pgpool-ja.css b/doc/pgpool-ja.css
deleted file mode 100644
index 131b9a5d0..000000000
--- a/doc/pgpool-ja.css
+++ /dev/null
@@ -1,198 +0,0 @@
-ul#navlist
-	{
-	width: 158px>;
-	\width: 160px;
-	w\idth: 158px;
-	padding: 0px;
-	border: 1px solid #808080;
-	border-top: 0px;
-	margin: 0px;
-	font: bold 12px verdana,helvetica,arial,sans-serif;
-	background: #808080;
-	}
-	
-	ul#navlist li
-	{
-	list-style: none;
-	margin: 0px;
-	border: 0px;
-	border-top: 1px solid #808080;
-	font-size:7pt;
-	}
-	
-	ul#navlist li a
-	{
-	display: block;
-	width: 122px;
-	\width: 158px;
-	w\idth: 122px;
-	padding: 4px 8px 4px 8px;
-	border: 0px;
-	border-left: 20px solid #aaaabb;
-	background: #ccccdd;
-	text-decoration: none;
-	text-align: right;
-	
-	}
-	
-	ul#navlist li a:link { color: #666677; }
-	div#navcontainer li a:visited { color: #666677; }
-	
-	ul#navlist li a:hover
-	{
-	border-color: #ff9000;
-	color: #ffffff;
-	background: #000d33;
-	}
-	
-/* --------------------------- */
-#menu {
-	border-right:1px dotted #cccccc;
-	float: left;
-	padding-top: 20px;
-}
-#navcontainer {
-	margin-bottom: 20px;
-}
-#manual {
-	border-left:1px dotted #cccccc;
-	width: 800px;
-	float: left;
-}
-body {
-	font-family:Verdana, Arial, Helvetica, sans-serif;
-	font-size:9pt;
-	margin: 0px;
-	color: black;
-	border-left: 20px solid #ccc;
-}
-pre {
-	background-color:#f0f0f0;
-	color: brown;
-	padding: 5px;
-	margin-left:40px;
-	margin-right:30px;
- 	word-wrap: break-word;
- 	word-break: break-all;
-	overflow: auto;
-}
-h1 {
-	margin-top: 50px;
-	border-bottom: 2px solid #6699CC;
-	padding: 5px;
-	margin-left:10px;
-	background:#6699CC;
-	color: #ffffff;
-}
-h2 {
-	margin-top: 30px;
-	padding: 5px;
-	margin-left:30px;
-	background: #8CD8E2;
-}
-
-h3 {
-	margin-top: 30px;
-	border: 2px solid #8CD8E2;
-	border-left: 10px solid #8CD8E2;
-	padding: 5px;
-	margin-left:40px;
-	background: #F4F8F1;
-}
-
-h4 {
-	border-bottom: 2px solid #8CD8E2;
-	padding: 5px;
-	margin-left:40px;
-	background: #F4F8F1;
-}
-
-p {
-	padding-left: 15px;
-	margin-left:25px;
-	margin-right:25px;
-}
-
-ul, ol,dl {
-	margin-left:40px;
-	padding-right: 30px;
-}
-dt {
-	font-weight:bold;
-}
-
-ul li {
-	padding-right: 30px;
-	list-style:square;
-	color: #663333;
-}
-
-ol li {
-	padding-right: 30px;
-	color: #663333;
-}
-
-
-table {
-	margin-left:40px;
-	border-collapse: collapse;
-	border: #666666 1px solid;
-	margin-bottom: 10px;
-}
-th, td {
-	padding: 5px;
-	font-size:10pt;
-}
-th {
-	font-weight: normal;
-	background-color: #eeeeee;
-}
-th.nodec {
-	text-align: left;
-	white-space: nowrap;
-}
-tr.header th {
-	font-weight: bold;
-	background-color: #cccccc;
-	border-bottom: double;
-}
-tr.center td {
-	text-align: center;
-}
-
-dd {
-	margin-left: 0px;
-}
-	a:link { color: blue; }
-	a:hover { color: red; }
-
-p.top_link {
-	text-align: right;
-}
-p.top_link a {
-	text-decoration: none;
-	border: #aaaaaa 1px solid;
-	border-radius: 3px;
-	background-color: #eeeeee;
-	padding: 1px 5px;
-	color: #666666;
-}
-.header_small {
-	font-size: 0.9em;
-	background-color: #f0f0f0;
-	
-}
-.header_text {
-	border-bottom: 2px solid #663366;
-	padding: 5px;
-	background-color: #E9F8F8;	
-	font-size: 2em;
-	font-weight:bold;
-	padding:25px;
-}
-
-.copyright {
-	padding: 5px;
-	padding:25px;
-	text-align:center;
-}
diff --git a/doc/pgpool-ja.html b/doc/pgpool-ja.html
deleted file mode 100644
index d509cb108..000000000
--- a/doc/pgpool-ja.html
+++ /dev/null
@@ -1,15052 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<html>
-<head>
-<meta http-equiv="content-type" content="text/html;charset=utf-8">
-<link rel="stylesheet" href="./pgpool.css" type="text/css">
-<title>pgpool-II ユーザマニュアル</title>
-</head>
-<body>
-
-<!-- hhmts start -->
-Last modified: Mon Aug 24 18:18:48 JST 2015
-<!-- hhmts end -->
-
-<body bgcolor="#ffffff">
-<div id="top" class="header_text">Welcome to pgpool -II page</div>
-
-<div id="menu">
-    <div id="navcontainer">
-      <ul id="navlist">
-        <li id="active"><a href="#Whatis" id="current">pgpool-IIとは</a></li>
-        <li><a href="#license">ライセンス</a></li>
-        <li><a href="#platform">pgpool-IIの稼働環境</a></li>
-        <li><a href="#install">pgpool-IIのインストール</a></li>
-        <li><a href="#config">pgpool-IIの設定</a></li>
-        <li><a href="#common">共通設定項目</a></li>
-        <li><a href="#connection_pool_mode">コネクションプールモード</a></li>
-        <li><a href="#replication_mode">レプリケーションモード</a></li>
-        <li><a href="#master_slave_mode">マスタースレーブモード</a></li>
-        <li><a href="#stream">Streaming Replicationへの対応</a></li>
-        <li><a href="#hba">クライアント認証(HBA)のための pool_hba.conf 設定方法</a></li>
-        <li><a href="#query_cache">クエリキャッシュの設定方法</a></li>
-        <li><a href="#memqcache">インメモリクエリキャッシュの設定方法</a></li>
-        <li><a href="#start">pgpool-IIの起動と停止</a></li>
-        <li><a href="#reload">pgpool-IIの設定ファイルの再読み込み</a></li>
-        <li><a href="#show-commands">SHOWコマンド</a></li>
-        <li><a href="#online-recovery">オンラインリカバリ</a></li>
-        <li><a href="#backup">バックアップ</a></li>
-        <li><a href="#deploy">pgpool-IIの配置について</a></li>
-        <li><a href="#watchdog">watchdog</a></li>
-        <li><a href="#pcp_command">PCP コマンド</a></li>
-        <li><a href="#pgpool_adm">pgpool_adm</a></li>
-        <li><a href="#troubleshooting">トラブルシューティング</a></li>
-        <li><a href="#restriction">制限事項</a></li>
-        <li><a href="#release">リリースノート</a></li>
-      </ul>
-    </div>
-
-    <div class="header_small" align="center">
-    [<a href="pgpool-en.html">English page</a>]
-    [<a href="pgpool-zh_cn.html">Chinese page</a>]
-    </div>
-</div>
-
-<div id="manual">
-
-<!-- ================================================================================ -->
-
-<h1 style="margin-top: 20px">pgpool-IIとは<a name="whatis"></a></h1>
-<p>
-pgpool-IIはPostgreSQL専用のミドルウェアで、PostgreSQLのデータベースクライアントと
-PostgreSQLサーバの間に割り込む形で動作し、PostgrSQLに以下のような機能を追加します。
-</p>
-
-<ul>
-    <li>コネクションプーリング
-    <p>
-    PostgreSQLへの接続を保存しておき、同じ属性(ユーザ名、データベース、プロトコルバージョン)を持つ接続を
-    受け付けたときに再利用することによって
-    PostgreSQLへの接続オーバヘッドを低減し、システム全体のスループットを向上することができます。
-    </p>
-    </li>
-
-    <li>レプリケーション
-    <p>
-    pgpool-IIは複数のPostgreSQLサーバを管理することができます。レプリケーション機能を使用することにより、
-    物理的に2台以上のDBサーバにリアルタイムでデータを保存することができ、
-    万が一どれかのDBサーバに障害が発生しても運用を継続することができます。
-    </p>
-    </li>
-
-    <li>負荷分散
-    <p>
-    レプリケーションまたマスタースレーブモードで運用している場合、どのサーバに問い合わせても同じ結果が返ってきます。
-    多数の検索リクエストをそれぞれのサーバで分担して負荷を軽減させ、システム全体の性能を向上させることができます。
-    最良の場合にはサーバ台数に比例した性能向上が見込めます。
-    </p>
-    <p>
-    特に多数のユーザが大量の問い合わせを投げるような環境で威力を発揮します。
-    </p>
-    </li>
-
-    <li>接続数の制限
-    <p>
-    PostgreSQLに接続可能なセッション数には上限があり、それを超えて接続することはできません。
-    かと言って、同時セッション数をむやみに多くすると、メモリーなどのリソースが多く消費されて
-    パフォーマンスに影響があります。
-    </p>
-    <p>
-    pgpool-IIでもクライアントからの接続数には上限がありますが、それを超えてもただちにエラーになることはなく、
-    一定の間待たされるようになっています。
-    したがって、pgpool-IIはPostgreSQLへの接続要求を実質的にキューイングし、
-    PostgreSQLへの過大な接続数を制限することが可能です。
-    </p>
-    </li>
-
-</ul>
-
-<p>
-pgpool-IIはPostgreSQLバックエンドとフロントエンドの通信プロトコルを理解してその間を中継します。
-すなわち、PostgreSQLのデータベースアプリケーションからはPostgreSQLサーバに、
-PostgreSQLからはデータベースアプリケーションに見えるように設計されています。
-</p>
-<p>
-そのため、PostgreSQLそのものはもちろん、アプリケーションの開発言語によらず、
-PostgreSQLのデータベースアプリケーションにほとんど手を加えることなく、
-pgpool-IIの機能が利用できます。
-</p>
-<p><strong>一部のSQLには<a href="#restriction">制限事項</a>があります。</strong></p>
-
-<p class="top_link"><a href="#Top">back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1>License<a name="license"></a></h1>
-
-<p>Copyright (c) 2003-2016        PgPool Global Development Group</p>
-<p><br></p>
-<p>
-Permission to use, copy, modify, and distribute this software and
-its documentation for any purpose and without fee is hereby
-granted, provided that the above copyright notice appear in all
-copies and that both that copyright notice and this permission
-notice appear in supporting documentation, and that the name of the
-author not be used in advertising or publicity pertaining to
-distribution of the software without specific, written prior
-permission. The author makes no representations about the
-suitability of this software for any purpose.  It is provided "as
-is" without express or implied warranty.
-</p>
-
-<p class="top_link"><a href="#Top">△ back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1>pgpool-II の稼働環境<a name="platform"></a></h1>
-<p>pgpool-II は、Linux をはじめ、Solaris や FreeBSD などのほとんどの UNIX 環境で動作します。
-Windows では動きません。</p>
-<p>
-対応する PostgreSQL のバージョンは、PostgreSQL の 6.4 以降です。
-また、PostgreSQL 7.4 より前のバージョンでは、使用できる機能に制限事項があります。
-もっとも、そのような古いバージョンの PostgreSQL はそもそも使うべきではありません。
-</p>
-<p>
-pgpool-II 配下で利用する PostgreSQL サーバのメジャーバージョン、
-OS やハードウェアアーキテクチャを同じものにしなければなりません。
-また、バージョンが同じであっても、PostgreSQL のビルド方法が違うものを混ぜている場合の動作は保証できません。
-たとえば、SSL サポートの有無、日付型の実装方法 (--disable-integer-datetimes)、
-ブロックサイズの違いなどは、pgpool-II の一部の機能に影響を与えるでしょう。
-PostgreSQL のマイナーバージョンが違う場合は大抵の場合問題になりませんが、
-すべての PostgreSQL のマイナーバージョンを検証したわけではないので、
-できればマイナーバージョンを合わせておくことをお勧めします。
-</p>
-
-<p class="top_link"><a href="#Top">△ back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1>pgpool-II のインストール<a name="install"></a></h1>
-
-<p>
-Linux 用の RPM パッケージは、CentOS、RedHat Enterprise Linux、Fedora、Debian 用などが提供されています。
-該当リポジトリをチェックしてみてください。
-</p>
-
-<p>
-pgpool-II のソースコードは <a href="http://pgpool.net/mediawiki/index.php/Downloads">pgpool 開発ページ</a> から
-ダウンロードできます。
-</p>
-
-<p>pgpool-II のソースコードからのインストールには、gcc 2.9 以上、および GNU make が必要です。
-また、pgpool-II は libpq（PostgreSQL 付属のクライアントライブラリ）を使用するので、
-ビルドを行うマシン上に libpq がインストールされていることが必要です。</p>
-<p>また、OpenSSL サポートを有効にする場合は、OpenSSL ライブラリと開発用のヘッダーファイルが必要です。</p>
-
-<h2 id="install_pgpool">pgpool-II のインストール</h2>
-
-<dl>
-<dt>configureの実行</dt>
-    <dd>
-    <p>ソースコードのtar ballを展開したら、configureを実行します。</p>
-<pre>
-./configure
-</pre>
-    <p>configureに指定できるオプションは以下です。</p>
-
-    <table border>
-    <tr><th class="nodec"><code>--prefix=path</code></th>
-    <td>pgpool-II 本体や関連ファイルをインストールするトップディレクトリを指定します。
-        デフォルトは /usr/local です。
-    </td></tr>
-    <tr><th class="nodec"><code>--with-pgsql=path</code></th>
-    <td>PostgreSQL のクライアントライブラリなどがインストールされているトップディレクトリを指定します。
-        デフォルトは<code>pg_config</code>コマンドで取得できるパスです。
-    </td></tr>
-    <tr><th class="nodec"><code>--with-openssl</code></th>
-    <td>pgpool-II を OpenSSL サポート付で作成します。
-        デフォルトでは OpenSSL サポートは無効です。
-        <span class="version">V2.3 〜</span>
-    </td></tr>
-    <tr><th class="nodec"><code>--enable-sequence-lock</code></th>
-    <td>pgpool-II 3.0シリーズ (3.0.4まで) 互換の insert_lock を使用します。
-        pgpool-II は、シーケンステーブルの行に対してロックを行います。
-        これは、2011 年 06 月より後にリリースされた PostgreSQL 8.2 以降では使用できません。
-        <span class="version">V3.1 〜</span>
-    </td></tr>
-    <tr><th class="nodec"><code>--enable-table-lock</code></th>
-    <td>pgpool-II 2.2 と 2.3 シリーズ互換の insert_lock を使用します。
-        pgpool-II は、挿入対象のテーブルに対してロックを行ないます。
-        これは、ロックが VACUUM と競合するため非推奨です。
-        <span class="version">V3.1 〜</span>
-    </td></tr>
-    <tr><th class="nodec"><code>--with-memcached=path</code>
-    </th>
-    <td>キャッシュストレージに <a href="memcached_params">memcached</a> を利用し、
-    <a href="#memqcache">インメモリクエリキャッシュ</a>機能を
-        利用したい場合に指定します。
-        <a href="http://libmemcached.org/libMemcached.html">libMemcached</a>のインストールが必要です。
-        <span class="version">V3.2 〜</span>
-    </td></tr>
-    </table>
-    </dd>
-
-<dt>makeの実行</dt>
-    <dd>
-<pre>
-make
-make install
-</pre>
-    </dd>
-</dl>
-
-<h2 id="install_functions">関数の登録</h2>
-
-<h3 id="pgpool_regclass">pgpool_regclass のインストール（オプション） <span class="version">V3.0 〜</span></h3>
-<p>PostgreSQL 8.0 以降、PostgreSQL 9.3までを使用している場合は、pgpool-II が内部で使用する C 関数
-pgpool_regclass をインストールします。</p>
-<p>
-PostgreSQL 9.4以降を使用している場合は、pgpool_regclassのインストールは必要ありません。
-PostgreSQLに同等の関数(to_regclass)が含まれているからです。
-</p>
-<h4>pgpool_regclass とは？</h4>
-<p>
-この関数がインストールされていなくても pgpool-II は動作しますが、違うスキーマで同じテーブル名を定義していて、
-SQL 文の中でスキーマ名を省略している場合に、不具合が生じることがあります（一時テーブルを除く）。
-したがって、可能ならば pgpool_regclass をインストールすることをお勧めします。
-</p>
-
-<h4>関数のインストール</h4>
-<p>このインストールは、pgpool-II がアクセスする予定のすべての PostgreSQL サーバで実施してください。</p>
-<pre>
-$ cd pgpool-II-x.x.x/sql/pgpool-regclass
-$ make
-$ make install
-</pre>
-
-<p>この後に以下か、</p>
-
-<pre>
-$ psql -f pgpool-regclass.sql template1
-</pre>
-
-<p>または</p>
-
-<pre>
-$ psql template1
-=# CREATE EXTENSION pgpool_regclass;
-</pre>
-
-<p>を実行します。</p>
-
-<h4>備考</h4>
-<p>
-pgpool-regclass.sql または <code>CREATE EXTENSION</code> の実行は、
-pgpool-II 経由で利用するデータベース毎に必要になります。
-ただし、template1 データベースに対して "<code>psql -f pgpool-regclass.sql template1</code>" または
-<code>CREATE EXTENSION</code> を実行後に作成されたデータベースでは、
-新たに pgpool-regclass.sql または <code>CREATE EXTENSION</code> を実行する必要はありません。
-</p>
-
-<h3 id="insert_lock_table">insert_lock テーブルの作成 <span class="version">V3.0 〜</span></h3>
-
-<h4>レプリケーションモードでの insert_lock</h4>
-<p>
-レプリケーションモードで insert_lock を利用したい場合は、排他制御用のテーブル
-pgpool_catalog.insert_lock を作成します。
-</p>
-<p>
-insert_lock テーブルが存在しなくても今のところ insert_lock は動作しますが、
-その場合は、挿入対象のテーブルに対してロックが行われます。
-これは pgpool-II 2.2 と 2.3 シリーズの動作と同じです。挿入対象のテーブルに対するロックは、
-VACUUM と競合して INSERT 処理が長時間が待たされる可能性があります。
-</p>
-<p>
-したがって、insert_lock テーブルを作成することをお勧めします。
-テーブルの作成は、pgpool-II がアクセスする予定のすべての PostgreSQL サーバで実施してください。
-</p>
-
-<h4>テーブルの作成</h4>
-<pre>
-$ cd pgpool-II-x.x.x/sql
-$ psql -f insert_lock.sql template1
-</pre>
-
-<h4>備考</h4>
-<p>
-insert_lock.sqlの実行は、pgpool-II経由で利用するデータベース毎に必要になります。
-ただし、"<code>psql -f insert_lock.sql template1</code>" を実行後に作成されたデータベースでは
-自動的に insert_lock.sql の内容が反映されているので、新たに insert_lock.sql を実行する必要はありません。
-</p>
-
-<h3 id="pgpool_recovery">pgpool_recovery のインストール</h3>
-
-<p>後述の <a href="#online_recovery_in_stream_mode">オンラインリカバリ</a> の機能を使う場合には、
-pgpool_recovery, pgpool_remote_start, pgpool_switch_xlog という関数が必要です。</p>
-<p>また管理ツールである pgpoolAdmin の画面上から、バックエンドノードの PostgreSQL を停止・再起動・
-設定再読み込みを行なうことができますが、これには pgpool_pgctl という関数が使われます。</p>
-<p>これらの機能を使いたい場合には、上記の pgpool_regclass と同様の手順でこれらの C 関数を登録します。
-なお、この 4 つの関数は、すべてのデータベースにインストールされている必要はなく、template1 にだけで
-構いません。</p>
-<pre>
-$ cd pgpool-II-x.x.x/sql/pgpool-recovery
-$ make
-$ make install
-</pre>
-
-<p>この後に以下か、</p>
-<pre>
-$ psql -f pgpool-recovery.sql template1
-</pre>
-
-<p>または</p>
-
-<pre>
-$ psql template1
-=# CREATE EXTENSION pgpool_recovery;
-</pre>
-
-<p>を実行します。</p>
-
-<h4 id="pgpool_pgctl">pgpool.pg_ctl の設定 <span class="version">V3.3 〜</span></h4>
-
-<p>pgpool_pgctl 関数は、バックエンドノードの PostgreSQL の 「pgpool.pg_ctl」という
-カスタムパラメータに書かれたコマンドを実行します。
-この関数を使うには、このパラメータに pg_ctl コマンドのパスを指定します。</p>
-<pre>
-ex)
-$ cat &gt;&gt; /usr/local/pgsql/postgresql.conf
-pgpool.pg_ctl = '/usr/local/pgsql/bin/pg_ctl'
-
-$ pg_ctl reload -D /usr/local/pgsql/data
-</pre>
-
-<p class="top_link"><a href="#Top">△ back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1>pgpool-IIの設定<a name="config"></a></h1>
-<p>
-pgpool-IIの設定ファイルはデフォルトでは/usr/local/etc/pgpool.confおよび
-/usr/local/etc/pcp.confです。pgpool-IIは動作モードによって使用できる機能と、
-必要な設定項目が異なります。
-</p>
-<table border>
-
-<tr class="header">
-<th>使用できる機能/モード</th><th>rawモード(*2)</th><th>レプリケーションモード</th>
-<th>マスタスレーブモード</th>
-</tr>
-
-<tr>
-<th>コネクションプーリング</th><td align="center">○</td><td align="center">○</td>
-<td align="center">○</td>
-</tr>
-
-<tr>
-<th>レプリケーション</th><td align="center">×</td><td align="center">○</td>
-<td align="center">×</td>
-</tr>
-
-<tr>
-<th>負荷分散</th><td align="center">×</td><td align="center">○</td>
-<td align="center">○</td>
-</tr>
-
-<tr>
-<th>フェイルオーバ</th><td align="center">○</td><td align="center">○</td>
-<td align="center">○</td>
-</tr>
-
-<tr>
-<th>オンラインリカバリ</th><td align="center">×</td><td align="center">○</td>
-<td align="center">△(*1)</td>
-</tr>
-
-<tr>
-<th>サーバ台数</th><td align="center">1以上</td><td align="center">2以上</td>
-<td align="center">2以上</td>
-</tr>
-
-</table>
-
-<ul>
-    <li>(*1)マスタースレーブモードでは、Streaming Replicationと併用するときにのみ
-        オンラインリカバリが可能です。
-    </li>
-    <li>(*2)単にpgpool-IIを経由して接続するだけのモードです。
-        レプリケーションモードもマスタースレーブモードも有効にしていないときの動作です。
-        PostgreSQLサーバへの接続セッション数を制限したり、2台以上のPostgreSQLサーバを用意して
-        フェイルオーバ動作をさせたいときに利用します。
-    </li>
-</ul>
-
-<!-- ================================================================================ -->
-
-<h1 id="pcp_conf">pcp.confの設定</h1>
-<p>
-どの動作モードでも、pcp.confの設定は必要です。pgpool-IIには管理者がpgpool-IIの
-停止や情報取得などの管理操作を行うためのインターフェイスが用意されています。
-そのインターフェイスを利用するためにはユーザ認証が必要になるので、
-そのユーザ名とパスワードをpcp.confに登録します。
-pgpool-IIをインストールすると、$prefix/etc/pcp.conf.sampleができるので、それを
-$prefix/etc/pcp.confという名前でコピーします。
-</p>
-<pre>
-cp $prefix/etc/pcp.conf.sample $prefix/etc/pcp.conf
-</pre>
-
-<p>
-pcp.confでは空白行や#で始まる行はコメントと見なされます。
-ユーザとパスワードは、
-</p>
-<pre>
-ユーザ名:[md5暗号化したパスワード]
-</pre>
-
-<p>
-のように指定します。
-[md5暗号化したパスワード]は、$prefix/bin/pg_md5コマンドで作成できます。
-</p>
-<pre>
-./pg_md5 foo
-acbd18db4cc2f85cedef654fccc4a4d8
-</pre>
-
-<p>
-パスワードを引数に渡したくない場合は pg_md5 -p を実行してください。
-</p>
-<pre>
-./pg_md5 -p
-password: &lt;パスワードを入力&gt;
-</pre>
-<p>
-pcp.confは、pgpool-IIを動作させるユーザIDで読み取り可能になっていなければ
-なりません。
-</p>
-
-<!-- ================================================================================ -->
-
-<h1 id="pgpool_conf">pgpool.confの設定</h1>
-<h2 id="pgpool_conf_sample">サンプルファイル <span class="version">V2.3 〜</span></h2>
-<p>
-pgpool-IIをインストールすると、インストール先ディレクトリ(デフォルトでは/usr/local)
-/etc/pgpool.conf.sampleができるので、それを
-インストール先ディレクトリ/etc/pgpool.confという名前でコピーします。
-</p>
-<pre>
-cp インストール先ディレクトリ/etc/pgpool.conf.sample $prefix/etc/pgpool.conf
-</pre>
-<p>
-また、各動作モード用のサンプルpgpool.confが用意されています。
-こちらもご利用下さい。
-</p>
-
-<p>
-<table border>
-<tr class="header"><th>動作モード</th><th>サンプルファイル名</th></tr>
-<tr><th>レプリケーションモード</th><td>pgpool.conf.sample-replication</td></tr>
-<tr><th>マスタースレーブモード(Slony-I)</th><td>pgpool.conf.sample-master-slave</td></tr>
-<tr><th>マスタースレーブモード(Streaming replication)</th><td>pgpool.conf.sample-stream</td></tr>
-</table>
-
-</p>
-
-<h2>コメントの扱い</h2>
-<p>
-pgpool.confでは空白行や#で始まる行はコメントと見なされます。
-</p>
-
-<p class="top_link"><a href="#Top">△ back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1><a name="common"></a>共通設定項目</h1>
-<p>
-各動作モードで共通する設定項目を説明します。
-</p>
-
-<h3>Connections</h3>
-
-<dl>
-<dt><a name="LISTEN_ADDRESS"></a>listen_addresses</dt>
-    <dd>
-    <p>
-    pgpool-IIがTCP/IPコネクションを受け付けるアドレスをホスト名またはIPアドレスで指定します。
-    「*」を指定するとすべてのIPインタフェースからのコネクションを受け付けます。
-    「''」を指定するとTCP/IPコネクションを受け付けません。デフォルト値は「localhost」です。
-    UNIXドメインソケット経由のコネクションは常に受け付けます。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-
-<dt><a name="PORT"></a>port</dt>
-    <dd>
-    <p>
-    pgpool-IIがコネクションを受け付けるポート番号です。デフォルト値は9999
-    です。
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-
-<dt><a name="SOCKET_DIR"></a>socket_dir</dt>
-    <dd>
-    <p>
-    pgpool-IIがコネクションを受け付けるUNIXドメインソケットを置くディレクトリです。
-    デフォルト値は'/tmp'です。
-    このソケットは、cronによって削除されることがあるので注意してください。
-    <code>'/var/run'</code>などのディレクトリに変更することをお勧めします。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-
-<dt><a name="PCP_LISTEN_ADDRESS"></a>pcp_listen_addresses</dt>
-    <dd>
-    <p>
-    pcpがTCP/IPコネクションを受け付けるアドレスをホスト名またはIPアドレスで指定します。
-    「*」を指定するとすべてのIPインタフェースからのコネクションを受け付けます。
-    「''」を指定するとTCP/IPコネクションを受け付けません。デフォルト値は「*」です。
-    UNIXドメインソケット経由のコネクションは常に受け付けます。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-
-<dt><a name="PCP_PORT"></a>pcp_port</dt>
-    <dd>
-    <p>
-    pcpが使用するポート番号です。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-
-<dt><a name="PCP_SOCKET_DIR"></a>pcp_socket_dir</dt>
-    <dd>
-    <p>
-    pcpがコネクションを受け付けるUNIXドメインソケットを置くディレクトリです。
-    デフォルト値は'/tmp'です。
-    このソケットは、cronによって削除されることがあるので注意してください。
-    <code>'/var/run'</code>などのディレクトリに変更することをお勧めします。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-
-<h3>Pools</h3>
-
-<dl>
-<dt><a name="NUM_INIT_CHILDREN"></a>num_init_children</dt>
-    <dd>
-    <p>
-    preforkするpgpool-IIのサーバプロセスの数です。デフォルト値は32になっています。
-    これが、pgpool-IIに対してクライアントが同時に接続できる上限の数になります。
-    これを超えた場合は、そのクライアントは、pgpool-IIのどれからのプロセスへのフロントエンドの接続が終了するまで
-    待たされます(PostgreSQLと違ってエラーになりません)。
-    </p>
-    <p>
-    待たされる数の上限は、<code><a href="#LISTEN_BACKLOG_MULTIPLIER">listen_backlog_multiplier</a> *
-    <a href="#NUM_INIT_CHILDREN">num_init_children</a></code> です。
-    待ち行列は、OS内部に作られ、「listenキュー」と呼ばれます。listenキューの長さは「バックログ」と呼ばれます。
-    システムによってはバックログの上限が設定されており、listen_backlog_multiplier * num_init_children が
-    これを越える場合はシステム側の設定変更が必要になります。
-    </p>
-    <p>
-    さもないと高負荷時にlistenキューが溢れ、pgpool-IIへの接続が失敗したり、
-    システム内で行われるリトライにより著しく性能が低下することがあります。
-    </p>
-    <p>
-    listenキューが溢れているかどうかは、"netstat -s"で確認できます。"TcpExt"のパートで、
-    </p>
-<pre>
-535 times the listen queue of a socket overflowed
-</pre>
-    <p>
-    のようなメッセージが出ていればlistenキューが溢れています。
-    listenキュー溢れを防ぐためにバックログを大きくするには、Linuxでは以下のようにします(root権限が必要です)。
-    </p>
-<pre>
-# sysctl net.core.somaxconn
-net.core.somaxconn = 128
-# sysctl -w net.core.somaxconn = 256
-</pre>
-    <p>
-    もちろん、/etc/sysctl.confに以下のように書いても構いません。
-    </p>
-<pre>
-net.core.somaxconn = 256
-</pre>
-    <p>
-    基本的に後述のmax_pool * num_init_children分だけPostgreSQLへのコネクションが張られますが、
-    他に以下の考慮が必要です。
-    </p>
-    <ul>
-        <li>問い合わせのキャンセルを行うと通常のコネクションとは別に新たなコネクションが張られます。
-            したがって、すべてのコネクションが使用中の場合は問い合わせのキャンセルができなくなってしまうので、
-            ご注意下さい。
-            問い合わせのキャンセルを必ず保証したい場合は、想定されるコネクション数の倍の値を
-            設定することをおすすめします。
-        </li>
-        <li>一般ユーザでPostgreSQLに接続できるのは、
-            <code>max_connections - superuser_reserved_connections</code> 分だけです。
-        </li>
-    </ul>
-    <p>
-    以上をまとめると、
-    </p>
-
-    <table border>
-    <tr><th>クエリのキャンセルを考慮しない場合</th>
-        <td>max_pool * num_init_children &lt;=<br>
-            (max_connections - superuser_reserved_connections)</td></tr>
-    <tr><th>クエリのキャンセルを考慮する場合</th>
-        <td>max_pool * num_init_children * 2 &lt;=<br>
-            (max_connections - superuser_reserved_connections)</td></tr>
-    </table>
-
-    <p>
-    のどちらかを満たすように設定してください。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-
-<dt><a name="LISTEN_BACKLOG_MULTIPLIER"></a>listen_backlog_multiplier <span class="version">V3.4 -</span></dt>
-    <dd>
-    <p>
-    フロントエンドからpgpool-IIへの接続待ち行列の長さを制御します。デフォルト値は2です。
-    接続待ち行列(listenシステムコールのbacklogパラメータ)の長さは、
-    <code><a href="#LISTEN_BACKLOG_MULTIPLIER">listen_backlog_multiplier</a> *
-    <a href="#NUM_INIT_CHILDREN">num_init_children</a></code> で決まります。
-    もし待ち行列の長さが不足する場合にはこのパラメータを増やしてください。
-    その際、OSの設定値によっては待ち行列を長く出来ないことがあります。
-    詳細は<a href="#NUM_INIT_CHILDREN">num_init_children</a>の項を参照してください。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-
-<dt><a name="SERIALIZE_ACCEPT"></a>serialize_accept <span class="version">V3.5 -</span></dt>
-    <dd>
-    <p>
-    クライアントからの接続を受け付ける際に accept() の呼び出しをシリアライズするかどうかを指定します。
-    デフォルトはoffです(シリアライズしません)で、これは pgpool-II 3.4 以前と同じ挙動です。
-    </p>
-    <p>
-    このパラメータがoffの場合、カーネルはすべてのpgpool-II子プロセスを起こして accept() を実行させます。
-    そして子プロセスのうちひとつだけが実際に接続を受け付けます。
-    問題は、ここで多くの子プロセスが一度に起こされるため、重いコンテキストスイッチングが起こり、性能に影響がでることです。
-    この現象は「thundering herd problem」と呼ばれる古典的な問題です。
-    serialize_accept を有効にすることにより、pgpool-II子プロセスのうちひとつだけが起こされて accept() を実行するようになり、
-    この問題は回避されます。
-    </p>
-    <p>
-    ではどんなときに serialize_accept を有効にすべきでしょう？
-    num_init_children が大きい時はserialize_accept 有効にすることをおすすめします。
-    num_init_children が小さい時はserialize_accept 有効にしても効果がないかもしれません。
-    むしろシリアライズのオーバヘッドのために性能が低下するかもしれません。
-    どの位の数が「大きい」と言えるかは環境によります。
-    どうするか決める前に、ベンチマークテストを行ってみることをおすすめします。
-    </p>
-    <p>
-    例として以下のような方法でpgbenchを実行します。
-    </p>
-
-<pre>
-pgbench -n -S -p 9999 -c 32 -C -S -T 300 test
-</pre>
-    <p>
-      ここで、 -C は pgbench にトランザクションの実行の度に毎回データベースに接続することを指示します。
-      -c 32 は、pgpool-II への同時接続数です。これはあなたのシステム環境にあわせて変更しましょう。
-      pgbenchが終了すると、"including connections establishing" のところに数字が出てくるのでそれをチェックします。
-    </p>
-    <p>
-    なお、<a href="#CHILD_LIFE_TIME">child_life_time</a> が有効だと、serialize_accept は効果がありません。
-    serialize_accept を有効にしたい場合は、child_life_timeが 0 であることを確認してください。
-    pgpool-IIプロセスのメモリーリークなどの潜在的な問題を気にする場合は、
-    代わりに<a href="#CHILD_MAX_CONNECTIONS">child_max_connections</a> を使ってください。
-    この制限は純粋に実装上の問題であり、将来はなくなるかもしれません。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-
-<dt><a name="CHILD_LIFE_TIME"></a>child_life_time</dt>
-    <dd>
-    <p>
-    pgpool-IIの子プロセスの寿命です。アイドル状態になってから
-    child_life_time秒経過すると、一旦終了して新しいプロセスを起動します。
-    メモリーリークその他の障害に備えた予防措置です。
-    child_life_timeのデフォルト値は300秒、すなわち5分です。
-    0を指定するとこの機能は働きません（すなわち起動しっ放し）。
-    なお、まだ一度もコネクションを受け付けていないプロセスにはchild_life_timeは適用されません。
-    </p>
-    <p>
-      注意: このパラメータが0以外の場合、<a href="#SERIALIZE_ACCEPT">serialize_accept</a> の効果はなくなります。
-    </p>
-    <p>
-    このパラメータを変更した時には設定ファイルを再読み込みしてください。
-    </p>
-    </dd>
-
-<dt><a name="CHILD_MAX_CONNECTIONS"></a>child_max_connections</dt>
-    <dd>
-    <p>
-    各pgpool-II子プロセスへの接続回数がこの設定値を超えると、その子プロセスを終了します。
-    <a href="#CHILD_LIFE_TIME">child_life_time</a> や <a href="#CONNECTION_LIFE_TIME">connection_life_time</a>が
-    効かないくらい忙しいサーバで、
-    PostgreSQLバックエンドが肥大化するのを防ぐのに有効です。
-    </p>
-    <p>
-    このパラメータを変更した時には設定ファイルを再読み込みしてください。
-    </p>
-    </dd>
-
-<dt><a name="CLIENT_IDLE_LIMIT"></a>client_idle_limit</dt>
-    <dd>
-    <p>
-    前回クライアントから来たクエリから、client_idle_limit 秒越えても次の
-    クエリが届かない場合は、クライアントへの接続を強制的に切断し、
-    クライアントからの次のコネクションを待つようにします。
-    この設定は、だらしないクライアントプログラムや、クライアントとpgpoolの間の
-    TCP/IPコネクションが不調なことによって、
-    pgpoolの子プロセスが占有されてしまう問題を回避するのに役立ちます。
-    デフォルト値は 0(無効)です。このパラメータは、オンラインリカバリのセカンドステージでは無視されます。
-    </p>
-    <p>
-    このパラメータを変更した時には設定ファイルを再読み込みしてください。
-    </p>
-    </dd>
-
-<dt><a name="ENABLE_POOL_HBA"></a>enable_pool_hba</dt>
-    <dd>
-    <p>
-    trueならば、pool_hba.confに従ってクライアント認証を行います。
-    詳細は<a href="#hba">クライアント認証(HBA)のためのpool_hba.conf設定方法</a>を参照してください。
-    </p>
-    <p>
-    このパラメータを変更した時には設定ファイルを再読み込みしてください。
-    </p>
-    </dd>
-
-<dt><a name="POOL_PASSWD"></a>pool_passwd</dt>
-    <dd>
-    <p>
-    md5 認証で用いる認証ファイルのファイル名を指定します。
-    デフォルト値は "pool_passwd" です。
-    空文字列（""）を指定すると 認証ファイルの読込は無効になります。
-    詳細は<a href="#md5">認証・アクセス制御方式</a>を参照してください。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-
-<dt><a name="AUTHENTICATION_TIMEOUT"></a>authentication_timeout</dt>
-    <dd>
-    <p>
-    認証処理のタイムアウト時間を秒単位で指定します。0 を指定するとタイムアウトを無効にします。
-    authentication_timeout のデフォルト値は60です。
-    </p>
-    <p>
-    このパラメータを変更した時には設定ファイルを再読み込みしてください。
-    </p>
-    </dd>
-</dl>
-
-<h3>Logs</h3>
-
-<dl>
-<dt><a name="LOG_DESTINATION"></a>log_destination <span class="version">V3.1 〜</span></dt>
-    <dd>
-    <p>
-    pgpool-IIは、stderrかsyslogのどちらかにログを書くことができます。デフォルトはstderrです。
-    </p>
-    <p>
-    注意:syslogを使う場合は、syslogデーモンの設定を変更する必要があります。
-    </p>
-    <p>
-    pgpool-IIは、syslog ファシリティ LOCAL0 から LOCAL7 までにログを書くことができます
-    (syslog_facilityをご覧ください)。
-    しかし、ほとんどのデフォルトのsyslog設定は、そのようなメッセージを廃棄してしまいます。
-    そこで、syslogデーモンの以下のような設定が必要になります。
-    </p>
-<pre>
-local0.*    /var/log/pgpool.log
-</pre>
-    </dd>
-
-<dt><a name="PRINT_TIMESTAMP"></a>print_timestamp</dt>
-    <dd>
-    <p>
-    trueならばpgpool-IIのログにタイムスタンプを追加します。デフォルトはtrueです。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-
-<dt><a name="PRINT_USER"></a>print_user</dt>
-    <dd>
-    <p>
-    trueならばpgpool-IIのログにセッションユーザ名を追加します。デフォルトはfalseです。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-
-
-    <dt><a name="LOG_LINE_PREFIX"></a>log_line_prefix</dt>
-    <dd>
-    <p>
-    ログの先頭に付加する文字列をprintfのようなスタイルで指定します。
-    「%」はエスケープ文字で、この後の文字は以下のように置換えをされて出力されます。
-    認識できないエスケープ指定は無視されます。それ以外の文字はそのままログに出力されます。
-    log_line_prefixのデフォルトは '%t: pid %p: 'で、タイムスタンプとプロセスIDを印字します。
-    これは、3.4より前のバージョンとの互換性を保つためです。
-    </p>
-    <table border>
-    <tr class="header"><th>エスケープ文字</th><th>効果</th></tr>
-    <tr><td>%a</td><td>クライアントのアプリケーション名</td></tr>
-    <tr><td>%p</td><td>プロセスID (PID)</td></tr>
-    <tr><td>%P</td><td>プロセス名</td></tr>
-    <tr><td>%t</td><td>タイムスタンプ</td></tr>
-    <tr><td>%d</td><td>データベース名</td></tr>
-    <tr><td>%u</td><td>ユーザ名</td></tr>
-    <tr><td>%l</td><td>プロセスごとのログ行番号</td></tr>
-    <tr><td>%%</td><td>'%' 文字自身</td></tr>
-    </table>
-    <p>
-    このパラメータを変更した時には設定ファイルを再読み込みしてください。
-    </p>
-    </dd>
-
-<dt><a name="LOG_ERROR_VERBOSITY"></a>log_error_verbosity</dt>
-    <dd>
-    <p>
-      ログメッセージの詳細度を指定します。
-    TERSE, DEFAULT, VERBOSEの順に詳細になります。
-    TERSE では、DETAIL, HINT, CONTEXTの各メッセージが含まれなくなります。
-    </p>
-    <p>
-    このパラメータを変更した時には設定ファイルを再読み込みしてください。
-    </p>
-    </dd>
-
-<dt><a name="LOG_CONNECTIONS"></a>log_connections</dt>
-    <dd>
-    <p>
-    trueならば、全てのクライアント接続をログへ出力します。
-    </p>
-    <p>
-    このパラメータを変更した時には設定ファイルを再読み込みしてください。
-    </p>
-    </dd>
-
-<dt><a name="CLIENT_MIN_MESSAGES"></a>client_min_messages</dt>
-    <dd>
-    <p>
-    クライアントに送る最低メッセージレベルを設定します。
-    DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, LOG, NOTICE,
-    WARNING, ERROR が指定でき、左に行くほど冗長です。
-    デフォルトは NOTICE です。
-    </p>
-    <p>
-    このパラメータを変更した時には設定ファイルを再読み込みしてください。
-    </p>
-    </dd>
-
-<dt><a name="LOG_MIN_MESSAGES"></a>log_min_messages</dt>
-    <dd>
-    <p>
-    ログに書き出す最低メッセージレベルを設定します。
-    DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, INFO, NOTICE,
-    WARNING, ERROR, LOG, FATAL, PANIC が指定でき、左に行くほど冗長です。
-    デフォルトは WARNING です。
-    </p>
-    <p>
-    このパラメータを変更した時には設定ファイルを再読み込みしてください。
-    </p>
-    </dd>
-
-<dt><a name="LOG_HOSTNAME"></a>log_hostname</dt>
-    <dd>
-    <p>
-    trueならば、psコマンドでの状態表示時にIPアドレスではなく、ホスト名を表示します。
-    また、<a href="#LOG_CONNECTIONS">log_connections</a>が有効な場合にはログにホスト名を出力します。
-    </p>
-    <p>
-    このパラメータを変更した時には設定ファイルを再読み込みしてください。
-    </p>
-
-<dt><a name="LOG_STATEMENT"></a>log_statement</dt>
-    <dd>
-    <p>
-    trueならばSQL文をログ出力します。この役目はPostgreSQLのlog_statementオプションと似ていて、
-    デバッグオプションがないときでも問い合わせをログ出力して調べることができるので便利です。
-    </p>
-    <p>
-    このパラメータを変更した時には設定ファイルを再読み込みしてください。
-    </p>
-    </dd>
-
-<dt><a name="LOG_PER_NODE_STATEMENT"></a>log_per_node_statement <span class="version">V2.3 〜</span></dt>
-    <dd>
-    <p>
-    <a href="#LOG_STATEMENT">log_statement</a>と似ていますが、DBノード単位でログが出力されるので、
-    レプリケーションや負荷分散の確認が容易です。
-    </p>
-    <p>
-    このパラメータを変更した時には設定ファイルを再読み込みしてください。
-    </p>
-    </dd>
-
-<dt><a name="SYSLOG_FACILITY"></a>syslog_facility <span class="version">V3.1 〜</span></dt>
-    <dd>
-    <p>
-    syslogが有効な場合、このパラメータによってsyslogの「ファシリティ」を設定します。
-    LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7から選択します。
-    デフォルトは LOCAL0 です。
-    併せてsyslogデーモンのドキュメントもご覧ください。
-    </p>
-    </dd>
-
-<dt><a name="SYSLOG_IDENT"></a>syslog_ident <span class="version">V3.1 〜</span></dt>
-    <dd>
-    <p>
-    syslogが有効な場合、このパラメータによってsyslogのメッセージにあらわれるプログラム名を設定します。
-    デフォルトは"pgpool"です。
-    </p>
-    </dd>
-
-<dt><a name="DEBUG_LEVEL"></a>debug_level <span class="version">V3.0 〜</span></dt>
-    <dd>
-    <p>
-    デバッグメッセージの詳細レベル。0でデバッグメッセージの出力なし。
-    1以上でデバッグメッセージを出力します。
-    数字が大きければより詳細なメッセージが出力されるようになります
-    (3.0では今のところメッセージの詳細度は変りません)。
-    デフォルト値は0です。
-    </p>
-    </dd>
-</dl>
-
-<h3>File locations</h3>
-
-<dl>
-<dt><a name="PID_FILE_NAME"></a>pid_file_name <span class="version">V2.2 〜</span></dt>
-    <dd>
-    <p>
-    pgpool-IIのpid file(プロセスIDを格納したファイル)のフルパス名です。
-    デフォルト値は'/var/run/pgpool/pgpool.pid'です。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-
-<dt><a name="LOGDIR"></a>logdir</dt>
-    <dd>
-    <p>
-    このディレクトリ下に、pgpool-IIのDBノードの状態を記録するpgpool_statusファイルが書かれます。
-    </p>
-    </dd>
-</dl>
-
-<h3>Connction pooling</h3>
-
-<dl>
-<dt><a name="CONNECTION_CACHE"></a>connection_cache</dt>
-    <dd>
-    <p>
-    trueならPostgreSQLへのコネクションをキャッシュします。デフォルトはonです。
-    ただし、connection_cacheがonでも、template0、template1、postgres、
-    regression データベースへの接続はキャッシュされません。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-</dl>
-
-<h3>Health check</h3>
-
-<dl>
-<dt><a name="HEALTH_CHECK_TIMEOUT"></a>health_check_timeout</dt>
-    <dd>
-    <p>
-    pgpool-IIはサーバ障害やネットワーク障害を検知するために、定期的にバックエンドに接続を試みます。
-    これを「ヘルスチェック」と言います。障害が検知されると、フェイルオーバや縮退運転を試みます。
-    </p>
-    <p>
-    この パラメータは、ネットワークケーブルが抜けた際などにヘルスチェックが長時間待たされるのを防ぐための
-    タイムアウト値を秒単位で指定します。
-    デフォルトは20秒です。0を指定するとタイムアウト処理をしません
-    (すなわち TCP/IP のタイムアウトまで待つことになります)。
-    </p>
-    <p>
-    なお、ヘルスチェックを有効にすると、ヘルスチェックのための余分の接続が1つ必要になりますので、
-    PostgreSQLのpostgresql.confの設定項目のmax_connectionsを少くとも1増やすようにしてください。
-    </p>
-    <p>
-    このパラメータを変更した時には設定ファイルを再読み込みしてください。
-    </p>
-    </dd>
-
-<dt><a name="HEALTH_CHECK_PERIOD"></a>health_check_period</dt>
-    <dd>
-    <p>
-    ヘルスチェックを行う間隔を秒単位で指定します。0を指定するとヘルスチェックを行いません。
-    デフォルトは0です(つまりヘルスチェックを行いません)。
-    このパラメータを変更した時には設定ファイルを再読み込みしてください。
-</p>
-</dd>
-
-<dt><a name="HEALTH_CHECK_USER"></a>health_check_user</dt>
-    <dd>
-    <p>
-    ヘルスチェックを行うためのPostgreSQLユーザ名です。
-    このユーザ名はPostgreSQLに登録済みでなければなりません。
-    さもないと、ヘルスチェックがエラーとなります。
-    </p>
-    <p>
-    このパラメータを変更した時には設定ファイルを再読み込みしてください。
-    </p>
-    </dd>
-
-<dt><a name="HEALTH_CHECK_PASSWORD"></a>health_check_password <span class="version">V3.1 〜</span></dt>
-    <dd>
-    <p>
-    ヘルスチェックを行うためのPostgreSQLパスワードです。
-    </p>
-    <p>
-    このパラメータを変更した時には設定ファイルを再読み込みしてください。
-    </p>
-    </dd>
-
-<dt><a name="HEALTH_CHECK_DATABASE"></a>health_check_database <span class="version">V3.5 -</span></dt>
-    <dd>
-    <p>ヘルスチェックを行う対象のデータベース名を指定します。
-    デフォルトは '' で、この場合最初に「postgres」データベースを試し、
-    それに接続できない場合は「template1」データベースを試します。これはpgpool-II 3.4以前の挙動と同じです。
-    </p>
-    <p>
-    このパラメータを変更した時には設定ファイルを再読み込みしてください。
-    </p>
-    </dd>
-
-<dt><a name="HEALTH_CHECK_MAX_RETRIES"></a>health_check_max_retries <span class="version">V3.2 〜</span></dt>
-    <dd>
-    <p>
-    ヘルスチェックに失敗した後(したがってフェイルオーバする前に)リトライする回数を指定します。
-    この設定は動作にむらのあるネットワーク環境において、マスタが正常であるにも関わらず
-    たまにヘルスチェックが失敗することが予想される場合に有用です。
-    デフォルト値は0で、この場合はリトライをしません。
-    この設定を有効にする場合は、併せて<a href="#FAIL_OVER_ON_BACKEND_ERROR">fail_over_on_backend_error</a>を
-    offにすることをお勧めします。
-    </p>
-    <p>
-    health_check_max_retriesを変更した場合は、pgpool.confの再読込が必要です。
-    </p>
-    </dd>
-
-<dt><a name="HEALTH_CHECK_RETRY_DELAY"></a>health_check_retry_delay <span class="version">V3.2 〜</span></dt>
-    <dd>
-    <p>
-    ヘルスチェックのリトライの間の秒数を指定します(health_check_max_retries &gt; 0でなければ有効になりません)。
-    0を指定すると、待ちなしに直ちにリトライします。
-    </p>
-    <p>
-    <a href="#HEALTH_CHECK_RETRY_DELAY">health_check_retry_delay</a>を変更した場合は、pgpool.confの再読込が必要です。
-    </p>
-    </dd>
-
-<dt><a name="CONNECT_TIMEOUT"></a>connect_timeout <span class="version">V3.4 -</span></dt>
-    <dd>
-      <p>connect()システムコールを使ってバックエンドに接続する際のタイムアウト値をミリ秒単位で指定します。
-        デフォルトは10000ミリ秒(10秒)です。不安定なネットワークを使わなければならない場合は、この値を大きくすると良いでしょう。
-        0を指定すると、タイムアウトしません。
-      </p>
-    <p>
-    <a href="#CONNECT_TIMEOUT">connect_timeout</a>を変更した場合は、pgpool.confの再読込が必要です。
-    </p>
-    </dd>
-
-    <dt><a name="SEARCH_PRIMARY_NODE_TIMEOUT"></a>search_primary_node_timeout <span class="version">V3.3 -</span></dt>
-    <dd>
-    <p>このパラメータはフェイルオーバが起きた時にプライマリノードを検索する際のタイムアウト時間を秒単位で指定します。
-        デフォルト値は300です。
-        pgpool-IIは、フェイルオーバの際にここで指定した時間プライマリノードを検索し続けます。
-        0を指定すると、永久に検索し続けます。
-        このパラメータはストリーミングレプリケーションモードで運用している場合以外は無視されます。
-    </p>
-    <p>
-    search_primary_node_timeoutを変更した場合は、pgpool.confの再読込が必要です。
-    </p>
-    </dd>
-
-</dl>
-
-<h3>Failover and failback</h3>
-
-<dl>
-<dt><a name="FAILOVER_COMMAND"></a>failover_command</dt>
-    <dd>
-    <p>
-    ノードが切り離された時に実行するコマンドを指定します。特殊文字を指定すると、
-    pgpool が必要な情報に置き換えてコマンドを実行します。
-    </p>
-
-    <center>
-    <table border>
-    <tr class="header"><th>文字</th><th>意味</th></tr>
-    <tr><td>%d</td><td>切り離されたノード番号</td></tr>
-    <tr><td>%h</td><td>切り離されたノードのホスト名</td></tr>
-    <tr><td>%H</td><td>新しいマスターのホスト名</td></tr>
-    <tr><td>%p</td><td>切り離されたノードのポート番号</td></tr>
-    <tr><td>%D</td><td>切り離されたノードのデータベースクラスタパス</td></tr>
-    <tr><td>%M</td><td>古いマスターのノード番号</td></tr>
-    <tr><td>%m</td><td>新しいマスターのノード番号</td></tr>
-    <tr><td>%P</td><td>古いプライマリノード番号</td></tr>
-    <tr><td>%r</td><td>新しいマスターのポート番号</td></tr>
-    <tr><td>%R</td><td>新しいマスターのデータベースクラスタパス</td></tr>
-    <tr><td>%%</td><td>'%'文字</td></tr>
-    </table>
-    </center>
-
-    <p>
-    このパラメータを変更した時には設定ファイルを再読み込みしてください。
-    </p>
-    <p>
-    フェイルオーバー時には、pgpoolはまず子プロセスを切断します(結果として、すべてのセッションが切断されます)。
-    次に、pgpoolはフェイルオーバコマンドを実行し、その完了を待ちます。
-    そのあとで新しいpgpoolの子プロセスが起動され、クライアントからの接続を受け付けられる状態になります。
-    </p>
-    </dd>
-
-<dt><a name="FAILBACK_COMMAND"></a>failback_command</dt>
-    <dd>
-    <p>
-    ノードが復帰した時に実行するコマンドを指定します。特殊文字を指定すると、
-    pgpool が必要な情報に置き換えてコマンドを実行します。
-    </p>
-
-    <center>
-    <table border>
-    <tr class="header"><th>文字</th><th>意味</th></tr>
-    <tr><td>%d</td><td>復帰したノード番号</td></tr>
-    <tr><td>%h</td><td>復帰したノードのホスト名</td></tr>
-    <tr><td>%p</td><td>復帰したノードのポート番号</td></tr>
-    <tr><td>%D</td><td>復帰したノードのデータベースクラスタパス</td></tr>
-    <tr><td>%M</td><td>古いマスターのノード番号</td></tr>
-    <tr><td>%m</td><td>新しいマスターのノード番号</td></tr>
-    <tr><td>%H</td><td>新しいマスターのホスト名</td></tr>
-    <tr><td>%P</td><td>古いプライマリノード番号</td></tr>
-    <tr><td>%r</td><td>新しいマスターのポート番号</td></tr>
-    <tr><td>%R</td><td>新しいマスターのデータベースクラスタパス</td></tr>
-    <tr><td>%%</td><td>'%'文字</td></tr>
-    </table>
-    </center>
-
-    <p>
-    このパラメータを変更した時には設定ファイルを再読み込みしてください。
-    </p>
-    </dd>
-
-<dt><a name="FOLLOW_MASTER_COMMAND"></a>follow_master_command <span class="version">V3.1 〜</span></dt>
-    <dd>
-    <p>
-    マスターノードのフェイルオーバー後に実行するコマンドを指定します。
-    これは、マスタースレーブモードでストリーミングレプリケーション構成の場合のみ有効です。
-    特殊文字を指定すると、pgpool が必要な情報に置き換えてコマンドを実行します。
-    </p>
-
-    <center>
-    <table border>
-    <tr class="header"><th>文字</th><th>意味</th></tr>
-    <tr><td>%d</td><td>切り離されたノード番号</td></tr>
-    <tr><td>%h</td><td>切り離されたノードのホスト名</td></tr>
-    <tr><td>%p</td><td>切り離されたノードのポート番号</td></tr>
-    <tr><td>%D</td><td>切り離されたノードのデータベースクラスタパス</td></tr>
-    <tr><td>%M</td><td>古いマスターのノード番号</td></tr>
-    <tr><td>%m</td><td>新しいマスターのノード番号</td></tr>
-    <tr><td>%H</td><td>新しいマスターのホスト名</td></tr>
-    <tr><td>%P</td><td>古いプライマリノード番号</td></tr>
-    <tr><td>%r</td><td>新しいマスターのポート番号</td></tr>
-    <tr><td>%R</td><td>新しいマスターのデータベースクラスタパス</td></tr>
-    <tr><td>%%</td><td>'%'文字</td></tr>
-    </table>
-    </center>
-
-    <p>
-    このパラメータを変更した時には設定ファイルを再読み込みしてください。
-    </p>
-
-    <p>
-    空文字列以外を指定すると、マスターノードのフェイルオーバー後に新しいマスター以外のすべてのノードは切り離され、
-    クライアントから再び接続を受け付けるために子プロセスの再起動が行われます。
-    その後、切り離されたそれぞれのノードに対してfollow_master_commandに指定したコマンドが実行されます。
-    通常は、ここに <a href="#pcp_recovery_node">pcp_recovery_node</a> コマンドを組み込んだシェルスクリプトなどを
-    指定し、新しいマスターからスレーブをリカバリするために使用します。
-    </p>
-    </dd>
-
-<dt><a name="FAIL_OVER_ON_BACKEND_ERROR"></a>fail_over_on_backend_error <span class="version">V2.3 〜</span></dt>
-    <dd>
-    <p>
-    trueならば、バックエンドのソケットへからの読み出し、書き込みに失敗するとフェイルオーバします。
-    falseにすると、フェイルオーバせず、単にエラーがレポートされてセッションが切断されます。
-    このパラメータをfalseにする場合には、health checkを有効にすることをお勧めします。
-    なお、このパラメータがfalseの場合でも、バックエンドがシャットダウンされたことを
-    pgpool-IIが検知した場合にはフェイルオーバが起きることに注意してください。
-    </p>
-    <p>
-    このパラメータを変更した時には設定ファイルを再読み込みしてください。
-    </p>
-    </dd>
-</dl>
-
-<h3>Load balancing mode</h3>
-
-<dl>
-<dt><a name="IGNORE_LEADING_WHITE_SPACE"></a>ignore_leading_white_space</dt>
-    <dd>
-    <p>
-    trueならば、load balanceの際にSQL文行頭の空白を無視します(全角スペースは無視されません)。
-    これは、DBI/DBD:Pgのように、勝手に行頭にホワイトスペースを追加するようなAPIを使い、
-    ロードバランスしたいときに有効です。
-    </p>
-    <p>
-    このパラメータを変更した時には設定ファイルを再読み込みしてください。
-    </p>
-    </dd>
-
-    <dt id="ALLOW_SQL_COMMENTS">allow_sql_comments <span class="version">V3.4 〜</span></dt>
-    <dd>
-    <p>
-      onならば、負荷分散やクエリキャッシュができるかどうかの判定の際にSQLコメントを無視します。
-      offならば、その判定に影響を与えます(3.4より前のバージョンの動作です)。
-    </p>
-    <p>
-    このパラメータを変更した時には設定ファイルを再読み込みしてください。
-    </p>
-    </dd>
-
-</dl>
-
-<h3>Backends</h3>
-
-<dl>
-<dt><a name="BACKEND_HOSTNAME"></a>backend_hostname</dt>
-    <dd>
-    <p>
-    使用するPostgreSQLサーバのホスト名を指定します。
-    pgpool-IIは、このホスト名を使ってPostgreSQLと通信します。
-    </p>
-    <p>
-    TCP/IPを使用する場合、ホスト名またはIPアドレスを指定できます。
-    "/"で始まる文字列を指定すると、TCP/IPではなく、UNIXドメインソケットを使用され、
-    ディレクトリ名とみなしてそこにソケットファイルが作成されることになります。
-    空文字(<code>''</code>)を指定すると、<code>/tmp</code>下に作成したUNIXドメインソケットで接続します。
-    </p>
-    <p>
-    実際には、"backend_hostname"の後に0, 1, 2...と数字を付加して使用する複数
-    のPostgreSQLを区別します(たとえば<code>backend_hostname0</code>)。
-    この数字のことを「DBノードID」と呼び、0から開始します。
-    DBノードID == 0のPostgreSQLは、特別に「マスターDB」と呼ばれます。
-    複数のDBノードを運用している場合、条件によってはマスターDBがダウンしても運用を続けることができます。
-    この場合は、稼働中かつDBノードIDがもっとも若いものが新しいマスターDBになります。
-    </p>
-    <p>
-    ただし、ストリーミングレプリケーションモードで運用している場合は、
-    DBノードIDが0のノードには特別な意味はなく、プライマリノードかどうかが問題になります。
-    詳細は<a href="#stream">Streaming Replicationへの対応</a>をご覧ください。
-    <p>
-    1台しかPostgreSQLを使用しない場合は、"backend_hostname0"としてください。
-    </p>
-    <p>
-    backend_hostname は新しく追加した行を設定ファイル再読み込みで追加することができます。
-    すでにある情報を途中で変更することはできません。
-    変更する場合には pgpool-II を再起動してください。
-    </p>
-    </dd>
-
-<dt><a name="BACKEND_PORT"></a>backend_port</dt>
-    <dd>
-    <p>
-    使用するPostgreSQLサーバのポート番号を指定します。
-    実際には、"backend_port"の後に0, 1, 2...とDBノードIDを付加して使用する複数のPostgreSQLを区別します。
-    1台しかPostgreSQLを使用しない場合は、"backend_port0"としてください。
-    </p>
-    <p>
-    backend_port は新しく追加した行を設定ファイル再読み込みで追加することができます。
-    すでにある情報を途中で変更することはできません。変更する場合には pgpool-II を再起動してください。
-    </p>
-    </dd>
-
-<dt><a name="BACKEND_WEIGHT"></a>backend_weight</dt>
-    <dd>
-    <p>
-    使用するPostgreSQLサーバに対する負荷分散の比率を0以上の整数または浮動小数点で指定します。
-    "backend_weight"の後には、DBノードIDを付加して使用する複数のPostgreSQLを区別します。
-    1台しかPostgreSQLを使用しない場合は、"backend_weight0"としてください。
-    負荷分散を使用しない場合は、「1」を設定してください。
-    </p>
-    <p>
-    backend_weight は新しく追加した行を設定ファイル再読み込みで追加することができます。
-    pgpool-II 2.2.6/2.3以降では、設定ファイルの再読込でbackend_weight値を変更できます。
-    新しく接続したクライアントセッションから、この新しいweight値が反映されます。
-    マスタースレーブモードにおいて、あるスレーブに対して管理業務を実施する都合上、
-    問い合わせがそのスレーブに送られるのを防ぎたい場合に有用です。
-    </p>
-    </dd>
-
-<dt><a name="BACKEND_DATA_DIRECTORY"></a>backend_data_directory</dt>
-    <dd>
-    <p>
-    使用する PostgreSQL サーバのデータベースクラスタのパスを指定します。
-    実際には、"backend_data_directory"の後にDBノードIDを付加して使用する複数のPostgreSQLを区別します。
-    このパラメータはオンラインリカバリの際に使用します。
-    オンラインリカバリを使用しない場合には設定する必要はありません。
-    </p>
-    <p>
-    backend_data_directory は新しく追加した行を設定ファイル再読み込みで追加することができます。
-    すでにある情報を途中で変更することはできません。変更する場合には pgpool-II を再起動してください。
-    </p>
-    </dd>
-
-<dt><a name="BACKEND_FLAG"></a>backend_flag <span class="version">V3.1 〜</span></dt>
-    <dd>
-    <p>
-    バックエンド単位での様々な挙動を制御するフラグです。
-    実際には、"backend_flag"の後に数字を付けて、どのバックエンドのフラグか指定します。
-    </p>
-    <p>
-    例: <code>backend_flag0</code>
-    </p>
-    <p>
-    複数のフラグを"|"で連結して指定することができます。
-    現在以下のものがあります。
-    </p>
-
-    <table border>
-    <tr><th class="nodec">ALLOW_TO_FAILOVER</th>
-    <td>フェイルオーバやデタッチが可能になります。これがデフォルトの動作です。
-        DISALLOW_TO_FAILOVERと同時には指定できません。
-    </td></tr>
-    <tr><th class="nodec">DISALLOW_TO_FAILOVER</th>
-    <td>フェイルオーバやデタッチが行われません。
-        HeartbeatやPacemakerなどのHA(High Availability)ソフトでバックエンドを二重化しているなどの事情で、
-        pgpool-II側でフェイルオーバの制御をして欲しくないときなどに指定します。
-        ALLOW_TO_FAILOVERと同時には指定できません。
-    </td></tr>
-    </table>
-
-    <p>
-    このパラメータを変更した時には設定ファイルを再読み込みしてください。
-    </p>
-    </dd>
-</dl>
-
-<h3>SSL</h3>
-
-<dl>
-<dt><a name="SSL">ssl</a> <span class="version">V2.3 〜</span></dt>
-    <dd>
-    <p>
-    trueならばpgpool-IIとフロントエンド、pgpool-IIとバックエンドの間のSSL接続が可能になります。
-    なお、pgpool-IIとフロントエンドの接続にSSLが利用できるためには、
-    <code>ssl_key</code>と<code>ssl_cert</code>が設定されてなければなりません。
-    </p>
-    <p>
-    デフォルトではSSLサポートはオフになっています。
-    SSLサポートを有効にするためには、configure時にOpenSSLサポートを有効にする必要があります。
-    詳細は<a href="#install">インストール</a>の項目をご覧下さい。
-    </p>
-    <p>
-    sslを有効に設定したら、pgpoolの再起動をしてください。
-    </p>
-    </dd>
-
-<dt><a name="SSL_KEY"></a>ssl_key <span class="version">V2.3 〜</span></dt>
-    <dd>
-    <p>
-    フロントエンドとの接続に使用するプライベートキーファイルのフルパスを指定します。
-    </p>
-    <p>
-    ssl_keyのデフォルト値はありません。
-    ssl_keyの設定がない場合は、フロントエンドとの接続でSSLが使用されなくなります。
-    </p>
-    </dd>
-
-    <dt><a name="SSL_CERT"></a>ssl_cert <span class="version">V2.3 〜</span></dt>
-    <dd>
-    <p>
-    フロントエンドとの接続に使用する公開x509証明書のフルパスを指定します。
-    </p>
-    <p>
-    ssl_certのデフォルト値はありません。
-    ssl_certの設定がない場合は、フロントエンドとの接続でSSLが使用されなくなります。
-    </p>
-    </dd>
-
-<dt><a name="SSL_CA_CERT"></a>ssl_ca_cert</dt>
-    <dd>
-    <p>
-    1 つ以上の CA ルート証明書を格納している PEM 形式ファイルのパスを指定します。
-    このファイルはバックエンドサーバ証明書の検証に用いられます。
-    このオプションは OpenSSL の <code>verify(1)</code> コマンドにおける <code>-CAfile</code> オプションと同様の機能を提供します。
-    </p>
-
-    <p>
-    デフォルトでは値が設定されておらず検証は行われません。
-    このオプションが設定されていない場合においても、<code>ssl_ca_cert_dir</code> オプション
-    が設定されている場合には検証が行われます。
-    </p>
-    </dd>
-
-<dt><a name="SSL_CA_CERT_DIR"></a>ssl_ca_cert_dir</dt>
-    <dd>
-    <p>
-    PEM 形式の CA 証明書ファイルを格納しているディレクトリのパスを指定します。
-    これらのファイルはバックエンドサーバ認証の検証に用いられます。
-    このオプションは OpenSSL の <code>verify(1)</code> コマンドにおける <code>-CApath</code> オプションと同様の機能を提供します。
-    </p>
-
-    <p>
-    デフォルトでは値が設定されておらず検証は行われません。
-    このオプションが設定されていない場合においても、<code>ssl_ca_cert</code> オプション
-    が設定されている場合には検証が行われます。
-    </p>
-    </dd>
-
-</dl>
-
-<h3>Other</h3>
-
-<dl>
-<dt><a name="RELCACHE_EXPIRE"></a>relcache_expire <span class="version">V3.1 〜</span></dt>
-    <dd>
-    <p>
-    リレーションキャッシュの寿命を秒単位で指定します。
-    0を指定すると、キャッシュの寿命の管理は行わず、プロセスが生きているか、
-    キャッシュが溢れるまでは有効になります(デフォルトの動作)。
-    </p>
-    <p>
-    リレーションキャッシュは、PostgreSQLのシステムカタログに対する問い合わせを保存しておくものです。
-    問い合わせる内容は、テーブルの構造、テーブルが一時テーブルかどうかなどがあります。
-    キャッシュはpgpoolの子プロセスのローカルメモりに保管されています。
-    <p>
-    もしALTER TABLEが発行されると、テーブルの構造が変わる場合があり、
-    リレーションキャッシュの内容と一致しなくなる恐れがあります。
-    relcache_expireにより、その危険性をコントロールできるようになります。
-    </p>
-    </dd>
-
-<dt><a name="RELCACHE_SIZE"></a>relcache_size <span class="version">V3.2 〜</span></dt>
-    <dd>
-    <p>
-    リレーションキャッシュのサイズを指定します。
-    デフォルトは256です。
-    </p>
-<pre>
-"pool_search_relcache: cache replacement happend"
-</pre>
-    <p>
-    のようなメッセージがログに頻繁に出る場合は、この数字を大きくしてください。
-    </p>
-    </dd>
-
-<dt><a name="CHECK_TEMP_TABLE"></a>check_temp_table <span class="version">V3.2 〜</span></dt>
-    <dd>
-    <p>
-    もしonなら、SELECTに含まれるテーブルが一時テーブルかどうかのチェックを行います。
-    このチェックは、primary/masterのシステムカタログへのアクセスを発生させ、それなりに負荷を上げます。
-    もし一時テーブルを使っていないということが確かで、primary/masterの負荷を少しでも下げたいのであれば、
-    offにすることができます。デフォルトはonです。
-    </p>
-    </dd>
-
-<dt><a name="CHECK_UNLOGGED_TABLE"></a>check_unlogged_table <span class="version">V3.4 〜</span></dt>
-    <dd>
-    <p>
-    もしonなら、SELECTに含まれるテーブルがunloggedテーブルかどうかのチェックを行います。
-    このチェックは、primary/masterのシステムカタログへのアクセスを発生させ、それなりに負荷を上げます。
-    もしunloggedテーブルを使っていないということが確かで(たとえばPostgreSQLのバージョンが9.0かそれより前)、
-    primary/masterの負荷を少しでも下げたいのであれば、
-    offにすることができます。デフォルトはonです。
-    </p>
-    </dd>
-
-</dl>
-
-<h2>SSL証明書の生成</h2>
-<p>
-証明書の扱いについてはこのマニュアルの範囲外です。
-PostgreSQLドキュメント<a href="http://www.postgresql.jp/document/pg842doc/html/ssl-tcp.html">
-SSLによる安全なTCP/IP接続</a>の章に自分で認証する証明書を作成するコマンドの例があります。
-</p>
-
-<h2 id="failover_in_raw_mode">rawモードにおけるフェイルオーバ動作について</h2>
-<p>
-rawモードにおいて、2台以上のPostgreSQLサーバを指定すると、フェイルオーバが可能です。
-フェイルオーバでは、正常時にはbackend_hostname0で指定したPostgreSQLのみを使用し、
-ほかのサーバにはアクセスしません。
-backend_hostname0のサーバがダウンすると、次にbackend_hostname1で指定したサーバにアクセスをこころみ、
-成功すればそれを使用します。以下、backend_hostname2...でも同様になります。
-</p>
-
-<p class="top_link"><a href="#Top">△ back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1><a name="connection_pool_mode"></a>コネクションプールモード</h1>
-<p>
-rawモードに加え、コネクションプーリングが利用できるようになります。
-コネクションプールモードを有効にするには、 <a href="#CONNECTION_CACHE">connection_cache</a> をonにします。
-以下の設定項目がコネクションプールの動作に影響を与えます。
-</p>
-
-<dl>
-<dt><a name="MOtherAX_POOL"></a>max_pool</dt>
-<dd>
-    <p>
-    pgpool-IIの各サーバプロセスがキープするPostgreSQLへの最大コネクション数です。
-    pgpool-IIは、ユーザ名、データベースが同じならばコネクションを再利用しますが、
-    そうでなければ新たにPostgreSQLへのコネクションを確立しようとします。
-    したがって、ここでは想定される[ユーザ名:データベース名]のペアの種類の数だけを
-    max_poolに指定しておく必要があります。
-    もしmax_poolを使いきってしまった場合は一番古いコネクションを切断し、
-    そのスロットが再利用されます。
-    </p>
-    <p>
-    max_poolのデフォルト値は4です。
-    </p>
-    <p>
-    なお、pgpool-II全体としては、<a href="#NUM_INIT_CHILDREN">num_init_children</a> *
-    <a href="#MAX_POOL">max_pool</a> 分だけ
-    PostgreSQLへのコネクションが張られる点に注意してください。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-
-<dt><a name="CONNECTION_LIFE_TIME"></a>connection_life_time</dt>
-    <dd>
-    <p>
-    コネクションプール中のコネクションの有効期間を秒単位で指定します。
-    0を指定すると有効期間は無限になります。
-    connection_life_timeのデフォルト値は0です。
-    </p>
-    <p>
-    このパラメータを変更した時には設定ファイルを再読み込みしてください。
-    </p>
-    </dd>
-
-<dt><a name="RESET_QUERY_LIST"></a>reset_query_list</dt>
-    <dd>
-    <p>
-    セッションが終了するときにコネクションを初期化するためのSQLコマンドを「;」で区切って列挙します。
-    デフォルトは以下のようになっていますが、任意のSQL文を追加しても構いません。
-<pre>
-reset_query_list = 'ABORT; DISCARD ALL'
-</pre>
-
-    <p>
-    PostgreSQLのバージョンによって使用できるSQLコマンドが違います。
-    各バージョンごとのお勧め設定は以下です(ただし、"ABORT"は必ずコマンドに含めてください)。
-    </p>
-
-    <table border>
-    <tr class="header"><th>PostgreSQLバージョン</th><th>reset_query_listの推奨設定値</th></tr>
-    <tr><th>7.1以前</th><td>ABORT</td></tr>
-    <tr><th>7.2から8.2</th><td>ABORT; RESET ALL; SET SESSION AUTHORIZATION DEFAULT</td></tr>
-    <tr><th>8.3以降</th><td>ABORT; DISCARD ALL</td></tr>
-    </table>
-
-    <ul>
-    <li>「ABORT」は、PostgreSQL 7.4以上ではトランザクションブロックの中にいない場合には発行されません。</li>
-    </ul>
-
-    <p>
-    このパラメータを変更した時には設定ファイルを再読み込みしてください。
-    </p>
-    </dd>
-
-</dl>
-
-<h2 id="failover_in_cp_mode">コネクションプールモードにおけるフェイルオーバ動作について</h2>
-<p>
-rawモードと同様の動作をします。
-</p>
-
-<p class="top_link"><a href="#Top">△ back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1><a name="replication_mode"></a>レプリケーションモード</h1>
-<p>
-レプリケーションを有効にするモードです(設定ファイルの雛形はpgpool.conf-replication)。
-rawモード、コネクションプールモードに加え、以下を設定します。
-</p>
-
-<dl>
-<dt><a name="REPLICATION_MODE"></a>replication_mode</dt>
-    <dd>
-    <p>
-    レプリケーションモードで動作させる場合はtrueを指定してください。デフォルト値はfalseです。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-
-<dt><a name="LOAD_BALANCE_MODE"></a>load_balance_mode</dt>
-    <dd>
-    <p>
-    trueを指定するとレプリケーションモードまたはマスタースレーブモードの際に、
-    SELECT文をロードバランスして検索性能を向上させることができます。デフォルト値はfalseです。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-
-<dt><a name="REPLICATION_STOP_ON_MISMATCH"></a>replication_stop_on_mismatch</dt>
-    <dd>
-    <p>
-    各DBノードから送られてくるパケットの種類が不一致になった場合に、DBノードを切り放して縮退運転に入ります。
-    </p>
-    <p>
-    良くあるケースとしては、<a href="#REPLICATE_SELECT">replicate_select</a> が指定されていて
-    SELECTが各DBノードで実行されているときに、
-    検索結果行数が一致しないなど、があります(これに限定されるものではありません。
-    たとえばあるDBノードでUPDATEが成功したのに、他のDBノードでは失敗した場合が一例です)。
-    ただし、pgpoolはパケットの中身まではチェックしていないので、SELECT結果のデータ内容が異なっていても、
-    縮退は起きないことに注意してください。
-    </p>
-    <p>
-    縮退対象のDBノードは「多数決」で少数派になったものが対象になります。
-    もし多数決で同票になった場合は、マスタDBノード(DBノード番号がもっともわかいもの)を含むグループが優先され、
-    それ以外のグループに所属するDBノードが切り放しの対象になります。
-    </p>
-    <p>
-    このオプションがfalseの場合は、該当のセッションを強制的に終了するだけに留めます。
-    デフォルト値はfalseです。
-    </p>
-
-<dt><a name="FAILOVER_IF_AFFECTED_TUPLES_MISMATCH"></a>failover_if_affected_tuples_mismatch <span class="version">V3.0 〜</span></dt>
-    <dd>
-    <p>
-    各DBノードで実行されたINSERT/UPDATE/DELETEの結果行数が不一致になった場合に、
-    DBノードを切り放して縮退運転に入ります。
-    </p>
-    <p>
-    縮退対象のDBノードは「多数決」で少数派になったものが対象になります。
-    もし多数決で同票になった場合は、マスタDBノード(DBノード番号がもっともわかいもの)を含むグループが優先され、
-    それ以外のグループに所属するDBノードが切り放しの対象になります。
-    </p>
-    <p>
-    このオプションがfalseの場合は、該当のセッションを強制的に終了するだけに留めます。
-    デフォルト値はfalseです。
-    </p>
-    </dd>
-
-<dt><a name="WHITE_FUNCTION_LIST"></a>white_function_list <span class="version">V3.0 〜</span></dt>
-    <dd>
-    <p>
-    データベースに対して<strong>更新を行なわない関数名</strong>をコンマ区切りで指定します。
-    このリストに含まれない関数呼び出しを含むSELECTは、負荷分散の対象とはならず、
-    レプリケーションモードにおいてはすべてのDBノードで実行されます。
-    (マスタースレーブモードにおいては、マスター(primary)DBノードにのみ送信されます)。
-    </p>
-    <p>
-    関数名には正規表現を使うことができます。指定した各表現に ^ と $ をつけた形で使われます。
-    たとえば、読み出しのみの関数が"get_"あるいは"select_"で始まるならば、以下のような指定が可能です。
-    </p>
-<pre>
-white_function_list = 'get_.*,select_.*'
-</pre>
-    </dd>
-
-<dt><a name="BLACK_FUNCTION_LIST"></a>black_function_list <span class="version">V3.0 〜</span></dt>
-    <dd>
-    <p>
-    データベースに対して<strong>更新を行なう関数名</strong>をコンマ区切りで指定します。
-    このリストに含まれる関数呼び出しを含むSELECTは、負荷分散の対象とはならず、
-    レプリケーションモードにおいてはすべてのDBノードで実行されます。
-    このリストに含まれない関数呼び出しを含むSELECTは、負荷分散の対象となります。
-    </p>
-    <p>
-    関数名には正規表現を使うことができます。指定した各表現に ^ と $ をつけた形で使われます。
-    たとえば、読み出しのみの関数が"set_"、"update_"、"delete_"あるいは"insert_"で始まるならば、
-    以下のような指定が可能です。
-    </p>
-<pre>
-black_function_list = 'nextval,setval,set_.*,update_.*,delete_.*,insert_.*'
-</pre>
-
-    <p>
-    white_function_listとblack_function_listの両方を空以外にすることはできません。
-    どちらか一方のみに関数名を指定します。
-    </p>
-    <p>
-    pgpool-II 3.0より前のバージョンでは、固定でnextvalとsetvalが書き込みを行なう関数として認識されていました。
-    それと同じ動作を行なわせるには、以下のようにwhite_function_listとblack_function_listを指定します。
-    </p>
-<pre>
-white_function_list = ''
-black_function_list = 'nextval,setval,lastval,currval'
-</pre>
-
-    <p>
-    上の例では、nextvalとsetvalに加え、lastvalとcurrvalが追加されていることに注意してください。
-    lastvalとcurrvalは書き込みを行う関数ではありませんが、これらの関数が負荷分散されることによって、
-    エラーが発生するのを未然に防ぐことができます。
-    black_function_listに含まれる関数は負荷分散されないからです。
-    </p>
-    </dd>
-
-<dt><a name="REPLICATE_SELECT"></a>replicate_select</dt>
-    <dd>
-    <p>
-    true を設定すると、レプリケーションモードでは SELECT 文をレプリケーションします。
-    これは pgpool-II 1.0 までの挙動と同じになります。
-    false を設定すると更新を伴わない SELECT 文をマスタのみに送信します。デフォルト値は false です。
-    </p>
-    <p>
-    replicate_select、<a href="#LOAD_BALANCE_MODE">load_balance_mode</a>、
-    SELECT問合わせが明示的なトランザクションブロックの内側にあるかどうかどうかで、
-    レプリケーションモードの動作が変化します。詳細を表に示します。
-    </p>
-
-    <table border>
-    <tr class="center">
-        <th class="nodec">replicate_selectがtrue</th>
-        <td>Y</td><td colspan="4">N</td>
-    </tr>
-    <tr class="center">
-        <th class="nodec">load_balance_modeがtrue</th>
-        <td>any</td><td colspan="3">Y</td><td>N</td>
-    <tr class="center">
-        <th class="nodec">SELECTが明示的なトランザクションブロックの内側にある</th>
-        <td>any</td><td colspan="2">Y</td><td>N</td><td>any</td>
-    </tr>
-    <tr class="center">
-        <th class="nodec">「トランザクション分離レベルがSERIALIZABLE」または<br>
-                          「トランザクション内で更新を伴うクエリが実行されている」</th>
-        <td>any</td><td>Y</td><td>N</td><td>any</td><td>any</td>
-    </tr>
-    <tr class="footer center">
-        <th class="nodec">結果(R:レプリケーション, M: マスタのみに送信, L: ロードバランスされる)</th>
-        <td>R</td><td>M</td><td>L</td><td>L</td><td>M</td>
-    </tr>
-    </table>
-    </dd>
-
-<dt><a name="INSERT_LOCK"></a>insert_lock</dt>
-    <dd>
-    <p>
-    SERIAL型を使っているテーブルをレプリケーションすると、SERIAL型の列の値がDBノードの間で
-    一致しなくなることがあります。
-    この問題は、該当テーブルを明示的にロックすることで回避できます
-    (もちろんトランザクションの並列実行性は犠牲になりますが)。
-    しかし、そのためには、
-    </p>
-<pre>
-INSERT INTO ...
-</pre>
-
-    <p>
-    を
-    </p>
-
-<pre>
-BEGIN;
-LOCK TABLE ...
-INSERT INTO ...
-COMMIT;
-</pre>
-
-    <p>
-    に書き換えなければなりません。
-    insert_lockをtrueにすると自動的にトランザクションの開始、テーブルロック、トランザクションの終了を
-    行ってくれるので、こうした手間を省くことができます
-    （すでにトランザクションが開始されている場合はLOCK TABLE...だけが実行されます）。
-    </p>
-
-    <dl>
-    <dt>pgpool-II 2.2以降</dt>
-        <dd><p>
-        テーブルがSERIAL列を持つかどうか自動判別するため、
-        SERIAL列がなければ決してテーブルをロックしません。
-        </p></dd>
-    <dt>pgpool-II 3.0.4までの3.0シリーズ</dt>
-        <dd><p>
-        対応するシーケンステーブルに対して行ロックをかけることで排他制御を行ないます。
-        それ以前のバージョンと比べると、VACUUM(autovacuumを含む)とのロック競合がなくなるメリットがあります。
-        </p>
-        <p>
-        しかし、これは他の問題を引き起こします。
-        トランザクション周回が起きた後、シーケンステーブルに対する行ロックはPostgreSQLの内部エラー
-        (詳細には、トランザクション状態を保持するpg_clogへのアクセスエラー)を起こします。
-        これを防ぐため、PostgreSQLのコア開発者はシーケンステーブルに対する行ロックを許可しないことを決定しました。
-        これはもちろんpgpool-IIを動作不能にします(修正されたPostgreSQLはバージョン
-        9.0.5, 8.4.9, 8.3.16そして8.2.22としてリリースされるでしょう)。
-        </p></dd>
-
-    <dt>pgpool-II 3.0.5以降</dt>
-        <dd><p>
-        新しいPostgreSQLがシーケンステーブルに対するロックを許可しなくなったため、
-        pgpool_catalog.insert_lockテーブルに対して行ロックをかけることで排他制御を行ないます。
-        したがって、pgpool-II経由でアクセスするすべてのデータベースにinsert_lockテーブルを
-        あらかじめ作成しておく必要があります。
-        詳細は<a href="#install">insert_lockテーブルの作成</a>の項目をご覧ください。
-        </p>
-        <p>
-        もし、insert_lockテーブルが存在しない場合は、挿入対象のテーブルに対してロックを行います。
-        これは、pgpool-II 2.2と2.3シリーズのinsert_lockと同じ動作です。
-        また、過去のバージョンと互換性のあるinsert_lockを使用したい場合は、configureスクリプトで設定できます。
-        詳細は<a href="#install">configureの実行</a>の項目をご覧下さい。
-        </dd></p>
-        </dl>
-
-    <p>
-    なお、あまり必要ないかも知れませんが、コメントを利用して、この挙動を細かく制御することもできます。
-    </p>
-
-    <ol>
-        <li>insert_lockをtrueにして、INSERT文の先頭に/*NO INSERT LOCK*/コメントを追加する。
-        このコメントがあると、テーブルロックは行われません(pgpool-II 3.0以降でも同様)。
-        </li>
-        <li>insert_lockをfalseにして、INSERT文の先頭に/*INSERT LOCK*/コメントを追加する。
-        このコメントがあると、このINSERT文に対してのみテーブルロックが行われます(pgpool-II 3.0以降でも同様)。
-        </li>
-    </ol>
-
-    <p>
-    insert_lockのデフォルト値はtrueです。
-    </p>
-    <p>
-    なお、insert_lockを有効にしてregression testを実行すると、少くともPostgreSQL 8.0では
-    transactions, privileges, rules, alter_tableがfailします。
-    ruleでは、viewに対してLOCKをしようとしてしまうこと、ほかのものは
-    </p>
-<pre>
-! ERROR:  current transaction is aborted, commands ignored until end of transaction block
-</pre>
-
-    <p>
-    というようなメッセージが出てしまうためです。たとえば、transactions では、
-    存在しないテーブルに対してINSERTを行うテストが含まれており、
-    pgpoolが最初に存在しないテーブルに対してLOCKを行う結果、エラーになってトランザクションがアボート状態になり、
-    続くINSERTで上記エラーが出てしまいます。
-    </p>
-    <p>
-    このパラメータを変更した時には設定ファイルを再読み込みしてください。
-    </p>
-    </dd>
-
-<dt><a name="RECOVERY_USER"></a>recovery_user</dt>
-    <dd>
-    <p>
-    オンラインリカバリを行うための PostgreSQL ユーザ名です。
-    このパラメータを変更した時には設定ファイルを再読み込みしてください。
-    </p>
-    </dd>
-
-<dt><a name="RECOVERY_PASSWORD"></a>recovery_password</dt>
-    <dd>
-    <p>
-    オンラインリカバリを行うための PostgreSQL ユーザパスワードです。
-    このパラメータを変更した時には設定ファイルを再読み込みしてください。
-    </p>
-    </dd>
-
-<dt><a name="RECOVERY_1ST_STAGE_COMMAND"></a>recovery_1st_stage_command</dt>
-    <dd>
-    <p>
-    オンラインリカバリ中に起動するコマンド名を指定します。
-    このスクリプトはPostgreSQLのマスタサーバ(プライマリサーバ)が起動します。
-    コマンドファイルはセキュリティ上の観点からデータベースクラスタ以下にある
-    コマンドやスクリプトのみを呼び出します。
-    例えば、recovery_1st_stage_command = 'sync-command' と設定してある場合、
-    $PGDATA/sync-command を起動しようとします。
-    </p>
-    <p>
-    recovery_1st_stage_command は次の4つの引数を受けとります。
-    </p>
-    <ol>
-        <li>マスタ(プライマリ)データベースクラスタへのパス</li>
-        <li>リカバリ対象のPostgreSQLのホスト名</li>
-        <li>リカバリ対象のデータベースクラスタへのパス</li>
-        <li>マスタデータベースクラスタのポート番号</li>
-    </ol>
-    <p>
-    recovery_1st_stage_command を実行している間は pgpool ではクライアン
-    トからの接続を<b>制限しません</b>。参照や更新を行うことができます。
-    </p>
-    <p>
-    <font color="red">
-    注意:
-    </font>
-    recovery_1st_stage_command は、PostgreSQLから見ると、一つのSQLとして実行されます。PostgreSQLの statement_timeout を無効にするか、statement_timeout が recovery_1st_stage_command の実行時間よりも十分長くないと、コマンドの実行がPostgreSQLにより途中でキャンセルされてしまいます。
-    この場合の典型的な症状は、recovery_1st_stage_command の中で呼び出されるコマンド(たとえば rsync)がシグナル2を受け取って中断する、というものです。
-    </p>
-    <p>
-    このパラメータを変更した時には設定ファイルを再読み込みしてください。
-    </p>
-    </dd>
-
-<dt><a name="RECOVERY_2ND_STAGE_COMMAND"></a>recovery_2nd_stage_command</dt>
-    <dd>
-    <p>
-    2 回目のオンラインリカバリ中に起動するコマンド名を指定します。
-    このスクリプトはPostgreSQLのマスタサーバ(プライマリサーバ)が起動します。
-    コマンドファイルはセキュリティ上の観点からデータベースクラスタ以下にある
-    コマンドやスクリプトのみを呼び出します。
-    例えば、recovery_2nd_stage_command = 'sync-command' と設定してある場合、
-    $PGDATA/sync-command を起動しようとします。
-    </p>
-    <p>
-    recovery_2nd_stage_command は次の3つの引数を受けとります。
-    </p>
-    <ol>
-        <li>マスタ(プライマリ)データベースクラスタへのパス</li>
-        <li>リカバリ対象のPostgreSQLのホスト名</li>
-        <li>リカバリ対象のデータベースクラスタへのパス</li>
-    </ol>
-    </p>
-    <p>
-    recovery_2nd_stage_command を実行している間は pgpool ではクライアントから
-    接続、参照、更新処理を一切<b>受け付けません</b>。
-    また、バッチ処理などによって接続しているクライアントが長時間存在している場合にはコマンドを起動しません。
-    新たな接続を制限し、現在の接続数が 0 になった時点
-    でコマンドを起動します。
-    </p>
-    <p>
-    <font color="red">
-    注意:
-    </font>
-    recovery_2nd_stage_command は、PostgreSQLから見ると、一つのSQLとして実行されます。
-    PostgreSQLの statement_timeout を無効にするか、statement_timeout が
-    recovery_2nd_stage_command の実行時間よりも十分長くないと、コマンドの実行が
-    PostgreSQLにより途中でキャンセルされてしまいます。
-    この場合の典型的な症状は、recovery_2nd_stage_command の中で呼び出されるコマンド(たとえば rsync)が
-    シグナル2を受け取って中断する、というものです。
-    </font>
-    </p>
-    <p>
-    このパラメータを変更した時には設定ファイルを再読み込みしてください。
-    </p>
-    </dd>
-
-<dt><a name="RECOVERY_TIMEOUT"></a>recovery_timeout</dt>
-    <dd>
-    <p>
-    pgpoolは、オンラインリカバリの際にすべてのクライアントが接続を終了するまで待ちます。
-    recovery_timeoutでその最大待ち時間を指定します。単位は秒です。
-    待ち時間がrecovery_timeoutを越えると、オンラインリカバリは中止され、通常の状態に戻ります。
-    </p>
-    <p>
-    アイドル状態のクライアントが自分から切断するのを待ちたくない場合は、
-    <a href="#CLIENT_IDLE_LIMIT_IN_RECOVERY">client_idle_limit_in_recovery</a>を利用することもできます。
-    </p>
-    </p>
-    <p>
-    recovery_timeoutは、この他、オンラインリカバリの最後にリカバリ対象のDBノードで
-    postmasterを起動する際の待ち時間にも利用されます。
-    </p>
-    <p>
-    recovery_timeoutのデフォルト値は90秒です。
-    recovery_timeoutを0としてもタイムアウトが無効になるわけではなく、
-    単に即座にタイムアウトするだけですので注意してください。
-    このパラメータを変更した時には設定ファイルを再読み込みしてください。
-    </p>
-    </dd>
-
-<dt><a name="CLIENT_IDLE_LIMIT_IN_RECOVERY"></a>client_idle_limit_in_recovery <span class="version">V2.2 〜</span></dt>
-    <dd>
-    <p>
-    client_idle_limitと似ていますが、このパラメータはリカバリのセカンドステージでのみ効力があります。
-    前回クライアントから来たクエリから、client_idle_limit_in_recovery 秒越えても次のクエリが届かない場合は、
-    クライアントへの接続を強制的に切断し、リカバリのセカンドステージの進行が妨害されるのを防ぎます。
-    -1を指定すると、直ちにクライアントへの接続を切断してセカンドステージに入ります。
-    デフォルト値は 0(無効)です。
-    </p>
-    <p>
-    クライアントが忙しく、アイドル状態にならない場合はclient_idle_limit_in_recoveryを設定しても
-    セカンドステージに移行できません。
-    この場合、client_idle_limit_in_recoveryに-1を設定すると、クライアントがビジーであっても
-    ただちにクライアントへの接続を切断し、セカンドステージに移行することができます。
-    </p>
-    <p>
-    このパラメータを変更した時には設定ファイルを再読み込みしてください。
-    </p>
-    </dd>
-
-<dt><a name="LOBJ_LOCK_TABLE"></a>lobj_lock_table <span class="version">V2.3 〜</span></dt>
-    <dd>
-    <p>
-    ラージオブジェクトのレプリケーションを行いたいときにロック管理に使うためのテーブル名を指定します。
-    </p>
-    <p>
-    このテーブルが指定されていて、ラージオブジェクトの作成要求がクライアントから送信され、
-    かつその要求の中にラージオブジェクトのIDの明示的な指定が含まれていない場合
-    (つまり、lo_creatでラージオブジェクトを作成する場合)、
-    pgpool-IIは、排他制御のためにこのテーブルをロックした後、
-    ラージオブジェクトを格納するシステムカタログpg_largeobjectのラージオブジェクトに格納されている
-    IDの最大値を取りだし、その値+1のIDを使ってlo_create()を呼び出してラージオブジェクトの作成を行います
-    (lo_create()を持たないバージョン8.1より前のPostgreSQLではこの処理は行われません)。
-    この方法により、すべてのDBノードで同じIDを持つラージオブジェクトが作成されることが保証されます。
-    </p>
-    <p>
-    このような処理の対象となるラージオブジェクトの操作は、PostgreSQLのC言語用のAPI(libpq)で言うと、lo_creat()です。
-    2010年2月時点の我々の調査では、以下の言語のラージオブジェクト作成APIは、すべてlo_creat()を呼び出すか、
-    またはlo_creat()と同じ通信プロトコルを使っているので、pgpool-IIの上記の操作の対象になり、
-    ラージオブジェクトのレプリケーションが安全に行われるようになります。
-    </p>
-
-    <ul>
-        <li>Java(JDBCドライバ)</li>
-        <li>PHP(pg_lo_create関数、またはPDOなどの該当API)</li>
-        <li>psqlから\lo_importを呼び出す場合</li>
-    </ul>
-
-    <p>
-    上記以外であっても、ラージオブジェクトの作成APIで
-    ラージオブジェクトのIDを引数として渡すようになっていないものは
-    間違いなくlo_creat()を使っており、pgpool-IIの上記の操作の対象になると考えて良いでしょう。
-    </p>
-
-    <p>
-    pgpool-IIの上記処理の対象とならないようなラージオブジェクトの作成処理は以下のものです。
-    </p>
-    <ul>
-        <li>libpqのlo_create()を使用している</li>
-        <li>C言語以外のAPIで、lo_create()を使用しているもの</li>
-        <li>バックエンド関数のlo_importをSELECTで呼び出す場合</li>
-        <li>バックエンド関数のlo_creatをSELECTで呼び出す場合</li>
-    </ul>
-    <p>
-    lobj_lock_tableで指定するテーブルはどのような定義のものでも構いませんが、
-    あらかじめ作成済でかつすべてのユーザが書き込み可能でなければなりません。
-    そのようなテーブルを作る例を示します。
-    </p>
-
-<pre>
-CREATE TABLE public.my_lock_table ();
-GRANT ALL ON public.my_lock_table TO PUBLIC;
-</pre>
-
-    <p>
-    この操作はpgpool-II経由で接続するすべてのデータベースに対して、あらかじめ実施しておかなければなりません。
-    しかし、この操作をtemplate1データベースに対して一度行っておけば、
-    以後作成されるデータベースにはこのテーブルが含まれるようになるので、管理の手間が省けます。
-    </p>
-    <p>
-    lobj_lock_tableに指定するテーブル名が空文字の場合は、ラージオブジェクトに関する上記の処理は行いません
-    (したがって、ラージオブジェクトのレプリケーションは保証されません)。
-    lobj_lock_tableのデフォルト値は空文字です。
-    </p>
-    </dd>
-
-</dl>
-
-<h2 id="condition_for_load_balance">ロードバランスの条件について</h2>
-<p>
-load_balance_mode = true を設定した場合、以下の条件のすべてを満たした時に
-SELECTなどの問い合わせがロードバランスされます。
-</p>
-<ul>
-    <li>PostgreSQLのバージョンが7.4以降である</li>
-    <li>レプリケーションモードまたはマスタースレーブモードである
-    <li>問い合わせが明示的なトランクザションブロックの内側にない(つまり、BEGINを発行していない)
-          <ul>
-          <li>ただし、以下の条件が満たされればトランザクションブロックの内側であってもロードバランスの対象となります。
-            <ul>
-              <li>トランザクション分離レベルがSERIALIZABLEでない</li>
-              <li>トランザクション内で更新を伴うクエリが実行されていない
-                  (更新を伴うクエリが実行されるまではロードバランスされます。
-                  ここで「更新を伴うクエリ」とは、SELECT以外のDDLやDMLを指します。
-                  black/white function listで指定される更新関数を含むSELECTは更新を伴うクエリとは見なされません。
-                  この仕様は将来変更される可能性があります)
-              </li>
-              <li>もしblack/white function listが空の場合は、関数を持つSELECTは、更新を伴うクエリとは見なされません。</li>
-            </ul>
-          </li>
-          </ul>
-    </li>
-    <li>SELECT文(WITH付も含む。<a href="#BLACK_FUNCTION_LIST">black_list</a> または
-        <a href="#WHITE_FUNCTION_LIST">white_list</a> で指定された書き込みを含むSELECTを除く)
-        またはCOPY TO STDOUT, EXPLAIN, EXPLAIN ANALYZE SELECT... のいずれかである</li>
-    <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>
-        </ul>
-  </ul>
-<p>
-(<a href="#replicate_select">replicate_selectの項目</a>も参考にしてください)
-また、<a href="where_to_send_queries.pdf">詳細な判定条件をフローチャートにしたもの</a>もご覧下さい。
-</p>
-
-<p>
-なお、
-</p>
-
-<pre>
-/*REPLICATION*/ SELECT ...
-</pre>
-
-<p>
-とすることによって、本来負荷分散されたり、マスタのみに送信されるべき問合わせが
-すべてのバックエンドに送信される（レプリケーションされる）ようになります。
-副作用がある関数を含む問合わせに対してはこのテクニックが利用できます。
-</p>
-<p>
-SQLコメントの記述が負荷分散に影響を与えないようにするには、
-<a href="#ALLOW_SQL_COMMENTS">allow_sql_comments</a>をonにします。
-</p>
-<p>
-<font color="red">
-注意: JDBC ドライバなどのように、ドライバ内で autocommit の有効・無効のオプションがある場合、
-autocommit を無効にすると、ドライバが内部で BEGIN コマンドを実行し、明示的なトランザクションが開始されます。
-この場合、トランザクション内における<a href="#condition_for_load_balance">上記のロードバランスの制限事項</a>が適用されます。
-</font>
-</p>
-
-<h2 id="detach_in_replication_mode">レプリケーションモードにおける縮退運転について</h2>
-<p>
-PostgreSQLサーバのうち、1台がダウンすると、そのサーバを切り離して縮退運転に入ります。
-1台でもサーバが生き残っていれば、システムとしての運用を継続できます。
-</p>
-
-<h2 id="errors_in_replication_mode">レプリケーションモード固有のエラーについて</h2>
-<p>
-レプリケーションモードにおいて、pgpoolはレプリケーション時に INSERT、UPDATE、DELETE の更新件数が
-すべてのノードが同じでない場合、
-<a href="#FAILOVER_IF_AFFECTED_TUPLES_MISMATCH">failover_if_affected_tuples_mismatch</a> が falseならば、
-意図的に構文エラーを起すSQLを送信することによって、トランザクションをアボートさせます。
-trueならば、フェイルオーバが起きます。その際、以下のようなエラーメッセージが表示されます。
-</p>
-
-<pre>
-=# UPDATE t SET a = a + 1;
-ERROR: pgpool detected difference of the number of update tuples Possible last query was: "update t1 set i = 1;"
-HINT: check data consistency between master and other db node
-</pre>
-
-<p>
-ログには更に以下のように、更新行数が記録されます(この場合はDBノード0が0行、DBノード1が1行)。
-</p>
-<pre>
-2010-07-22 13:23:25 LOG:   pid 5490: SimpleForwardToFrontend: Number of affected tuples are: 0 1
-2010-07-22 13:23:25 LOG:   pid 5490: ReadyForQuery: Degenerate backends: 1
-2010-07-22 13:23:25 LOG:   pid 5490: ReadyForQuery: Number of affected tuples are: 0 1
-</pre>
-
-<p class="top_link"><a href="#Top">△ back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1><a name="master_slave_mode"></a>マスタースレーブモード</h1>
-<p>
-master/slaveモードは、Slony-IやStreaming Replicationのような、
-master/slave式のレプリケーションソフトにレプリケーションをまかせるモードです。
-</p>
-<p>
-なお、スレーブの数は1である必要はありません。
-実際には127個までのスレーブを持つことができます(スレーブの数は0でも構いません)。
-</p>
-<p>
-このモードで使うためには、レプリケーションモードと同じように、
-DBノードのホスト情報(<a href="#BACKEND_HOSTNAME">backend_hostname</a>,
-<a href="#BACKEND_PORT">backend_port</a>, <a href="#BACKEND_WEIGHT">backend_weight</a>,
-<a href="#BACKEND_FLAG">backend_flag</a> それにオンラインリカバリが必要ならば
-<a href="#BACKEND_DATA_DIRECTORY">backend_data_directory</a>)をセットし、
-<a href="#MASTER_SLAVE_MODE">master_slave_mode</a>と<a href="LOAD_BALANCE_MODE">load_balance_mode</a>をtrueにします。
-</p>
-<p>
-pgpool-IIは、レプリケーションされる必要のある問い合わせはマスターに送り、
-その他の問い合わせを可能ならば負荷分散します。問い合わせによってマスターDBだけに問い合わせが送られる場合と、
-DBノードの間でロードバランスされて問い合わせが送られる場合があります。
-</p>
-
-<p>
-マスタスレーブモードでは、一時テーブルの作成、更新、検索はマスタノードでのみ実行されます。
-SELECTをマスタだけで実行するように強制することができます。
-このためには、/*NO LOAD BALANCE*/ コメントをSELECTに前に挿入しなければなりません。
-</p>
-<p>
-マスタースレーブモードでは、pgpool.confのreplication_modeをfalseに、
-<a href="#MASTER_SLAVE_MODE">master_slave_mode</a> をtrueにします(同時にtrueにはできません)。
-また、'<a href="#MASTER_SLAVE_SUB_MODE">master_slave_sub_mode</a>'を指定します。
-これは、'slony'(デフォルト)か、'stream'です。
-</p>
-<p>
-'slony'はSlony-Iを利用する時に指定します。
-'stream'は、PostgreSQL組み込みのStreaming Replicationを利用するときに指定します。
-</p>
-<p>
-Slony-Iを使う場合の設定ファイルの雛形はpgpool.conf.sample-master-slaveです。
-Streaming Replicationを使う場合の雛形はpgpool.conf.sample-streamです。
-</p>
-<p>
-このパラメータを変更した時には pgpool-II を再起動してください。
-</p>
-<p>
-マスタースレーブモードでも、DB書き込みを行なう関数の呼び出しを含むSELECTを負荷分散の対象から外す指定を
-<a href="#white_function_list">white_function_list</a>と
-<a href="#black_function_list">black_function_list</a>で行なうことができます。
-詳細は<a href="#white_function_list">white_function_list</a>の項をご覧下さい。
-</p>
-
-<p class="top_link"><a href="#Top">△ back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1><a name="stream"></a>Streaming Replicationへの対応 <span class="version">V3.1 〜</span></h1>
-<p>
-前述のように、マスタスレーブモードで、'<a href="#MASTER_SLAVE_SUB_MODE">master_slave_sub mode</a>'に
-'stream'を指定すると、PostgreSQL 9.0から利用可能になったStreaming Replicationに対応します
-(pgpool-IIでは、今のところ、Streaming ReplicationとHot Standbyを併用することを前提にしています)。
-このモードでは、以下の設定項目も利用できます。
-
-<dl id="params_for_stream_mode">
-<dt id="DELAY_THRESHOLD">delay_threshold <span class="version">V3.0 〜</span></dt>
-    <dd>
-    <p>
-    スタンバイサーバへのレプリケーションの遅延許容度をバイト単位で指定します。
-    pgpool-IIは、スタンバイサーバの遅延がこの値を超えた場合には、
-    負荷分散が有効であってもそのDBノードにSELECTを送信せず、プライマリサーバに送るようにします。
-    delay_thresholdが0の場合は、遅延のチェックを行ないません。
-    また、delay_thresholdが指定されていても、<a href="#SR_CHECK_PERIOD">sr_check_period</a>が無効(=0)ならば、
-    やはりこの機能は働きません。
-    デフォルト値は0です。
-    </p>
-    <p>
-    このパラメータは設定ファイルの再読込によって変更できます。
-    </p>
-</li>
-
-<dt id="SR_CHECK_PERIOD">sr_check_period <span class="version">V3.1 〜</span></dt>
-    <dd>
-    <p>
-    ストリーミングレプリケーションの遅延チェックの間隔を秒単位で指定します。
-    デフォルト値は0で、これはチェックを行わないことを意味します。
-    </p>
-    <p>
-    このパラメータは設定ファイルの再読込によって変更できます。
-    </p>
-    </dd>
-
-<dt id="SR_CHECK_USER">sr_check_user <span class="version">V3.1 〜</span></dt>
-    <dd>
-    <p>
-    ストリーミングレプリケーションの遅延チェックを行うユーザ名を指定します。
-    このユーザは、すべてのバックエンドに存在しなければなりません。
-    さもなければエラーになります。
-    sr_check_userとsr_check_passwordは、sr_check_periodが0であっても
-    指定が必要です。pgpool-IIは、どのサーバがprimaryサーバであるのかを調べるために、
-    PostgreSQLバックエンドに関数呼び出しのリクエストを送ります。
-    そのセッションでsr_check_userとsr_check_passwordが使われるからです。
-    </p>
-    <p>
-    このパラメータは設定ファイルの再読込によって変更できます。
-    </p>
-    </dd>
-
-<dt id="SR_CHECK_PASSWORD">sr_check_password <span class="version">V3.1 〜</span></dt>
-    <dd>
-    <p>
-    ストリーミングレプリケーションの遅延チェックを行うユーザに対するパスワードをを指定します。
-    パスワードが必要なければ空文字('')を指定します。
-    </p>
-    <p>
-    このパラメータは設定ファイルの再読込によって変更できます。
-    </p>
-    </dd>
-
-<dt id="SR_CHECK_DATABASE">sr_check_database <span class="version">V3.5 -</span></dt>
-    <dd>
-    <p>
-   ストリーミングレプリケーションの遅延チェックを行う対象のデータベース名を指定します。
-   デフォルトは「postgres」です（これは3.4以前のpgpool-IIが固定の値として使っていたデータベース名です）。
-    </p>
-    <p>
-    このパラメータは設定ファイルの再読込によって変更できます。
-    </p>
-    </dd>
-
-<dt id="LOG_STANDBY_DELAY">log_standby_delay <span class="version">V3.0 〜</span></dt>
-    <dd>
-    <p>
-    レプリケーションの遅延状況をログする条件を指定します。
-    'none'を指定すると、ログを出力しません。
-    'always'ならレプリケーションの遅延チェックを実行するたびに必ず出力します。
-    'if_over_threshold'を指定すると、<a href="#DELAY_THRESHOLD">delay_threshold</a>を超えたときだけ
-    ログが出力されます。
-    デフォルト値は'none'です。
-    </p>
-    <p>
-    このパラメータは設定ファイルの再読込によって変更できます。
-    </p>
-    <p>
-    なお、レプリケーションの遅延状況は <a href="#pool_status">show pool_status</a> コマンドでも確認できます。
-    項目名は"standby_delay#"です(#はDBノードIDです)。
-    </p>
-    </dd>
-</dl>
-
-<h2 id="failover_in_stream_mode">Streaming Replicationでのフェイルオーバ</h2>
-<p>
-Streaming replicationを利用したマスタスレーブモードでは、PrimaryやStandbyノードが停止した場合に、
-レプリケーションモードと同じように自動フェイルオーバを行なわせることができます。
-特に何も設定しなくても、停止したノードを自動的に切り放すことができますが、Streaming replicationでは、
-「トリガファイル」を作成することにより、Standbyノードを、リカバリモードから更新問い合わせを受け付ける
-通常のPostgreSQLの動作モードに自動変更することができます。
-これを利用して、フェイルオーバコマンドを併用して、Primaryノードがダウンしたときに、
-Standbyノードが自動的にとって代るような設定を行なうことができます。
-</p>
-<p>
-<strong>注意: 複数のStandbyノードを利用している場合、この設定を行なうときは、
-<a href="#DELAY_THRESHOLD">delay_threshold</a>を設定して、
-他のStandbyに振り分けられたSELECTが古いデータを取得しないようにしておくことをお勧めします。
-また、1台目のStandbyノードがPrimaryにとって代ったのちにダウンしてしまったケースで、
-2台目のStandbyが更に取って代わるとデータに不整合がおきるので、そのような設定は行なわないようにしてください。</strong>
-</p>
-<p>
-フェイルオーバの設定手順を示します。
-</p>
-<p>
-<ol>
-    <li>フェイルオーバ用のスクリプトを適当な場所(ここでは/usr/local/pgsql/bin)に配置して、実行権限を与えておきます。
-<pre>
-$ cd /usr/loca/pgsql/bin
-$ cat failover_stream.sh
-#! /bin/sh
-# Failover command for streming replication.
-# This script assumes that DB node 0 is primary, and 1 is standby.
-#
-# If standby goes down, does nothing. If primary goes down, create a
-# trigger file so that standby take over primary node.
-#
-# Arguments: $1: failed node id. $2: new master hostname. $3: path to
-# trigger file.
-
-failed_node=$1
-new_master=$2
-trigger_file=$3
-
-# Do nothing if standby goes down.
-if [ $failed_node = 1 ]; then
-    exit 0;
-fi
-
-# Create trigger file.
-/usr/bin/ssh -T $new_master /bin/touch $trigger_file
-
-exit 0;
-
-chmod 755 failover_stream.sh
-</pre>
-    </li>
-
-    <li>pgpool.confの、<a href="#FAILOVER_COMMAND">failover_commmand</a>を設定します。
-<pre>
-failover_command = '/usr/local/src/pgsql/9.0-beta/bin/failover_stream.sh %d %H /tmp/trigger_file0'
-</pre>
-    </li>
-
-    <li>standbyノードのrecovery.confを設定します。
-    <a href="recovery.conf.sample">recovery.confのサンプル</a>は PostgreSQLのインストールディレクトリ下の
-    "share/recovery.conf.sample"にあります。
-    これをstanndbyノードのデータベースクラスタ下に"recovery.conf"としてコピーしておきます。
-    そして、以下の項目を設定します。
-<pre>
-standby_mode = 'on'
-primary_conninfo = 'host=primary_hostのホスト名 user=postgres'
-trigger_file = '/tmp/trigger_file0'
-</pre>
-    </li>
-
-    <li>primaryノードのpostgresql.confを設定します。
-    以下は例ですので、必ず実際に合わせて調整してください。
-<pre>
-wal_level = hot_standby
-max_wal_senders = 1
-</pre>
-    </li>
-
-<li>primaryノードのpg_hba.confを設定します。
-以下は例ですので、必ず実際に合わせて調整してください。
-
-<pre>
-host    replication    postgres        192.168.0.10/32        trust
-</pre>
-    </li>
-
-</ol>
-
-<p>
-primaryとstandbyのPostgreSQLを起動すれば、Streaming replicationが開始されます。
-そして、primaryノードがダウンしたときに、自動的にstandbyノードが通常のPostgreSQLとして立ち上がり、
-更新問い合わせを受け付けるようになります。
-</p>
-
-<h2 id="load_balance_in_stream_mode">Streaming Replicationでのクエリ振り分け</h2>
-<p>
-Streaming replicationとHot Standbyを利用している環境では、primaryノードに送ってよい問い合わせ、
-standbyに送ってもよい問い合わせ、両方に送らなければならない問い合わせを厳密に管理する必要があります。
-pgpool-IIのStreaming Replicationモードは、こうした振り分けを自動的に行ないます。
-ここでは、そのロジックについて説明します。
-</p>
-<p>
-まず、問い合わせの種類によって以下のように分けられます。
-</p>
-
-<ul>
-    <li>Primaryノードにしか送られない問い合わせ
-    <ul>
-        <li>INSERT, UPDATE, DELETE, COPY FROM, TRUNCATE, CREATE, DROP, ALTER, COMMENT</li>
-        <li>SELECT ... FOR SHARE | UPDATE</li>
-        <li>トランザクションの分離レベルがシリアライザブルの場合のSELECT</li>
-        <li>ROW EXCLUSIVE MODEよりも強いLOCK</li>
-        <li>DECLARE, FETCH, CLOSE</li>
-        <li>SHOW</li>
-        <li>トランザクションコマンドの一部
-            <ul>
-                <li>BEGIN READ WRITE, START TRANSACTION READ WRITE
-                <li>SET TRANSACTION READ WRITE, SET SESSION CHARACTERISTICS AS TRANSACTION READ WRITE
-                <li>SET transaction_read_only = off
-            </ul>
-        </li>
-        <li>二相コミット関連のコマンド。PREPARE TRANSACTION, COMMIT PREPARED, ROLLBACK PREPARED</li>
-        <li>LISTEN, UNLISTEN, NOTIFY</li>
-        <li>VACUUM</li>
-        <li>シーケンス関連の関数(nextvalやsetvalなど)の呼び出し。</li>
-        <li>ラージオブジェクトの生成</li>
-    </ul>
-    </li>
-
-    <li>Primary/Standbyどちらにも送ることのできる問い合わせ。
-    <p>
-    負荷分散設定が有効ならば、standbyノードにも送信されます。
-    ただし、レプリケーションの遅延上限(delay_threshold)が設定されていて、
-    レプリケーションの遅延が<a href="#DELAY_THRESHOLD">delay_threshold</a>を上回っている場合は
-    問い合わせはPrimaryに送られます。
-    </p>
-    <ul>
-        <li>上記以外のSELECT</li>
-        <li>COPY TO</li>
-    </ul>
-    </li>
-
-    <li>Primary/Standbyどちらにも送られる問い合わせ
-    <ul>
-        <li>SET</li>
-        <li>DISCARD</li>
-        <li>DEALLOCATE ALL</li>
-    </ul>
-    </li>
-</ul>
-
-<p>
-明示的なトランザクションでは、以下のようになります。
-</p>
-
-<ul>
-    <li>BEGINなどのトランザクション開始コマンドは、Primaryサーバに送られます。</li>
-    <li>続くSELECTなど、Primary/Standbyどちらにも送ることのできる問い合わせは、
-        Primaryのトランザクション内でそのまま実行されるか、Standbyサーバで実行されます。</li>
-    <li>
-    INSERTなど、Standbyに送ることのできない問い合わせが現われた場合は、Primaryサーバで実行されます。
-    以後、SELECTなど、本来Standbyに送信しても構わないコマンドもPrimaryサーバで実行されます。
-    これは、トランザクションの中で実行されたINSERTなどの問い合わせの結果を
-    SELECTが直ちに参照できるようにするためです。
-    この状態は、トランザクションが閉じるか、アボートするまで続きます。
-    </li>
-</ul>
-
-<p>
-問い合わせが、拡張問い合わせモードで実行される場合は、問い合わせのparse段階で、
-問い合わせが負荷分散可能かどうかで送信先が決まります。
-その際の判断ルールは、通常のSQLと同じです。
-たとえば問い合わせがINSERTならば、Primaryサーバで実行される、という具合です。
-parseに続くbind, describe, executeも同じDBノードで実行されます。
-</p>
-
-<p>
-[注: SELECTが負荷分散されて Standby ノードで parseが実行されてから更新クエリが来た場合は、
-そのSELECTはPrimaryノードで実行されなければなりません。
-そのため、同じSELECTが再度Primaryノードでパースされることになります。]
-</p>
-
-<p>
-最後に、pgpool-IIのパーサが構文エラーと判断した問い合わせはPrimaryノードだけに送られます。
-</p>
-
-<p>
-データベース名とアプリケーション名によって細かく検索問い合わせの負荷分散を指定することもできます。
-</p>
-
-<p>
-
-<dl>
-  <dt id="DATABASE_REDIRECT_PREFERENCE_LIST">database_redirect_preference_list <span class="version">V3.4 〜</span></dt>
-    <dd>
-    <p>
-    データベース名によって負荷分散をしたいノード番号を、"データベース名:ノード番号"で指定します。
-    たとえば、"test:1"と書くと、"test"という名称のデータベースに接続すると、
-    常にノード番号1に検索問い合わせを送信するようになります。"データベース名:ノード番号"のペアを
-    カンマ(,)で区切って複数指定することもできます。データベース名には、正規表現を指定することできます。
-    ノード番号に"primary"と書くと、常にプライマリノードを指定したことになります。
-    ノード番号に"standby"と書くと、スタンバイノードのうちどれかをバックエンドウェイトに応じてランダムに選択します。
-    </p>
-    <p>
-      例を示します。
-<pre>
-database_redirect_preference_list = 'postgres:primary,mydb[01]:1,mydb2:standby'
-</pre>
-    </p>
-    <p>
-    この例では、検索問い合わせが、postgresデータベースはプライマリノード、mydb0とmydb1はノード1、mydb2はスタンバイノードに負荷分散します。
-    </p>
-    <p>
-    このパラメータは設定ファイルの再読込によって変更できます。
-    </p>
-    </dd>
-
-  <dt id="APP_NAME_REDIRECT_PREFERENCE_LIST">app_name_redirect_preference_list <span class="version">V3.4 〜</span></dt>
-    <dd>
-    <p>
-    アプリケーション名によって負荷分散をしたいノード番号を、"アプリケーション名:ノード番号"で指定します。
-    アプリケーション名とは、クライアントが接続時に指定する名称で、PostgreSQL 9.0以降で使用できます。
-</p>
-    <p>
-      <blockquote>
-    <font color="red">注意: </font>
-    JDBCドライバのpostgresql-9.3以前のバージョンでは、JDBCドライバの"ApplicationName" と
-    "assumeMinServerVersion=9.0"オプションを指定してもスタートアップパケットの中にapplication_nameを含まないため、
-    この機能を利用できません。
-    postgresql-9.4 以降のJDBCドライバをお使いください。
-      </blockquote>
-    </p>
-    <p>
-    たとえばpsqlコマンドのアプリケーション名は"psql"です。
-    pgpool-IIは、クライアントが接続に送信するスタートアップパケットに含まれるアプリケーション名だけを認識します。
-    接続後に変更されたアプリケーション名は認識されません。
-    </p>
-    <p>
-    アプリケーション名の指定はdatabase_redirect_preference_listと同様です。
-    正規表現も使用できます。
-    </p>
-    <p>
-      例を示します。
-<pre>
-app_name_redirect_preference_list = 'psql:primary,myapp1:1,myapp2:standby'
-</pre>
-    </p>
-    <p>
-    この例では、検索問い合わせが、psqlではプライマリノード、myapp1はノード1、myapp2はスタンバイノードに負荷分散します。
-    </p>
-    <p>
-      app_name_redirect_preference_listは、database_redirect_preference_listよりも優先されます。
-      以下の例を見てください。
-<pre>
-database_redirect_preference_list = 'bigdb:primary'
-app_name_redirect_preference_list = 'myapp:2'
-</pre>
-    </p>
-    <p>
-      通常、bigdbというデータベースに接続するアプリケーションはプライマリノードに検索問い合わせを送信します。
-      しかし、myappというアプリケーションは、同じbigdbに接続しても常にノード2に検索問い合わせするようになります。
-      たとえば、myapp2が非常に重いSELECTを実行する分析アプリケーションで、ノード2を分析処理専用にしたい場合に有効です。
-    </p>
-    <p>
-    このパラメータは設定ファイルの再読込によって変更できます。
-    </p>
-    </dd>
-</dl>
-</p>
-
-<h2 id="online_recovery_in_stream_mode">Streaming Replicationでのオンラインリカバリ</h2>
-<p>
-Streaming replicationを利用したマスタスレーブモードでは、
-レプリケーションモードと同じようにオンラインリカバリが利用できます。
-primaryサーバをマスタとし、standbyサーバをリカバリします。
-primaryサーバが動作しているのがこの方法の前提条件ですので、
-primaryサーバが停止している状態ではオンラインリカバリはできません。
-primaryサーガ停止している状態からの復旧は、すべてのDBノードとpgpool-IIを停止させて手動で実施しなければなりません。
-</p>
-
-<ol>
-    <li>リカバリ処理を実行するユーザ <a href="#RECOVERY_USER">recovery_user</a> を設定します。
-        通常、postgresユーザとなります。
-<pre>
-recovery_user = 'postgres'
-</pre>
-    </li>
-
-    <li><a href="#RECOVERY_PASSWORD">recovery_password</a> を設定します。
-        これは、<a href="#RECOVERY_USER">recovery_user</a> がDBにログインするときに使うパスワードです。
-<pre>
-recovery_password = 't-ishii'
-</pre>
-    </li>
-
-    <li><a href="#RECOVERY_1ST_STAGE_COMMAND">recovery_1st_stage_command</a> を設定します。
-    <p>
-    ここで指定するファイルは、primaryサーバからベースバックアップを取得し、
-    standbyサーバにリストアするものでなければなりません。
-    recovery_1st_stage_command は、primaryのPostgreSQLから、recovery_userの権限で起動され、
-    その時に引数を受けとります。
-    詳細は、<a href="#RECOVERY_1ST_STAGE_COMMAND">recovery_1st_stage_command</a>の設定項目をご覧ください。
-    </p>
-    <p>
-    このスクリプトファイルは、primaryのデータベースクラスタ下に配置し、実行権限を与えておきます。
-    サンプルとして、primary/standbyそれぞれ一台構成の場合のスクリプト
-    <a href="basebackup.sh">(basebackup.sh)</a>を示します。
-    このスクリプトでは、recovery_user がパスワードなしでリカバリ対象の
-    standbyノードにログインできることを前提にしているので、
-    あらかじめsshの設定を行なっておく必要があります。
-    </p>
-<pre>
-recovery_1st_stage_command = 'basebackup.sh'
-</pre>
-    </li>
-
-    <li><a href="#RECOVERY_2ND_STAGE_COMMAND">recovery_2nd_stage_command</a> は、空のままで構いません。
-<pre>
-recovery_2nd_stage_command = ''
-</pre>
-    </li>
-
-    <li>オンラインリカバリを実施するための PostgreSQL の C 言語関数やSQL関数を各DBノードにインストールします。
-
-<pre>
-# cd pgpool-II-x.x.x/sql/pgpool-recovery
-# make
-# make install
-# psql -f pgpool-recovery.sql template1
-</pre>
-    </li>
-
-    <li>オンラインリカバリが終了したあと、pgpool-IIは、停止していたDBノードのPostgreSQLを起動します。
-    そのためのスクリプトを、各DBノードのDBクラスタにインストールします。
-    <p>
-    <a href="pgpool_remote_start">スクリプトのサンプル</a>がソースコードの"sample"ディレクトリに含まれているので、
-    それを利用してください。
-    このサンプルの中では、PostgreSQLの起動をpg_ctlコマンドで行っており、pg_ctlコマンドへのパスが記述されています。
-    デフォルトでは/usr/local/pgsql/bin/pg_ctlとなっているので、お使いの環境に合わせて修正してください。
-    </p>
-    <p>
-    なお、このスクリプトはsshを使用しますので、少くとも、primaryのDBノードから、standbyのDBノードに対して、
-    recovery_userでパスワードなしでsshが利用できることが必要です。
-    必要ならばあらかじめ設定しておいてください。
-    </p>
-    </li>
-</ol>
-
-<p>
-以上でオンラインリカバリの設定が終了しました。
-standbyノードを停止した状態で、<a href="#pcp_recovery_node">pcp_recovery_node</a> を利用するか、
-pgpoolAdminの「リカバリ」ボタンでオンラインリカバリが出来るようになったはずです。
-うまくいかない場合は、pgpool-IIのログ、primaryサーバ、standbyサーバのログを確認してください。
-</p>
-
-<p>
-参考までに、ストリーミングレプリケーションでのオンラインリカバリの内部処理の流れを説明します。
-</p>
-
-<ol id="setting_for_online_recovery_in_stream_mode">
-    <li>pgpool-IIは、primaryサーバにユーザ: <a href="#RECOVERY_USER">recovery_user</a>,
-        パスワード: <a href="#RECOVERY_PASSWORD">recovery_password</a> で
-        template1データベースに接続します。
-    </li>
-    <li>primaryサーバで、pgpool_recovery関数を実行します。
-    </li>
-    <li>pgpool_recovery関数は、<a href="#RECOVERY_1ST_STAGE_COMMAND">recovery_1st_stage_command</a> で
-        指定されたスクリプトを実行します。
-        <p>
-        なお、PostgreSQLは、データベースクラスタディレクトリ中で関数を実行します。
-        よって、pgpool_recovery関数もprimaryサーバのデータベースクラスタディレクトリ中で
-        関数を実行されることに注意してください。
-        </p>
-    </li>
-    <li>primaryサーバで、pgpool_remote_start関数を実行します。
-    <p>
-    この関数は、primaryサーバのデータベースクラスタディレクトリ中にある
-    pgpool_remote_startという名前のスクリプトを起動し、
-    ここからssh経由でリカバリ対象のstandbyサーバのPostgreSQLをpg_ctlコマンドを使って起動します。
-    起動はバックグラウンドで行われ、起動できたかどうかは次のステップで確認されます。
-    </p>
-    </li>
-    <li>pgpool-IIから、standbyサーバのPostgreSQLのpostgresデータベース
-        (postgresデータベースがない場合はtemplate1データベース)に、
-        ユーザ: <a href="#RECOVERY_USER">recovery_user</a>,
-        パスワード: <a href="#RECOVERY_PASSWORD">recovery_password</a> でtemplate1データベースに接続を試みます。
-        <p>
-        リトライは、<a href="#RECOVERY_TIMEOUT">recovery_timeout</a>秒間行われます。
-        PostgreSQLの起動に成功したら、次のステップに移ります。
-        </p>
-    </li>
-    <li><a href="#FAILBACK_COMMAND">failback_command</a>が空でない場合は、
-        pgpool-IIの親プロセスは指定されたスクリプトを起動します。
-    </li>
-    <li><a href="#FAILBACK_COMMAND">failback_command</a>が終了したら、pgpool-IIの子プロセスをすべて再起動します。
-    </li>
-</ol>
-
-<p class="top_link"><a href="#Top">△ back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1><a name="hba"></a>クライアント認証(HBA)のための pool_hba.conf 設定方法</h1>
-<p>
-PostgreSQLのpg_hba.confと同じようにpgpoolでもpool_hba.confファイルを使った
-クライアント認証がサポートされています。
-</p>
-<p>
-pgpoolをインストールするとデフォルトインストール先の設定ファイルディレクトリ
-"/usr/local/etc"にpool_hba.conf.sampleが一緒にインストールされます。
-このpool_hba.conf.sampleファイルをpool_hba.confとしてコピーし、
-必要であれば編集してください。
-デフォルトではpool_hbaによる認証は無効にになっています。
-pgpool.confの<a href="#ENABLE_POOL_HBA">enable_pool_hba</a>をonにしてください。
-</p>
-<p>
-pool_hba.confのフォーマットはpg_hba.confのものとほとんど同じです。
-</p>
-<pre>
-local      DATABASE  USER  METHOD  [OPTION]
-host       DATABASE  USER  CIDR-ADDRESS  METHOD  [OPTION]
-</pre>
-<p>
-各フィールドで設定できる値の詳細は"pool_hba.conf.sample"を参照してください。
-</p>
-<p>
-以下はpool_hbaの制限事項です。
-</p>
-
-<ul>
-    <li>DATABASEフィールド値として"samegroup"はサポートされません</li>
-    <p>
-    pgpoolはバックエンドサーバにあるユーザ情報を事前に知る事ができないため、
-    データベース名はpool_hba.confにある値のみと比較されます。
-    なのでグループに関する認証はpool_hbaで行うことができません。
-    </p>
-    </li>
-
-<li>USERフィールド値として"+"を使ったグループ指定はサポートされません</li>
-    <p>
-    上記の"samegroup"と同じ理由で、ユーザ名はpool_hba.confにある値のみと比較されます。
-    グループに関する認証はpool_hbaで行うことはできません。
-    </p>
-    </li>
-
-<li>IPv6アドレス/マスク表記法はサポートされません</li>
-    <p>
-    現在pgpoolはIPv6をサポートしていません。
-    </p>
-    </li>
-
-<li>"trust", "reject", "pam", "md5"以外のメソッドはサポートされません</li>
-    <p>
-    これも上記の"samegroup"と同じ理由によるものです。
-    pgpoolはバックエンドのユーザ/パスワード情報を持っていないので、
-    バックエンドに保存されているパスワードを使った認証を行うことができません。
-    </p>
-    <p>
-    md5に関しては、pool_passwdというパスワードファイルを併用することによって利用できます。
-    詳細は<a href="#md5">認証・アクセス制御方式</a>を参照してください。
-    </p>
-    </li>
-
-</ul>
-
-<p>
-ここで説明された機能、制限はクライアントとpgpool間で行われるクライアント認証についてだということに
-注意してください。
-クラインアントはpgpoolのクライアント認証に成功したとしても、
-PostgreSQLによるクライアント認証に成功しないと接続状態となりません。
-pool_hbaにとってはクライアントに指定されたユーザ名やデータベース名(例. psql -U testuser testdb)が
-実際にバックエンド上に存在するかどうかは問題ではありません。
-それがpool_hba.confの値とマッチするかどうかでチェックが行われます。
-</p>
-<p>
-pgpoolが稼働するホスト上のユーザ情報を使ったPAM認証を利用することができます。
-pgpoolをPAMサポート付きでビルドするにはconfigureオプションに"--with-pam"を指定してください。
-</p>
-<pre>
-./configure --with-pam
-</pre>
-<p>
-実際にPAM認証を有効にするには、pool_hba.confで"pam"メソッドを設定するのに加え、
-pgpoolのサービス設定ファイルをシステムのPAM設定ディレクトリ（通常は /etc/pam.d に作成する必要があります。
-サービス設定ファイルの例はインストールディレクトリの"share/pgpool.pam"を参考にしてく
-ださい。
-</p>
-
-<p class="top_link"><a href="#Top">△ back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1><a name="memqcache"></a>インメモリクエリキャッシュの設定方法 <span class="version">V3.2 〜</span></h1>
-
-<p>
-pgpool-IIでは、すべてのモードでインメモリクエリキャッシュを利用することができます。
-上記のクエリキャッシュと違い、メモリ上にキャッシュが置かれるので高速であるばかりでなく、
-データが更新されると自動的にキャッシュが無効になり、pgpool-IIの再起動の必要がありません。
-</p>
-<p>
-インメモリクエリキャッシュは、問い合わせのSELECT文(拡張問い合わせの場合は更にバインドパラメータ)と
-検索結果をペアで記録し、2回目以降に同じSELECT文が発行された場合に、キャッシュから結果を返します。
-通常のSELECT文処理と違って、PostgreSQLにアクセスしないだけでなく、
-pgpool内部のSQLパース処理などを経由しないため、非常に高速です。
-</p>
-<p>
-反面、キャッシュにヒットしない場合は通常のSELECT文の処理に加えてキャッシュ処理のオーバヘッドが生じるので、
-かえって遅くなります。
-また、あるテーブルが更新された場合、そのテーブルを参照している
-すべてのキャッシュが自動削除されるため(自動削除しない設定も可能)、
-更新処理が多いシステムではインメモリクエリキャッシュを有効にしていることでかえって遅くなります。
-キャッシュのヒット率が70%以下の場合は、インメモリクエリキャッシュの設定を有効にしないほうが良いでしょう。
-</p>
-
-<h2 id="MEMORY_CACHE_RESTRICTIONS">インメモリクエリキャッシュの制限事項</h2>
-<ul>
-  <li>インメモリクエリキャッシュでは、テーブルに変更があると、関連するキャッシュを自動的に削除して
-      古いデータが返却されないようにする機能があります。
-      このため、pgpoolは常にUPDATEやINSERTやALTER TABLEなどのコマンドが発行されたかどうかをモニタしています。
-      しかし、トリガ、外部キーやDROP TABLE CASCADEなどの働きによって暗黙的にテーブルが更新されたことは
-      pgpool-IIからはわからないため、この機能が働きません。
-      この問題を回避するためには、<a href="#MEMQCACHE_EXPIRE">memqcache_expire</a>を使って
-      一定時間経過したキャッシュを削除するようにするか、
-      <a href="#BLACK_MEMQCACHE_TABLE_LIST">black_memqcache_table_list</a>を使って、
-      該当テーブルがキャッシュされないようにしてください。</li>
-  <li>複数のpgpool-IIを動かす環境で共有メモリを使ったインメモリクエリキャッシュを使用すると、
-      あるpgpool-II経由でテーブルが更新された時に、他のpgpool-IIのキャッシュが削除されず、
-      古いデータを読みだしてしまうことがあります。
-      このような環境では、キャッシュストレージにmemcachedを使ってください。</li>
-</ul>
-
-<h2 id="MEMORY_CACHE_ENABLED">インメモリクエリキャッシュの有効化</h2>
-<p>
-インメモリクエリキャッシュを有効にするには、pgpool.confの"memory_cache_enabled"を有効にします。
-<pre>
-memory_cache_enabled = true
-</pre>
-</p>
-
-<h2 id="MEMQCACHE_METHOD">キャッシュストレージの選択</h2>
-<p>
-メモリキャッシュのストレージには、共有メモリと<a href="http://memcached.org">memcached</a>のどちらかを
-選択することができます(併用はできません)。
-<p>
-共有メモリを使用するクエリキャッシュは高速で、memcachedの立ち上げも必要なく、手軽に利用できます。
-ただし、共有メモリサイズの上限によって保存できるキャッシュの量に制限があります。
-memcachedをキャッシュストレージに使用する場合は、ネットワークアクセスのオーバヘッドがあるものの、
-比較的自由にキャッシュメモリの大きさを設定できます。
-</p>
-<p>
-共有メモリを利用する場合は"memqcache_method"に 'shmem'、Memcachedを利用する場合は'memcached'と設定します。
-デフォルトは、'shmem'です。
-</p>
-
-<h2 id="memqcache_cases">キャッシュが作成される場合と作成されない場合</h2>
-<p>
-すべてのSELECT(もしくはWITH)がインメモリクエリキャッシュの対象になるわけではありません。
-キャッシュとDBの一貫性を極力保つために、キャッシュされないケースがあります。以下それを列挙します。
-</p>
-<ul>
-  <li> <a href="#BLACK_MEMQCACHE_TABLE_LIST">black_memqcache_table_list</a>で指定されているテーブルを使っているSELECT</li>
-  <li>「/*NO QUERY CACHE*/」コメントで始まるSELECT</li>
-  <li>SELECT FOR SHAREまたはUPDATE</li>
-  <li>IMMUTABLEでない関数を使っているSELECT</li>
-  <li>一時テーブルを使っているSELECT</li>
-  <li>システムカタログを検索しているSELECT</li>
-  <li>VIEWをまたはunloggedテーブル使っているSELECT。
-      ただし、それらのテーブルが<a href="#WHITE_MEMQCACHE_TABLE_LIST">white_memqcache_table_list</a>で
-      指定されている場合はキャッシュの対象になります。
-  </li>
-  <li>明示的なトランザクション内でSELECTが発行され、そのトランザクションがアボートした時</li>
-  <li>SELECT結果が大きい場合(<a href="#MEMQCACHE_MAXCACHE">memqcache_maxcache</a>の項参照)</li>
-</ul>
-
-<h2 id="non_memqcache_case">キャッシュがあっても参照されない場合</h2>
-<p>
-インメモリクエリキャッシュが存在しても、そのキャッシュが利用されないケースがあります。
-以下それを列挙します。
-</p>
-<ul>
-  <li>明示的なトランザクション内で更新クエリが発行されている場合は、そのトランザクション内では
-      一切クエリキャッシュは参照されません。</li>
-  <li>そのキャッシュを違うユーザが作成していた場合(セキュリティ上の理由)</li>
-  <li>キャッシュの寿命を超えていた場合(<a href="#MEMQCACHE_EXPIRE">memqcache_expireの項</a>を参照)</li>
-</ul>
-
-<h2 id="memqcache_params">共通設定項目</h2>
-<p>
-キャッシュストレージを共有メモリにする場合でも、memcachedにする場合でも、共通で設定する項目を説明します。
-</p>
-
-<dl>
-<dt id="MEMQCACHE_EXPIRE">memqcache_expire <span class="version">V3.2 〜</span></dt>
-    <dd>
-    <p>
-    クエリキャッシュの寿命を秒単位で設定します。デフォルト0です。
-    0を指定すると寿命が無限大になり、関連テーブルが更新されるまではキャッシュが有効になります。
-    なお、この設定は、<a href="#MEMQCACHE_AUTO_CACHE_INVALIDATION">memqcache_auto_cache_invalidation</a>とは
-    独立です。
-    </p>
-    </dd>
-
-<dt id="MEMQCACHE_AUTO_CACHE_INVALIDATION">memqcache_auto_cache_invalidation <span class="version">V3.2 〜</span></dt>
-    <dd>
-    <p>
-    trueならば関連するテーブルが更新されるとキャッシュを無効化します。
-    falseならばテーブルが更新されてもキャッシュを無効化しません。
-    デフォルト値はonです。
-    なお、この設定は<a href="#MEMQCACHE_EXPIRE">memqcache_expire</a>の設定とは独立です。
-    </p>
-    </dd>
-
-<dt id="WHITE_MEMQCACHE_TABLE_LIST">white_memqcache_table_list <span class="version">V3.2 〜</span></dt>
-    <dd>
-    <p>
-    VIEW やunloggedテーブルを使っているSELECTは通常キャッシュの対象になりませんが、
-    white_memqcache_table_list に記述しておくことで、キャッシュされるようになります。
-    テーブル名はカンマ区切りで指定します。正規表現も利用できます
-    （指定した各表現に ^ と $ をつけた形で使われます）。
-    <p>
-    なお、同じテーブル・VIEW が <a href="#BLACK_MEMQCACHE_TABLE_LIST">black_memqcache_table_list</a> と両方に
-    指定されている場合は、white_memqcache_table_list が優先され、キャッシュを利用します。
-    </p>
-    <p>スキーマ名を付けないテーブル名とスキーマ名を付けた形の両方をクエリの中で使う場合は、
-    両方共リストに登録してください。たとえば、"table1"と"public.table1"の両方がクエリに現れる場合は、
-    単に"table1"ではなく、"table1,public.table1"を追加する必要があります。
-    </p>
-    </dd>
-
-<dt id="BLACK_MEMQCACHE_TABLE_LIST">black_memqcache_table_list <span class="version">V3.2 〜</span></dt>
-    <dd>
-    <p>
-    SELECT結果をキャッシュしたくないテーブル名をカンマ区切りで指定します。正規表現も利用できます
-    （指定した各表現に ^ と $ をつけた形で使われます）。
-    </p>
-    <p>スキーマ名を付けないテーブル名とスキーマ名を付けた形の両方をクエリの中で使う場合は、
-    両方共リストに登録してください。たとえば、"table1"と"public.table1"の両方がクエリに現れる場合は、
-    単に"table1"ではなく、"table1,public.table1"を追加する必要があります。
-    </p>
-    </dd>
-
-<dt id="MEMQCACHE_MAXCACHE">memqcache_maxcache <span class="version">V3.2 〜</span></dt>
-    <dd>
-        <p>
-        SELECT文の実行結果がmemqcache_maxcacheバイトを超えると、キャッシュされません。
-        この場合、以下のようなメッセージが表示されます。
-        </p>
-<pre>
-2012-05-02 15:08:17 LOG:   pid 13756: pool_add_temp_query_cache: data size exceeds memqcache_maxcache. current:4095 requested:111 memq_maxcache:4096
-</pre>
-        <p>
-        この問題を回避するためには、memqcache_maxcacheを大きくすれば良いのですが、
-        キャッシュストレージとして共有メモリを使用する場合は、
-        <a href="#MEMQCACHE_CACHE_BLOCK_SIZE">memqcache_cache_block_size</a>を超えないようにしてください。
-        キャッシュストレージとしてmemcachedを使用する場合は、
-        memcachedのスラブサイズ(デフォルトで1MB)を超えないようにしてください。
-        </p>
-    </dd>
-
-<dt id="MEMQCACHE_OIDDIR">memqcache_oiddir <span class="version">V3.2 〜</span></dt>
-    <dd>
-    <p>
-    SELECT文が使用するテーブルにOIDを格納する一時ファイル領域のトップディレクトリをフルパスで指定します。
-    memqcache_oiddir以下には、データベースOID名のディレクトリが作成され、
-    更にその下にはテーブルOID名のファイルが作成されます。
-    テーブルOID名ファイルの中には、クエリキャッシュへのポインタが格納されており、
-    テーブルの更新があった際にキャッシュを削除するキーとなります。
-    </p>
-    <p>
-    この領域はデフォルトでは、pgpool を再起動しても再利用されます。
-    再利用せずに削除して起動したい場合は、<a href="#start">pgpool コマンド</a> に -C オプションをつけて起動します。
-    </p>
-    </dd>
-</dl>
-
-<h2 id="monitoring_memqcache">キャッシュのモニタリング</h2>
-<p>
-インメモリクエリキャッシュをモニタする方法を説明します。
-キャッシュから検索結果が取得されたかどうかは、<a href="#LOG_PER_NODE_STATEMENT">log_per_node_statement</a> を
-有効にすることで確認できます。
-</p>
-<pre>
-2012-05-01 15:42:09 LOG:   pid 20181: query result fetched from cache. statement: select * from t1;
-</pre>
-
-<p>
-クエリキャッシュのヒット率は、<a href="#pool_status">show pool_status コマンド</a> で確認できます。
-</p>
-<pre>
-memqcache_stats_start_time           | Tue May  1 15:41:59 2012 | Start time of query cache stats
-memqcache_no_cache_hits              | 80471                    | Number of SELECTs not hitting query cache
-memqcache_cache_hits                 | 36717                    | Number of SELECTs hitting query cache
-</pre>
-
-
-<p>
-この例では、
-</p>
-<p>
-<pre>
-(memqcache_cache_hits) / (memqcache_no_cache_hits+memqcache_cache_hits) = 36717 / (36717 + 80471) = 31.3%
-</pre>
-<p>
-がキャッシュヒット率ということになります。
-</p>
-<p>
-<a href="#pool_cache">show pool_cache</a>コマンドでも同様の内容が確認できます。
-</p>
-
-<h2 id="shmem_params">共有メモリ設定項目</h2>
-<p>
-キャッシュストレージとして共有メモリを使用する場合の設定項目を説明します。
-</p>
-
-<dl>
-<dt id="MEMQCACHE_TOTAL_SIZE">memqcache_total_size <span class="version">V3.2 〜</span></dt>
-    <dd>
-    <p>
-    キャッシュストレージに使用する共有メモリ領域のサイズを指定します。単位はバイトです。
-    </p>
-    </dd>
-
-<dt id="MEMQCACHE_MAX_NUM_CACHE">memqcache_max_num_cache <span class="version">V3.2 〜</span></dt>
-    <dd>
-    <p>
-    キャッシュの数を指定します。
-    この設定項目は、キャッシュの管理領域の大きさを決めるために使用します
-    (<a href="MEMQCACHE_TOTAL_SIZE">memqcache_total_size</a>とは別に取られます)。
-    管理領域の大きさは、memqcache_max_num_cache * 48(バイト)になります。
-    この数は少なすぎるとキャッシュを登録することができずにエラーになります。
-    逆に多すぎると無駄になります。
-    </p>
-    </dd>
-
-<dt id="MEMQCACHE_CACHE_BLOCK_SIZE">memqcache_cache_block_size <span class="version">V3.2 〜</span></dt>
-    <dd>
-    <p>
-    キャッシュストレージとして共有メモリを使用する場合は、メモリを
-    memqcache_cache_block_size のブロックに分けて利用します。検索結果
-    のキャッシュはこのブロックに入るだけ詰め込まれます。
-    ただし、キャッシュは複数のブロックにまたがって格納されないので、
-    memqcache_cache_block_sizeを検索結果が超えると、キャッシュに格納できなくなります。
-    memqcache_cache_block_sizeは、512以上の値でなければなりません。
-    </p>
-    </dd>
-</dl>
-
-<h2 id="memcached_params">memcached設定項目</h2>
-<p>
-キャッシュストレージとしてmemcachedを使用する場合の設定項目を説明します。
-</p>
-
-<dl>
-<dt id="MEMQCACHE_MEMCACHED_HOST">memqcache_memcached_host <span class="version">V3.2 〜</span></dt>
-    <dd>
-    <p>
-    memcachedが動いているホスト名またはIPアドレスを指定します。
-    pgpool-IIと同じマシンでmemcachedを動かす場合は、'localhost'とします。
-    </p>
-    </dd>
-
-<dt id="MEMQCACHE_MEMCACHED_PORT">memqcache_memcached_port <span class="version">V3.2 〜</span></dt>
-    <dd>
-    <p>
-    memcachedのポート番号を指定します。デフォルト値は 11211 です。
-    </p>
-    </dd>
-</dl>
-
-<h3 id="install_memcached">memcachedのインストール</h3>
-<p>
-pgpool-IIのクエリキャッシュストレージとしてmemcachedを使用する場合は、動作しているmemcachedと、
-libmemcachedというクライアントライブラリのインストールが必要です。
-rpmなどからインストールするのがおすすめですが、ここではソースコードからインストールする方法を説明します。
-</p>
-<p>
-memcachedのソースコードは<a href="http://memcached.org/">memcached開発ページ</a>からダウンロードできます。
-</p>
-
-<dl>
-<dt>configureの実行
-    <dd>
-    <p>
-    ソースコードのtar ballを展開したら、configureを実行します。
-    </p>
-<pre>
-./configure
-</pre>
-    </dd>
-
-<dt>makeの実行
-    <dd>
-<pre>
-make
-make install
-</pre>
-    </dd>
-</dl>
-
-<h3 id="install_libmemcached">libmemcachedのインストール</h3>
-
-<p>
-memcachedのクライアントライブラリは、libmemcachedを使用しています。<br>
-memcachedのインストール後に、libmemcachedをインストールする必要があります。
-</p>
-
-<p>
-libmemcachedのソースコードは、<a href="http://libmemcached.org/libMemcached.html">libMemcached開発ページ</a>から
-ダウンロードできます。
-</p>
-
-<dl>
-<dt>configureの実行
-    <dd>
-    <p>
-    ソースコードのtar ballを展開したら、configureを実行します。
-    </p>
-<pre>
-./configure
-</pre>
-
-    <p>
-    configureに指定できるオプションは以下です。
-    </p>
-
-    <ul>
-    <li><code>--with-memcached=path</code><br/>
-    Memcachedがインストールされているトップディレクトリを指定します。</li>
-    </ul>
-    </dd>
-
-<dt>makeの実行
-    <dd>
-<pre>
-make
-make install
-</pre>
-    </dd>
-</dl>
-
-<p class="top_link"><a href="#Top">△ back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1>pgpool-IIの起動と停止<a name="start"></a></h1>
-
-<h2 id="start_pgpool">pgpool-II の起動</h2>
-<p>
-以上で設定が終わったので、各DBノードを起動してからpgpool-IIを起動します。
-</p>
-<pre>
-pgpool [-c][-f config_file][-a hba_file][-F pcp_config_file][-n][-D][-d]
-</pre>
-
-<table border>
-<tr><td>-c</td><td>--clear-cache</td>
-    <td>クエリキャッシュを消去します</td></tr>
-<tr><td>-f config_file</td><td>--config-file config-file</td>
-    <td>pgpool-IIの設定ファイルを指定します</td></tr>
-<tr><td>-a hba_file</td><td>--hba-file hba_file</td>
-    <td>HBA認証設定ファイルを指定します</td></tr>
-<tr><td>-F pcp_config_file</td><td>--pcp-password-file</td>
-    <td>pcpの設定ファイルを指定します</td></tr>
-<tr><td>-n</td><td>--no-daemon</td>
-    <td>デーモンモードで起動しません（制御端末を切り離しません）</td></tr>
-<tr><td>-D</td><td>--discard-status</td>
-    <td>pgpool_statusを削除し、以前の状態を復元しません
-        <span class="version">V3.0 〜</span></td></tr>
-<tr><td>-C</td><td>--clear-oidmaps</td>
-    <td>インメモリクエリキャッシュの <a href="#MEMQCACHE_OIDDIR">memqcache_oiddir</a> の
-        ディレクトリの中身を消去します
-        （<a href="#MEMQCACHE_METHOD">memqcache_method</a> が 'memcached' のときのみ。
-          'shmem' のときは指定しなくても、必ず消去されます）。
-         <span class="version">V3.2 〜</span></td></tr>
-<tr><td>-d</td><td>--debug</td>
-    <td>デバッグモードで起動します</td></tr>
-</table>
-
-<h2 id="start_pgpool">pgpool-II の停止</h2>
-<p>
-pgpool-IIの停止は後述のpcpコマンドでもできますが、pgpool-IIコマンドを使うこと
-もできます。
-</p>
-<pre>
-pgpool [-f config_file][-F pcp_config_file] [-m {s[mart]|f[ast]|i[mmediate]}] stop
-</pre>
-
-<table border>
-<tr><td>-m s[mart]</td><td>--mode s[mart]</td>
-    <td>接続中のクライアントが接続を終わるのを待ってから停止します(デフォルト)</td></tr>
-<tr><td>-m f[ast]</td><td>--mode f[ast]</td>
-    <td>接続中のクライアントが接続を終わるのを待たずに直ちに停止します</td></tr>
-<tr><td>-m i[mmediate]</td><td>--mode i[mmediate]</td>
-    <td>-m fと同じ動作です</td></tr>
-</table>
-
-<p id="pool_status_file">
-pgpoolが停止すると、[logdir]/pgpool_statusというファイルにバックエンドの状態を書き込みます。
-pgpool-II 3.4.0から、ファイルフォーマットが変更され、ASCIIファイルになりました。
-ですから普通のエディタでこのファイルを参照したり編集ができます。
-たとえば、pgpool.confを編集して新しいバックエンドを追加、再起動した際に
-pgpool-IIが新しいバックエンドの死活を判定するまで待ちたくない場合、
-あらかじめそのバックエンドを"down"状態に編集しておくことができます。
-pgpool_statusの各行はそれぞれのバックエンドの状態に対応します。
-1行目は最初のバックエンド、2行目は2番目のバックエンドというような具合です。
-バックエンドの状態は"up", "down", "unused"のどれかです(大文字小文字は無視されます)。
-例を示します。
-<pre>
-up
-down
-up
-</pre>
-</p>
-
-<p>
-なお、pgpool-II 3.4.0より前のpgpool-IIはバイナリ形式のpgpool_status使用します。
-pgpool-II 3.4.0以降では、バイナリ形式のファイルも読むことができます。
-しかしpgpool-II 3.4.0より前のpgpool-IIはASCII形式のpgpool_statusを読むことはできません。
-</p>
-
-<p>
-次回pgpoolが起動したときにこのファイルが存在すると、バックエンドの状態をそこから復元します。
-これによって、
-</p>
-
-<ol>
-<li>バックエンドが停止してフェイルオーバ</li>
-<li>pgpool経由で正常なDBを更新</li>
-<li>pgpoolを停止</li>
-<li>停止していたDBを再起動</li>
-<li>pgpoolを再起動</li>
-</ol>
-
-<p>
-というシーケンスで、不整合のあるDBからレプリケーション状態に移行することを防ぐことができます。
-</p>
-<p>
-もしもDBの状態に不整合がなくなっている、あるいはpgpool.confを書き換えて設定を変えてしまった、
-というときはpgpool_statusを削除すればバックエンドの状態の復元を行いません。
-</p>
-
-<p class="top_link"><a href="#Top">△ back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1>pgpool-IIの設定ファイルの再読み込み<a name="reload"></a></h1>
-<p>
-pgpool-IIの設定ファイルは、pgpool-IIを再起動することなく読み直すことができます。
-</p>
-<pre>
-pgpool [-f config_file][-a hba_file][-F pcp_config_file] reload
-</pre>
-
-<table border>
-<tr><td>-f config_file</td><td>pgpool-IIの設定ファイルを指定します</tr>
-<tr><td>-a hba_file</td><td>HBA認証設定ファイルを指定します</tr>
-<tr><td>-F pcp_config_file</td><td>pcpの設定ファイルを指定します</tr>
-</table>
-
-<p>
-設定項目によっては、再読み込みを行なっても反映されないものがあるので、ご注意下さい。
-また、設定の変更はすでに接続中のセッションには反映されません。
-次回、クライアントがpgpool-IIに接続したときから反映されます。
-</p>
-
-<p class="top_link"><a href="#Top">△ back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1><a name="show-commands"></a>SHOWコマンド</h1>
-<h2 id="show_commands">概要</h2>
-<p>
-pgpool-IIでは、SHOWコマンドを使って情報を参照することができます。
-SHOWはSQLコマンドですが、pgpool-IIは一部のSHOWコマンドを独自に解釈して、pgpool-IIが管理する情報を返却します。
-以下のようなものがあります。
-</p>
-
-<table border>
-<tr><th><a href="#pool_status">pool_status</a></th><td>構成情報</td></tr>
-<tr><th><a href="#pool_nodes">pool_nodes</a></th>
-    <td>DBノード情報 <span class="version">V3.0 〜</span></td></tr>
-<tr><th><a href="#pool_processes">pool_processes</a></th>
-    <td>pgpool-IIプロセスの内部情報 <span class="version">V3.0 〜</span></td></tr>
-<tr><th><a href="#pool_pools">pool_pools</a></th>
-    <td>コネクションプール情報 <span class="version">V3.0 〜</span></td></tr>
-<tr><th><a href="#pool_version">pool_version</a></th>
-    <td>pgpool-IIのバージョン <span class="version">V3.0 〜</span></td></tr>
-</table>
-
-<p>"pool_status" SQL は以前からありますが、他のSQLはpgpool-II 3.0から追加されました。</p>
-<p>
-<u>注意</u>: "pool"という用語は、pgpoolプロセスによって所有されるPostgreSQLセッションを指します。
-pgpoolによって所有されるセッション全体ではありません。
-</p>
-
-<h2 id="pool_status">pool_status</h2>
-<p>"SHOW pool_status" は設定パラメータの名前と値、説明を表示します。出力の一部を示します。</p>
-<pre>
-benchs2=# show pool_status;
-                 item                 |             value              |                           description
---------------------------------------+--------------------------------+------------------------------------------------------------------
- listen_addresses                     | localhost                      | host name(s) or IP address(es) to listen to
- port                                 | 9999                           | pgpool accepting port number
- socket_dir                           | /tmp                           | pgpool socket directory
- pcp_port                             | 9898                           | PCP port # to bind
- pcp_socket_dir                       | /tmp                           | PCP socket directory
-</pre>
-
-<h2 id="pool_nodes">pool_nodes <span class="version">V3.0 〜</span></h2>
-<p>"SHOW pool_nodes"は、DBノードのリストを表示します。
-ホスト名、ポート番号、状態、重み(ロードバランスモードで運用しているときにのみ意味があります)、
-ノードの役割、発行されたSELECTの数、負荷分散対象のノードかどうか、レプリケーション遅延(単位はバイト、ストリーミングレプリケーションモードの時だけ、それ以外は常に0)が表示されます。
-状態(status)の意味については、<a href="#pcp_node_info">pcp_node_infoリファレンス</a>で説明されています。ホスト名が"/tmp"のように表示される場合、UNIXドメインソケットを使用してpgpool-IIがPosgreSQLに接続していることを意味します。SELECTの数には、pgpool-II内部で発行されるクエリの数は含まれません。また、このカウンタはpgpool-IIがスタートした時に0にリセットされます。
-</p>
-<pre>
-benchs2=# show pool_nodes;
- node_id | hostname | port  | status | lb_weight |  role   | select_cnt | load_balance_node | replication delay 
----------+----------+-------+--------+-----------+---------+------------+-------------------+-------------------
- 0       | /tmp     | 11002 | up     | 0.500000  | primary | 9231       | true              | 0
- 1       | /tmp     | 11003 | up     | 0.500000  | standby | 9469       | false             | 4248
-(2 rows)
-</pre>
-
-<h2 id="pool_processes">pool_processes <span class="version">V3.0 〜</span></h2>
-<p>"SHOW pool_processes"は、接続待ち、あるいは接続中pgpool-IIの子プロセスの状態を表示します。
-</p>
-<p>
-6つのカラムがあります。
-</p>
-<ul>
-    <li>pool_pid はpgpool-IIプロセスのプロセスIDです。</li>
-    <li>start_timeはこのプロセスが起動された時刻です(1970年1月1日からの経過秒で表示されます)。</li>
-    <li>databaseはこのプロセスが接続しているデータベース名です。</li>
-    <li>usernameはこのプロセスの接続で使用しているユーザ名です。</li>
-    <li>create_time isはこの接続が作成された時刻です。</li>
-    <li>pool_counter はこの接続が使用された回数です。</li>
-</ul>
-
-<p>返却行数は常にnum_init_childrenになります。
-また、データベース名などが表示されるのは、そのプロセスにフロントエンドからの接続がある場合に限ります。</p>
-<pre>
-benchs2=# show pool_processes;
- pool_pid |     start_time      | database | username  |     create_time     | pool_counter
-----------+---------------------+----------+-----------+---------------------+--------------
- 8465     | 2010-08-14 08:35:40 |          |           |                     |
- 8466     | 2010-08-14 08:35:40 | benchs   | guillaume | 2010-08-14 08:35:43 | 1
- 8467     | 2010-08-14 08:35:40 |          |           |                     |
- 8468     | 2010-08-14 08:35:40 |          |           |                     |
- 8469     | 2010-08-14 08:35:40 |          |           |                     |
-(5 lines)
-</pre>
-
-<h2 id="pool_pools">pool_pools <span class="version">V3.0 〜</span></h2>
-<p>"SHOW pool_pools"は、pgpool-IIのコネクションプールの状態を表示します。
-</p>
-<p>
-11のカラムがあります。
-</p>
-
-<ul>
-    <li>start_timeはこのプロセスが起動された時刻です(1970年1月1日からの経過秒で表示されます)。</li>
-    <li>pool_pid はpgpool-IIプロセスのプロセスIDです。</li>
-    <li>pool_id はコネクションプールIDです。(0からmax_pool-1の値です)</li>
-    <li>backend_id はPostgreSQLバックエンドの識別子です(0からバックエンド数-1の値です)</li>
-    <li>databaseはこのプロセスが接続しているデータベース名です。</li>
-    <li>usernameはこのプロセスの接続で使用しているユーザ名です。</li>
-    <li>create_time isはこの接続が作成された時刻です。</li>
-    <li>majorversion と minorversion はこの接続で使用されているプロトコルバージョン番号です。</li>
-    <li>pool_counter はこの接続が使用された回数です。</li>
-    <li>pool_backendpid は PostgreSQL のバックエンドプロセスのプロセスIDです。</li>
-    <li>pool_connected は真偽値で、0ならフロントエンドからの接続無し、1なら接続ありを表します。</li>
-</ul>
-
-<p>返却行数は常に<a href="#NUM_INIT_CHILDREN">num_init_children</a> * <a href="#MAX_POOL">max_pool</a> * 「バックエンドの数」になります。
-<pre>
-benchs2=# show pool_pools;
-  pool_pid |     start_time      | pool_id | backend_id | database | username  |     create_time     | majorversion | minorversion | pool_counter | pool_backendpid | pool_connected
-----------+---------------------+---------+------------+----------+-----------+---------------------+--------------+--------------+--------------+-----------------+----------------
- 8465     | 2010-08-14 08:35:40 | 0       | 0          |          |           |                     |              |              |              |                 |
- 8465     | 2010-08-14 08:35:40 | 1       | 0          |          |           |                     |              |              |              |                 |
- 8465     | 2010-08-14 08:35:40 | 2       | 0          |          |           |                     |              |              |              |                 |
- 8465     | 2010-08-14 08:35:40 | 3       | 0          |          |           |                     |              |              |              |                 |
- 8466     | 2010-08-14 08:35:40 | 0       | 0          | benchs   | guillaume | 2010-08-14 08:35:43 | 3            | 0            | 1            | 8473            | 1
- 8466     | 2010-08-14 08:35:40 | 1       | 0          |          |           |                     |              |              |              |                 |
- 8466     | 2010-08-14 08:35:40 | 2       | 0          |          |           |                     |              |              |              |                 |
- 8466     | 2010-08-14 08:35:40 | 3       | 0          |          |           |                     |              |              |              |                 |
- 8467     | 2010-08-14 08:35:40 | 0       | 0          |          |           |                     |              |              |              |                 |
- 8467     | 2010-08-14 08:35:40 | 1       | 0          |          |           |                     |              |              |              |                 |
- 8467     | 2010-08-14 08:35:40 | 2       | 0          |          |           |                     |              |              |              |                 |
- 8467     | 2010-08-14 08:35:40 | 3       | 0          |          |           |                     |              |              |              |                 |
- 8468     | 2010-08-14 08:35:40 | 0       | 0          |          |           |                     |              |              |              |                 |
- 8468     | 2010-08-14 08:35:40 | 1       | 0          |          |           |                     |              |              |              |                 |
- 8468     | 2010-08-14 08:35:40 | 2       | 0          |          |           |                     |              |              |              |                 |
- 8468     | 2010-08-14 08:35:40 | 3       | 0          |          |           |                     |              |              |              |                 |
- 8469     | 2010-08-14 08:35:40 | 0       | 0          |          |           |                     |              |              |              |                 |
- 8469     | 2010-08-14 08:35:40 | 1       | 0          |          |           |                     |              |              |              |                 |
- 8469     | 2010-08-14 08:35:40 | 2       | 0          |          |           |                     |              |              |              |                 |
- 8469     | 2010-08-14 08:35:40 | 3       | 0          |          |           |                     |              |              |              |                 |
-(20 lines)
-</pre>
-
-<h2 id="pool_version">pool_version <span class="version">V3.0 〜</span></h2>
-<p>"SHOW pool_version" はpgpool-IIのバージョン情報を表示します。
-例を示します。
-</p>
-<pre>
-benchs2=# show pool_version;
-      pool_version
-------------------------
- 3.0-dev (umiyameboshi)
-(1 line)
-</pre>
-
-<h2 id="pool_cache">pool_cache <span class="version">V3.1 〜</span></h2>
-<p>"SHOW pool_cache" は<a href="#memqcache">インメモリクエリキャッシュ</a>が有効である場合に、クエリキャッシュのヒット率や、キャッシュストレージの状況を表示します。
-例を示します。
-</p>
-<p>
-<pre>
-test=# \x
-\x
-Expanded display is on.
-test=# show pool_cache;
-show pool_cache;
--[ RECORD 1 ]---------------+---------
-num_cache_hits              | 891703
-num_selects                 | 99995
-cache_hit_ratio             | 0.90
-num_hash_entries            | 131072
-used_hash_entries           | 99992
-num_cache_entries           | 99992
-used_cache_enrties_size     | 12482600
-free_cache_entries_size     | 54626264
-fragment_cache_entries_size | 0
-</pre>
-</p>
-
-<ul>
-<li>num_cache_hits は、キャッシュにヒットした検索件数を表示します。</li>
-<li>
-num_selects は、キャッシュにヒットしなかった検索件数を表示します。
-cache_hit_ratio は、キャッシュヒット率で、num_cache_hits/(num_cache_hits+num_selects)
-から計算されています。
-</li>
-<li>num_hash_entries 以下は、キャッシュストレージが共有メモリの時だけ有効です。</li>
-<li>
-num_hash_entries は、キャッシュの検索インデックスであるハッシュテーブルのエントリ数を表し、
-pgpool.confの <a href="MEMQCACHE_MAX_NUM_CACHE">memqcache_max_num_cache</a> と一致します。
-この値が登録できるキャッシュ件数の最大値になります。
-</li>
-<li>used_hash_entries は、num_hash_entries のうち、使用済みのエントリ数です。</li>
-<li>num_cache_entries は、キャッシュ本体の登録件数で、used_hash_entries と一致します。</li>
-<li>
-used_cache_enrties_size は、使用済みのキャッシュ領域の合計サイズです。
-単位はバイトです。
-</li>
-<li>
-free_cache_entries_size は、キャッシュ領域のうち、未使用または最利用可能な領域の合計サイズです。
-単位はバイトです。
-</li>
-<li>
-fragment_cache_entries_size は、空き領域ではあるが、断片化していて利用できないキャッシュ領域の合計サイズです。
-単位はバイトです。
-断片化した領域は、利用できるキャッシュ領域を使い果たした時に自動的に再利用できるようになります。
-</li>
-</ul>
-
-<p class="top_link"><a href="#Top">△ back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1><a name="online-recovery"></a>オンラインリカバリ</h1>
-<h2>オンラインリカバリ概要</h2>
-<p>
-この章では、レプリケーションモードで利用する場合のオンラインリカバリ機能
-について説明します。
-マスタ／スレーブモード(Streaming Replication)でのオンラインリカバリの利用方法については、
-<a href="#stream">Streaming Replicationへの対応</a>をご覧下さい。
-レプリケーションモードで pgpool が動作している場合、ダウンしたノードのデータを再同期させた上で、
-ノードを復帰させることができます。この機能を「オンラインリカバリ」と呼びます。
-</p>
-
-<p>
-オンラインリカバリを実施するためには、ノードが切り離されていると
-pgpool が検知している必要があります。ノードを動的に追加したい場合には
-pgpool.conf の backend_hostnameなどのパラメータを追加しておき、
-設定ファイルを再読み込みさせると、ノードが切り離された状態で pgpool にノード情報が登録されます。
-</p>
-
-<p>
-また、リカバリするノードの PostgreSQL がすでに動作中であれば、あらかじめ
-PostgreSQL をシャットダウンさせておいてください。
-</p>
-
-<!--
-<p>
-<font color="red">注意: オンラインリカバリを実行する前に、マスタノード
-(稼働中のノードのうち、一番番号が若いノード)上でのautovacuumを停止してください。
-オンラインリカバリ中にautovacuumが動くと、データベースの内容が変化する可能性があるため、
-ノード間の同期がきちんと取れなくなる可能性があります。
-この制限は、rsyncなどの単純なコピー方法を使っている場合にのみ適用されます。
-PostgreSQLのPITRを使っている場合は適用されません。
-</font>
-</p>
--->
-
-<p>
-pgpool ではオンラインリカバリを 2 段階に分けて実施します。
-pgpool のクライアントからは完全なデータの同期を取るために若干の接続待ちが発生します。
-リカバリ手順で以下のとおりです。
-</p>
-
-<ol>
-    <li>CHECKPOINT 実行</li>
-    <li>ファーストステージの実施</li>
-    <li>接続がすべて切断されるまで待機</li>
-    <li>CHECKPOINT 実行</li>
-    <li>セカンドステージの実施</li>
-    <li>postmaster の起動(pgpool_remote_start の実行)</li>
-    <li>ノードの復帰</li>
-</ol>
-
-<p>
-データ同期の第一段階を「ファーストステージ」と呼びます。ファーストステージ中に1 回目のデータ同期を行います。
-ファーストステージ中はデータの更新や参照を並行して行うことができます。
-</p>
-
-<p>
-ファーストステージで処理する内容はユーザが定義することができます。
-スクリプトでは 3 つの引数を受け取ることができます。
-</p>
-<ol>
-    <li>マスタのデータベースクラスタパス</li>
-    <li>リカバリノードのホスト名</li>
-    <li>リカバリノードのデータベースクラスタパス</li>
-</ol>
-
-<p>
-次に 2 回目のデータ同期を行います。これを「セカンドステージ」と呼びます。
-pgpool ではセカンドステージに入る前に接続中のクライアントがすべて接続が終了されるまで待ちます。
-その間に接続リクエストが来た場合には、その接続をすべてブロックします。
-</p>
-
-<p>
-セカンドステージで処理する内容はユーザが定義することができます。
-スクリプトでは 3 つの引数を受け取ることができます。
-</p>
-<ol>
-    <li>マスタのデータベースクラスタパス</li>
-    <li>リカバリノードのホスト名</li>
-    <li>リカバリノードのデータベースクラスタパス</li>
-</ol>
-
-<p>
-すべての接続が終了されると、ファーストステージ以降に更新されたデータを同期するための
-セカンドステージが開始されます。そこで最終的なデータの同期を行います。
-この間はクライアントからは pgpool への接続が待たされる状態になります。
-</p>
-
-<p>
-<font color="red">
-なお、オンラインリカバリの制限事項として、複数のホストに pgpool を配置して
-レプリケーションさせている場合には、オンラインリカバリは正しく動作しません。
-どれかの pgpool にリカバリリクエストを出した時に、他の pgpool から更新が伝搬すると、
-データを同期させることができなく
-なります。
-</font>
-</p>
-
-<h2 id="online_recovery_params">pgpool の設定</h2>
-<p>
-オンラインリカバリを設定するためには、pgpool.conf の以下の値を設定してください。
-</p>
-
-<ul>
-    <li><a href="#BACKEND_DATA_DIRECTORY">backend_data_directory</a></li>
-    <li><a href="#RECOVERY_USER">recovery_user</a></li>
-    <li><a href="#RECOVERY_PASSWORD">recovery_password</a></li>
-    <li><a href="#RECOVERY_1ST_STAGE_COMMAND">recovery_1st_stage_command</a></li>
-    <li><a href="#RECOVERY_2ND_STAGE_COMMAND">recovery_2nd_stage_command></a></li>
-</ul>
-
-<h2 id="installing-c-functions">C 言語関数のインストール</h2>
-<p>
-次に、リカバリを実施するための PostgreSQL の C 言語関数を各ノードの
-template1 データベースにインストールします。ソースコードは
-</p>
-
-<pre>
-pgpool-II-x.x.x/sql/pgpool-recovery/
-</pre>
-
-<p>
-にあります。ディレクトリを移動し、make install してください。
-</p>
-
-<pre>
-% cd pgpool-II-x.x.x/sql/pgpool-recovery/
-% make install
-</pre>
-
-<p>
-C 言語関数のモジュールをインストールしたら、続いて C 言語関数を呼びだすための SQL をインストールします。
-</p>
-
-<pre>
-% cd pgpool-II-x.x.x/sql/pgpool-recovery/
-% psql -f pgpool-recovery.sql template1
-</pre>
-
-<h2 id="recovery_script">リカバリスクリプトの配置</h2>
-<p>
-データを同期させるためのスクリプトと、リモートから postmaster を再起動させるためのスクリプトを
-各ノードの $PGDATA 以下に配置します。
-あらかじめpgpool-II-x.x.x/sample 以下にサンプルスクリプトも用意してありますので参考にしてください。
-ここではサンプルスクリプトを使って、PITR によるリカバリ方法と、rsync によるリカバリ方法を説明します。
-</p>
-
-<h3 id="recovery_pitr">PITR によるリカバリ</h3>
-<p>
-ここでは PostgreSQL 8.2 以降で PITR 機能を使ってリカバリをする設定例を説明します。
-PITR によるリカバリをする場合にはあらかじめ PostgreSQL の設定で
-ログをアーカイブさせるようにしておいてください。
-</p>
-
-<h4>1st stage</h4>
-<p>
-まずファーストステージでベースバックアップを取得し、リカバリ先へコピーするスクリプト
-(ここではファイル名を copy-base-backup とします)を用意します。
-例えば以下のようなスクリプトで取得することができます。
-</p>
-
-<pre>
-#! /bin/sh
-
-DATA=$1
-RECOVERY_TARGET=$2
-RECOVERY_DATA=$3
-
-psql -c "select pg_start_backup('pgpool-recovery')" postgres
-echo "restore_command = 'scp $HOSTNAME:/data/archive_log/%f %p'" &gt; /data/recovery.conf
-tar -C /data -zcf pgsql.tar.gz pgsql
-psql -c 'select pg_stop_backup()' postgres
-scp pgsql.tar.gz $RECOVERY_TARGET:$RECOVERY_DATA
-</pre>
-
-<p>
-ベースバックアップ取得時に recovery.conf を生成しておきます。
-</p>
-<pre>
-restore_command = 'scp master:/data/archive_log/%f %p'
-</pre>
-
-<h4>2nd stage</h4>
-
-<p>
-セカンドステージでは最新の状態まで PITR によるリカバリを実施できるようにするために、
-pgpool_recovery_pitr スクリプトを$PGDATA にコピーします。
-このスクリプトではトランザクションログを強制的に切り替えるようにします。
-</p>
-<p>
-通常、トランザクションログを切り替えるには、pg_switch_xlog 関数を利用しますが、
-この関数は、アーカイブログファイルが生成される前に終了してしまう可能性があります。
-</p>
-<p><span class="version">V3.1 〜</span>
-そこで、より安全にオンラインリカバリを行うために
-pgpool_switch_xlog 関数が用意されています。
-pgpool_switch_xlog 関数の基本動作は pg_switch_xlog 関数と同じですが、
-トランザクションログの切り替えによるアーカイブログファイルの生成を
-待ってから終了します。
-この関数は、前述の「C言語関数のインストール」を実施するとインストールされ、
-引数にはアーカイブログの出力先ディレクトリを指定します。
-</p>
-<p>
-<pre>
-#! /bin/sh
-# Online recovery 2nd stage script
-#
-datadir=$1       # master dabatase cluster
-DEST=$2          # hostname of the DB node to be recovered
-DESTDIR=$3       # database cluster of the DB node to be recovered
-port=5432        # PostgreSQL port number
-archdir=/data/archive_log    # archive log directory
-
-# Force to flush current value of sequences to xlog
-psql -p $port -t -c 'SELECT datname FROM pg_database WHERE NOT datistemplate AND datallowconn' template1|
-while read i
-do
-  if [ "$i" != "" ];then
-    psql -p $port -c "SELECT setval(oid, nextval(oid)) FROM pg_class WHERE relkind = 'S'" $i
-  fi
-done
-
-psql -p $port -c "SELECT pgpool_switch_xlog('$archdir')" template1
-</pre>
-
-<p>
-スクリプト中のwhileループは、全データベース中のシーケンス値をトランザクションログに吐き出します。
-これによって、シーケンスも正しくリカバリされるようになります。
-</p>
-
-<p>
-スクリプトの配置が完了したら pgpool.conf に設定します。
-</p>
-
-<pre>
-recovery_1st_stage_command = 'copy-base-backup'
-recovery_2nd_stage_command = 'pgpool_recovery_pitr'
-</pre>
-
-<p>
-これで PITR によるオンラインリカバリの準備が完了です。
-</p>
-
-<h4 id="pool_remote_start">pgpool_remote_start</h4>
-<p>
-データ再同期後に postmaster を起動させるスクリプトです。
-pgpool からは以下の形式でスクリプトを実行します。
-</p>
-
-<pre>
-% pgpool_remote_start remote_host remote_datadir
-remote_host:    リカバリノードのホスト名
-remote_datadir: リカバリノードのデータベースクラスタパス
-</pre>
-
-<p>
-サンプルスクリプトでは ssh 経由で postmaster を起動しています。
-こちらもあらかじめパスフレーズ無しで ssh 経由でログインできるように設定しておく必要があります。
-</p>
-
-<p>
-PITR によるリカバリであれば、pgpool_remote_start 内でベースバックアップを展開し、
-recovery.conf の内容にしたがってリカバリした後にpostmaster が接続可能状態になります。
-</p>
-
-<pre>
-#! /bin/sh
-DEST=$1
-DESTDIR=$2
-PGCTL=/usr/local/pgsql/bin/pg_ctl
-
-# Expand a base backup
-ssh -T $DEST 'cd /data/; tar zxf pgsql.tar.gz' 2&gt;/dev/null 1&gt;/dev/null &lt; /dev/null
-# Startup PostgreSQL server
-ssh -T $DEST $PGCTL -w -D $DESTDIR start 2&gt;/dev/null 1&gt;/dev/null &lt; /dev/null &amp;
-</pre>
-
-<h3 id="recovery_rsync">rsync によるリカバリ </h3>
-<p>
-7.4 以前の場合は PITR 機能がありません。また、8.0 と 8.1 の場合は
-トランザクションログを強制的に切り替える関数が用意されていません。
-そこで PITR を使わずにrsync を使ったリカバリ方法を説明します。
-</p>
-<p>
-sample ディレクトリに pgpool_recovery というファイルがあります。
-マスタから復帰させるノードへのデータの物理コピーを行うスクリプトです。
-pgpool からは以下の形式でスクリプトを実行します。
-</p>
-
-<pre>
-% pgpool_recovery datadir remote_host remote_datadir
-datadir:        マスタのデータベースクラスタパス
-remote_host:    リカバリノードのホスト名
-remote_datadir: リカバリノードのデータベースクラスタパス
-</pre>
-
-<p>
-サンプルスクリプトでは rsync を使って物理コピーをしています。もし
-rsync を使う場合は、パスフレーズ無しで ssh 経由でログインできるように
-あらかじめ設定しておく必要があります。
-</p>
-
-<p>
-rsyncに関する注記:
-</p>
-<ul>
-    <li>-c (or --checksum) オプションを付けないと、ファイルが確実に転送されない場合があります。</li>
-    <li>-z (or --compress)オプションは低速なネットワークでは効果がありますが、
-        100M以上の高速なネットワークではかえってCPU負荷を増やし、結果的に遅くなることがあります。
-        高速ネットワークでは、このオプションを使用しないことをお勧めします。
-    </li>
-    <li>rsync の新しいバージョン(3.0.5)では、50%も性能が良くなったという報告が
-        pgpool-generalメーリングリストでありました。
-     </li>
-</ul>
-
-<p>
-pgpool_recovery を使う場合は pgpool.conf に以下の行を追加してください。
-</p>
-
-<pre>
-recovery_1st_stage_command = 'pgpool_recovery'
-recovery_2nd_stage_command = 'pgpool_recovery'
-</pre>
-
-<h2 id="perform_online_recovery">リカバリの実行</h2>
-<p>
-以上でオンラインリカバリの準備が整いました。
-オンラインリカバリを実行するには <a href="#pcp_recovery_node">pcp_recovery_node</a> コマンドを使うか、
-pgpool 管理ツールから実行してください。
-</p>
-
-<p>
-注意点として、<a href="#pcp_recovery_node">pcp_recovery_node</a> を実行する際に、タイムアウトを長くして
-ください。pgpoolAdmin から実行する場合は pgmgt.conf.php 内の
-_PGPOOL2_PCP_TIMEOUT を大きくしてください。
-</p>
-
-<h2 id="minorup_w_online_recovery">オンラインリカバリを利用したPostgreSQLのマイナーバージョンアップ</h2>
-<h3>レプリケーションモードの場合</h3>
-<p>
-レプリケーションモードでpgpool-IIが動作している場合は、
-オンラインで各ノードのPostgreSQLをバージョンアップできます。
-ただし、ノードの切り離し時と追加時に、pgpool-IIに接続しているすべての
-すべてのセッションが切断されるので注意してください。
-また、オンラインリカバリが利用できるバージョンアップはマイナーバージョンアップのみで、
-ダンプ/リストアが不要なリリースに限ります。
-</p>
-
-<p>
-はじめに、上記の「オンラインリカバリの概要」を参考に各ノードでオンラインリカバリが利用できるように準備します。
-</p>
-
-<p>
-PostgreSQLのバージョンアップは、マスタ以外のノードから行い、最後にマスタノードをバージョンアップします。
-そこで、まずバージョンアップを行うマスタ以外の１つのノードのPostgreSQLを停止します。
-pgpool-IIがPostgreSQLの停止を検知すると、以下のようなログを出力して縮退運転に移行します。
-その際、pgpool-IIに接続しているすべてのセッションは一旦切断されます。
-</p>
-<pre>
-2010-07-27 16:32:29 LOG:   pid 10215: set 1 th backend down status
-2010-07-27 16:32:29 LOG:   pid 10215: starting degeneration. shutdown host localhost(5433)
-2010-07-27 16:32:29 LOG:   pid 10215: failover_handler: set new master node: 0
-2010-07-27 16:32:29 LOG:   pid 10215: failover done. shutdown host localhost(5433)
-</pre>
-
-<p>
-停止したノードのPostgreSQLをバージョンアップします。
-バージョンアップは、新しいバージョンのPostgreSQLを古いバージョンのインストール先に上書きしても構いませんが、
-問題が起きた時に元のバージョンに戻せるようにインストール先を変えておくことをお勧めします。
-</p>
-
-<p>
-新しいバージョンのPostgreSQLを古いバージョンと別の場所にインストールした場合、
-リカバリスクリプトを編集することなくそのまま使用するには、シンボリックリンクなどを使用して
-インストール先のパスを以前と合わせる必要があります。
-上書きインストールした場合は以下のC言語関数をインストールするまでの操作は不要です。
-すぐにオンラインリカバリが実行できます。
-</p>
-
-<p>
-古いバージョンのPostgreSQLのインストール先ディレクトリ名を変更します。
-以下は、PostgreSQLが/usr/local/pgsqlにインストールされていたと仮定した一例です。
-</p>
-<pre>
-$ mv /usr/local/pgsql /usr/local/pgsql-old
-</pre>
-
-<p>
-新しいバージョンのPostgreSQLのインストール先にシンボリックリンクを作成します。
-これにより、今までどおりのパスで新しいバージョンのPostgreSQLが使用できるようになります。
-以下は、新しいバージョンのPostgreSQLが/usr/local/pgsql-newにインストールされていると仮定した一例です。
-</p>
-<pre>
-$ ln -s /usr/local/pgsql-new /usr/local/pgsql
-</pre>
-
-<p>
-データベースクラスタディレクトリがPostgreSQLのインストール先ディレクトリの下位にある場合は、
-同じパスでデータベースクラスタにアクセスできるようにシンボリックリンクを作成するかコピーします。
-以下は、シンボリックリンクを作成する例です。
-</p>
-<pre>
-$ ln -s /usr/local/pgsql-old/data /usr/local/pgsql/data
-</pre>
-
-<p>
-新しいバージョンのPostgreSQLに、オンラインリカバリ用の関数を
-「C言語関数のインストール」を参考にインストールします。
-オンラインリカバリは、データベースクラスタをコピーしますので、最後のpsqlを使用した関数の作成は不要です。
-make installを実行してください。
-</p>
-
-<p>
-最後にオンラインリカバリを実行して、１つのノードのバージョンアップが完了します。
-オンラインリカバリは、pcp_recovery_nodeコマンドを実行するかpgpoolAdminで行います。
-</p>
-
-<p>
-以上の手順をマスタ以外のノードで繰り返し、最後にマスタノードで行えば、
-全体のPostgreSQLのマイナーバージョンアップは完了です。
-</p>
-
-<h3>Streaming Replicationを利用している場合</h3>
-<p>
-マスタースレーブモードでStreaming Replicationを利用している場合は、
-オンラインでスタンバイのPostgreSQLをマイナーバージョンアップできます。
-</p>
-
-<p>
-スタンバイのPostgreSQLをマイナーバージョンアップする手順は、上記のレプリケーションモードの手順と同じです。
-ただし、recovery_1st_stage_commandとrecovery_2nd_stage_commandの設定などは、
-「Streaming Replicationでのオンラインリカバリ」を参考にしてください。
-</p>
-
-<p>
-プライマリのPostgreSQLのマイナーバージョンアップは、オンラインではできません。
-pgpool-IIの停止が必要になります。
-プライマリのPostgreSQLもバージョンアップの方法自体は、スタンバイと同様です。
-プライマリのPostgreSQLのバージョンアップは以下の手順で行います。
-<ol>
-<li>pgpool-IIを停止
-<li>プライマリのPostgreSQLを停止
-<li>プライマリのPostgreSQLをバージョンアップ
-<li>プライマリのPostgreSQLを起動
-<li>pgpool-IIを起動
-</ol>
-</p>
-
-<p class="top_link"><a href="#Top">△ back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1><a name="backup"></a>バックアップ</h1>
-<p>
-バックエンドのPostgreSQLのバックアップは、単体のPostgreSQLと同様に、
-物理バックアップ、論理バックアップ(pg_dump, pg_dumpall)、PITRが使用できます。
-ただし、論理バックアップとPITRの操作は、pgpool-IIを経由せずにPostgreSQLに対して直接行ってください。
-これは、<a href="#LOAD_BALANCE_MODE">load_balance_mode</a>や<a href="#REPLICATE_SELECT">replicate_select</a>などの
-設定によるバックアップの失敗を避けるためです。
-</p>
-
-<h2 id="backup_rep_or_ms_mode">レプリケーションモード、マスタースレーブモード</h2>
-<p>
-レプリケーションモードとマスタースレーブモードでpgpool-IIが動作している場合は、
-クラスタを構成しているいずれかのノードでバックアップを行います。
-</p>
-
-<p>
-マスタースレーブモードで非同期のレプリケーションを行っている場合で、かつ、
-最新のバックアップを取得したい場合は、マスタノードでバックアップしてください。
-</p>
-
-<p>
-バックアップ時の注意点として、PostgreSQLに対してpg_dumpコマンドなどを実行すると、
-ACCESS SHAREモードのロックがかかります。
-そのため、ACCESS SHAREモードと競合するACCESS EXCLUSIVEロックが必要になるコマンド
-（ALTER TABLE、DROP TABLE、TRUNCATE、REINDEX、CLUSTERおよびVACUUM FULLなど）は、ロック待ちが発生します。
-これは、非同期のレプリケーションで、スレーブノードに対してバックアップを行っている場合も、
-マスタが影響を受けることがありますので注意してください。
-</p>
-
-<p class="top_link"><a href="#Top">△ back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1><a name="deploy"></a>pgpool-IIの配置について</a></h1>
-<p>
-pgpool-IIは、独立したサーバに配置することもできますし、アプリケーションサーバと同居させることもできますし、
-その他の配置も考えられます。
-ここではそれぞれの配置方法を紹介し、それぞれの特徴、メリット、デメリットを検討します。
-</p>
-
-<dl>
-<dt>専用のサーバに配置
-    <dd>
-    <p>
-    pgpool-IIを物理的に独立した専用のサーバに配置する方法です。
-    分かりやすい方法ですし、他のサーバソフトウェアの影響を受けないのでpgpool-IIをもっとも安全に運営できますが、
-    サーバ装置を1台余計に増やす必要があるのが欠点です。
-    また、そのサーバが単一障害点になります(pgpool-IIが単一障害点になることを回避するには、
-    後述の<a href="#watchdog">watchdog</a>かpgpool-HAを併用します)。
-    </p>
-    </dd>
-
-<dt>Webサーバやアプリケーションサーバと同居
-    <dd>
-    <p>
-    Apache、JBoss、TomcatなどのWebサーバやアプリケーションサーバが稼働しているサーバに
-    pgpool-IIを同居させる方法です。
-    この方法では、Webサーバやアプリケーションサーバとpgpool-IIの通信がローカルマシン内になるので、
-    ソケット通信がマシン間で通信するよりも高速になるメリットがあります。
-    また、複数のWebサーバ／アプリケーションサーバがあれば、自然と単一障害点を回避できるようになります。
-    (この場合、複数のpgpool-IIの設定は<a href="#watchdog">watchdog用の設定</a>を除き同じにしてください)。
-    なお、複数のpgpool-IIが動作しているケースでは以下のような問題が考えられますが、
-    <a href="#watchdog">watchdog</a>を有効にすることによって回避できます。
-    したがって、このような構成では<a href="#watchdog">watchdog</a>を有効にすることを強くおすすめします。
-    </p>
-    <ul>
-        <li>pgpool-IIとDBサーバの間のネットワークが不安定だと、pgpool-IIから見てDBノード#1がダウン、
-            他のpgpool-IIから見て正常、というような状態になってしまうことがあります。
-            ネットワークを二重化するなどして、ネットワーク障害が起きないようにしてください。
-        </li>
-        <li>レプリケーションモードで、オンラインリカバリ実行中は、一つのpgpool-IIだけ残して
-            他のpgpool-IIを落してください。
-            さもないと、リカバリ後の結果に整合性がなくなる可能性があります。
-            マスター／スレーブモード+Streaming Replicationモードでは、同時に複数のpgpool-IIで
-            オンラインリカバリを実行しない限り、問題ありません。
-        </li>
-    </ul>
-    </dd>
-
-<dt>DBサーバと同居
-    <dd>
-    <p>
-    PostgreSQLの稼働しているDBサーバと同居させる方法です。
-    この方法では、pgpool-IIが単一障害点になることがなく、余計なサーバを追加する必要もない点が優れていますが、
-    アプリケーションがどのDBサーバに接続するのかを自ら判断する必要があるのが欠点です。
-    この問題を解決するには、<a href="#watchdog">watchdog</a>を有効にするか、pgpool-HAと組み合わせて仮想IPを利用します。
-    </p>
-    </dd>
-</dl>
-
-<h2 id="pgpool_ha">pgpool-HAについて</h2>
-<p>
-pgpool-HAは、heartbeatなどを利用してpgpool-IIを二重化し、pgpool-II自体の可用性を上げるソフトウェアです。
-pgpool-IIと同様、pgpoolプロジェクトのサブプロジェクトであり、pgpoolの開発サイトでOSSとして公開されています。
-</p>
-
-<p class="top_link"><a href="#Top">△ back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1 id="watchdog">Watchdog <span class="version">V3.2 ～</span></h1>
-<h2 id="what_is_watchdog">watchdog とは</h2>
-<p>
-watchdog プロセスは pgpool-II から起動される、高可用性を目的としたプロセスです。
-複数の pgpool-II を連携させることで単一障害点を回避します。
-pgpool-II <span class="version">V3.5 -</span> で watchdog は大幅に改善され、常にクォーラム（定足数）が確立されているようになりました。
-この新機能により watchdog はスプリットブレイン現象やネットワーク分断の対処や防止に関して、対障害性が向上し、よりロバストになりました。
-ただし、スプリットブレイン現象やネットワーク分断の対処や防止機能が正しく動くためには、pgpool-IIノードの数は3以上で、かつ奇数でなけれななりません。
-watchdog は以下の機能をから構成されます。
-</p>
-<h3>pgpool-II の死活監視</h3>
-<p>
-watchdog の lifecheck は watchdog 高可用性クラスタに参加している pgpool-II ノードの死活監視を行うサブコンポーネントです。
-従来の pgpool-II watchdog ではリモートノードの監視方法として "heartbeat" と "query" の２つのモードが提供されていました。
-pgpool-II <span class="version">V3.5 -</span> の watchdog では新しいモードとして "external" が追加されました。
-これにより、外部のサードパーティツールによる死活監視システムを pgpool-II watchdog で使用することが可能になります。
-サードパーティツールを watchdog で使用する方法について詳しくは
-<a href="#INTEGRATE_EXT_LIFECHECK">外部死活監視ツールとの連携</a> を参照してください。
-リモートノードの死活監視とは別に、lifecheck は上位サーバへの接続を監視することでローカルノードの状態もチェックすることも可能です。
-</p>
-<ul>
-<li>
-    ハートビートモードでは、watchdog はハートビート信号を用いて 他の pgpool-II プロセスの死活監視を行います。
-    watchdog は、他の pgpool-II の watchdog より定期的に送られるハートビート信号を受け取り、
-    これが一定期間以上途切れた場合には当該 pgpool-II プロセスに障害が発生したと判断します。
-    冗長性を高めるために、複数のネットワークを用いたハートビート交換が可能です。
-    デフォルトではこのモードで動作し、これが推奨設定です。
-</li>
-<li>
-    クエリモードでは、watchdog は pgpool-II のプロセスではなく「サービス」の応答を監視します。
-    このモードでは、監視対象の pgpool-II にクエリを発行しその応答をチェックします。
-    この方法では他の pgpool-II から接続を受ける必要があるため、<a href="NUM_INIT_CHILDREN">num_init_children</a> が
-    十分大きくない場合には監視が失敗する場合があることに注意してください。
-    これは非推奨の監視方法であり、下位互換のために残されています。
-</li>
-<li>
-外部ツールモード <span class="version">V3.5 -</span> では、基本的に pgpool-II watchdog
-の組み込みの死活監視を無効にし、外部システムが ローカルノード、および watchdog クラスタに参加する全リモートノードの状態を
-watchdog に通知することを期待します。
-</li>
-</ul>
-    <p>
-    また watchdog は、pgpool-II から上位のサーバ（アプリケーションサーバなど）への接続も監視し、
-    上位サーバへ pgpool-II のサービスを提供できるかチェックしています。
-    この監視に失敗した場合には、watchdog は pgpool-II に障害が発生しているとみなしダウンステータスに移行します。
-    </p>
-<h3>pgpool-II 間の協調動作</h3>
-    <p>
-    watchdog は互いに情報交換を行うことで複数の pgpool-II を協調動作させます。
-    </p>
-<ul>
-    <li>
-    フェイルオーバなどでバックエンドノードの状態が変化した場合には、この情報を他の pgpool-II へ伝達し、同期を行います。
-    </li>
-    <li>
-    オンラインリカバリ時には、複数の pgpool-II で DB に不整合が生じないよう他の pgpool-II へのクライアントの接続を制限します。
-    </li>
-    </p>
-    <li>
-    フェイルオーバ、ファイルバックの際に実行されるコマンド（<a href="#FAILOVER_COMMAND">failover_command</a>,
-    <a href="#FAILBACK_COMMAND">failback_command</a>, <a href="#FOLLOW_MASTER_COMMAND">follow_master_command</a>）は、
-    インターロック機構により、１つの pgpool-II でのみ実行されます。
-    </li>
-</ul>
-
-<h3>障害発生検知時のアクティブ、スタンバイ切り替え</h3>
-    <p>
-    pgpool-II の障害を検知した場合、watchdog は他の watchdog に障害検知を通知します。
-    故障した pgpool-II がアクティブの場合、他の watchdog は新しいアクティブを投票で決め、
-    アクティブ・スタンバイの切り替えを行います。
-    </p>
-
-<h3>全ノードの重要な設定パラメータの整合性検証 <span class="version">V3.5 -</span></h3>
-
-    <p>
-    watchdog の起動時にローカルノードの pgpool-II の設定がマスター watchdog ノードの設定と整合がとれているか検証します。
-    これにより pgpool-II ノード間の設定の不一致によって発生する予期しない挙動の可能性が軽減されます。
-    </p>
-
-<h3>サーバ切り替えと連動した仮想 IP アドレスの自動付け替え</h3>
-    <p>
-    スタンバイが新しいアクティブに昇格する際、新アクティブ機の watchdog は
-    アクティブ用の仮想IPインターフェースを起動します。
-    </p>
-    <p>
-    一方、旧アクティブ機の watchdog はアクティブ用仮想 IP インターフェースを停止します。
-    これにより、サーバが切り替わった後もアクティブは同じ IP アドレスでサービスを継続することができます。
-    </p>
-
-<h3>サーバ復旧時、スタンバイ機としての自動登録</h3>
-    <p>
-    障害機の復旧や新規サーバを追加する場合、watchdog はサーバの情報を他の watchdog に通知し、
-    他の watchdog からはアクティブや他のサーバの情報を受け取ります。
-    これにより追加したサーバはスタンバイ機として自動的に追加されます。
-    </p>
-
-
-<h2 id="watchdog_server_composition">サーバ構成</h2>
-<p>
-watchdogプロセスを含むpgpool-IIサーバは以下の図のようなシステム構成をとります。
-</p>
-
-<p><img src="wd-ja.jpg" alt="watchdog server composition" hight="70%" width="70%"></p>
-
-<h2 id="start_watchdog">watchdog の起動と停止</h2>
-<p>
-watchdog プロセスは pgpool-II の子プロセスとして自動的に起動・停止されますので、固有の起動・停止コマンドはありません。
-</p>
-<p>
-watchdog は仮想 IP インターフェースの起動・停止を行うため、 <font color="red">root 権限</font>を要求します。
-pgpool-II を起動する際に root 権限で実行するのが１つの方法です。
-しかし、セキュリティ上の理由からは、sudo や setuid を利用したコマンドを <a href="#IF_UP_CMD">if_up_cmd</a>、
-<a href="#IF_DOWN_CMD">if_up_cmd</a>、<a href="#ARPING_CMD">if_up_cmd</a> に設定するのがより良い方法です。
-</p>
-<p>
-watchdog 組み込みの死活監視は他の全ての pgpool-II が起動した後に開始されます。
-全ての pgpool-II が起動していない状態では監視は行われず、仮想 IP の切り替えも行われません。
-</p>
-
-<h2 id="config_watchdog">pgpool.conf の設定</h2>
-<p>
-watchdog プロセスの設定項目は pgpool.conf に記述します。
-pgpool.conf.sample ファイルの WATCHDOG セクションにサンプルを記述していますので、参照してください。
-</p>
-<p>
-watchdog プロセスは以下の項目すべてを指定する必要があります。
-</p>
-
-<h3>有効化</h3>
-<dl>
-<dt><a name="USE_WATCHDOG"></a>use_watchdog <span class="version">V3.2 ～</span></dt>
-    <dd>
-    <p>
-    watchdog を有効にするには on にします。デフォルトは off です。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-</dl>
-
-<h3>watchdog 間通信</h3>
-
-<p>watchdog 間の情報交換に関する設定です。</p>
-
-<dl>
-<dt><a name="WD_HOSTNAME"></a>wd_hostname <span class="version">V3.2 ～</span></dt>
-    <dd>
-    <p>
-    pgpool-II サーバのホスト名または IP アドレスです。
-    クエリやパケットの送受信の他、watchdog の識別子としても用います。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-
-<dt><a name="WD_PORT"></a>wd_port <span class="version">V3.2 ～</span></dt>
-    <dd>
-    <p>
-    wachdog 間の情報交換のためのパケットを受信するポート番号を指定します。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-
-<dt><a name="WD_AUTHKEY"></a>wd_authkey <span class="version">V3.3 ～</span></dt>
-    <dd>
-    <p>
-    wachdog 間通信で用いられる認証キーです。
-    全ての pgpool-II で同じキーを指定する必要があります。
-    認証キーが異なる watchdog からの通信は拒絶されます。
-    死活監視をハートビートモードで行う場合には、この認証はハートビート信号にも適用されます。
-    指定が無い場合には認証は行われず、これがデフォルトです。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-</dl>
-
-<h3>上位サーバへの接続</h3>
-<p>
-pgpool-II あるいは PostgreSQL のサービス提供先（DB クライアント）のサーバを、上位サーバと呼びます。
-pgpool-II が生きていて PostgreSQL と繋がっている場合でも、
-上位サーバとのリンクが切れていればサービスを継続できません。
-そのため、watchdog は上位サーバとのリンクが繋がっているかどうかも監視します。
-</p>
-
-<dl>
-<dt><a name="TRUSTED_SERVERS"></a>trusted_servers <span class="version">V3.2 ～</span></dt>
-    <dd>
-    <p>
-    上位接続を確認するための信頼できるサーバリストです。
-    ping の応答が得られる必要があります。
-    "hostA,hostB,hostC ..." のようにカンマで区切って複数のサーバを指定できます。
-    全てのサーバへの ping が失敗した場合、watchdog は pgpool-II に障害が発生したと判断します。
-    そのため、複数のサーバを指定することを推奨します。
-    </p>
-    <p>
-    指定がない場合は上位サーバへの接続監視は行いません。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-
-<dt><a name="PING_PATH"></a>ping_path <span class="version">V3.2 ～</span></dt>
-    <dd>
-    <p>
-    上位サーバへの接続監視に利用する ping コマンドのパスです。
-    "/bin" のようにパスだけを指定します。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-</dl>
-
-<h3>仮想 IP</h3>
-
-<p>
-仮想 IP の制御に関する設定です。
-</p>
-
-<dl>
-<dt><a name="DELEGATE_IP"></a>delegate_IP <span class="version">V3.2 ～</span></dt>
-    <dd>
-    <p>
-    （アプリケーションサーバなど）外部からの接続される pgpool-II の仮想 IP アドレスです。
-    スタンバイからアクティブに切り替わる際、pgpool-II はこの仮想 IP を引き継ぎます。
-    このオプションが空の場合には、仮想 IP は起動されません。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-
-<dt><a name="IF_CMD_PATH"></a>if_cmd_path <span class="version">V3.5 ～</span></dt>
-    <dd>
-    <p>
-    IP アドレス切り替えに利用するコマンドのパスです。
-    "/sbin" のようにパスだけを指定します。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-
-<dt><a name="IF_UP_CMD"></a>if_up_cmd <span class="version">V3.2 ～</span></dt>
-    <dd>
-    <p>
-    仮想 IP を起動するために実行するコマンドです。
-    "ip addr add $_IP_$/24 dev eth0 label eth0:0"
-    のようにコマンドとパラメータを指定します。
-    $_IP_$　は <a href="#DELEGATE_IP">delegate_IP</a> で指定された IP アドレスに置換されます。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-
-<dt><a name="IF_DOWN_CMD"></a>if_down_cmd <span class="version">V3.2 ～</span></dt>
-    <dd>
-    <p>
-    仮想IPを停止するために実行するコマンドです。
-    "ip addr del $_IP_$/24 dev eth0"
-    のようにコマンドとパラメータを指定します。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-
-<dt><a name="ARPING_PATH"></a>arping_path <span class="version">V3.2 ～</span></dt>
-    <dd>
-    <p>
-    IP アドレス切り替え後に ARP リクエストを送信するコマンドのパスです。
-    "/usr/sbin" のようにパスだけを指定します。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-
-<dt><a name="ARPING_CMD"></a>arping_cmd <span class="version">V3.2 ～</span></dt>
-    <dd>
-    <p>
-    IPアドレス切り替え後にARPリクエストを送信するコマンドです。
-    "arping -U $_IP_$ -w 1"
-    のようにコマンドとパラメータを指定します。
-    $_IP_$ は <a href="#DELEGATE_IP">delegate_IP</a> で指定された IP アドレスに置換されます。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-</dl>
-
-<h3>昇格および降格時の振る舞い</h3>
-
-<p>pgpool-II がアクティブ（仮想 IP を保持しているステータス）に昇格した時の振る舞いの設定です。</p>
-<dl>
-
-<dt><a name="CLEAR_MEMQCACHE_ON_ESCALATION"></a>clear_memqcache_on_escalation <span class="version">V3.3 ～</span></dt>
-    <dd>
-    <p>
-    このオプションが on の場合、pgpool-II がアクティブに昇格した時に、共有メモリ上のクエリキャッシュを全て削除します。
-    これにより、旧アクティブと非整合な古いクエリキャッシュが使われることを防止します。
-    <a href="#MEMQCACHE_METHOD">memqcache_method</a> が 'shmem' の場合のみ有効です。
-    デフォルトは on です。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-
-<dt><a name="WD_ESCALATION_COMMAND"></a>wd_escalation_command <span class="version">V3.3 ～</span></dt>
-    <dd>
-    <p>
-    pgpool-II ノードがマスター watchdog に昇格した時に、ここで指定したコマンドが実行されます。
-    </p>
-    <p>
-    コマンドは、仮想 IP が設定されていた場合、それが立ち上がる直前のタイミングで実行されます。
-    </p>
-    </dd>
-
-<dt><a name="WD_DE-ESCALATION_COMMAND"></a>wd_de_escalation_command <span class="version">V3.5 ～</span></dt>
-<dd>
-    <p>
-    pgpool-II watchdog のマスターノードがマスターの責務を辞退し降格するときに、ここで指定したコマンドが実行されます。
-    マスターノードは、そのマスターノードが停止したとき、および、
-    ネットワーク切断やクォーラムが失われたことを検出した時に、マスターから辞任します。
-    </p>
-    <p>
-    コマンドは、仮想 IP が設定されていた場合、それが停止される直前のタイミングで実行されます。
-    </p>
-</dd>
-
-</dl>
-
-<h3>pgpool-II の死活監視</h3>
-
-<p>watchdog は一定時間間隔で pgpool-II の状態のチェック、すなわち死活監視を行います。</p>
-
-<h4>共通設定</h4>
-
-<dl>
-<dt><a name="WD_LIFECHECK_METHOD"></a>wd_lifecheck_method <span class="version">V3.3 ～</span></dt>
-    <dd>
-    <p>
-    死活監視の方法を指定します。指定できる値は 'heartbeat' (デフォルト)、'query'、または 'external' です。
-    </p>
-    <p>
-    'heartbeat' を指定した場合には、監視は「ハートビートモード」で行われます。
-    watchdog は一定間隔でハートビート信号（UDP パケット）を他の pgpool-II へ送信します。
-    また watchdog は他の pgpool-II から送られてくる信号を受信し、これが一定時間以上途絶えた場合には
-    その pgpool-II に障害が発生したと判断します。
-    </p>
-    <p>
-    'query' を指定した場合には、監視は「クエリモード」で行われます。
-    watchdog は監視用のクエリを pgpool-II に発行し、それが成功するかどうかで pgpool-II が生きているかどうかを判断します。
-    </p>
-    <p>
-    <font color="red">注意: クエリモードを使用する場合は、<a href="#NUM_INIT_CHILDREN">num_init_children</a>に
-        十分大きな値を設定して下さい。watchdog 自身も pgpool-II にクライアントとして接続するためです。</font>
-    </p>
-    <p>
-    'external' を指定した場合には、監視は「外部ツールモード」で行われます（<span class="version">V3.5 -</span>）。
-    watchdog は組み込みの死活監視機能を無効にし、ローカルおよびリモートの watchdog ノードの死活監視を外部のシステムに頼ります。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-
-<dt><a name="WD_MONITORING_INTERFACES_LIST"></a>wd_monitoring_interfaces_list <span class="version">V3.5 -</span></dt>
-<dd>
-    <p>
-    watchdog プロセスがネットワークリンクの状態を監視するネットワークデバイス名をカンマ区切りのリストで指定します。
-    リスト中の全てのネットワークインタフェースが（無効化あるいはケーブルを抜かれることで）非アクティブになると、
-    watchdog はネットワークが完全に故障したと見なし自らを停止させませす。
-    空のリスト '' を指定するとネットワークインタフェースの監視が無効になります。
-    'any' を指定すると、ループバック以外の存在する全てのネットワークインタフェースを監視します。
-    デフォルトの値は空リスト '' （監視は無効）です。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-</dd>
-
-<dt><a name="WD_INTERVAL"></a>wd_interval <span class="version">V3.2 ～</span></dt>
-    <dd>
-    <p>
-    死活監視を行う間隔（秒）です。
-    （1 以上の数値）
-    デフォルトの値は 10 です。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-
-<dt><a name="WD_PRIORITY"></a>wd_priority <span class="version">V3.5 ～</span></dt>
-<dd>
-    <p>
-    このパラメータによってローカルの watchdog ノードがマスターに選ばれる優先度を上げることができます。
-    クラスタの初期起動時や古いマスターノードが故障した状況でクラスタがマスターノードの選択を行う際に、wd_priority
-    が高いノードがマスターwatchdog ノードに選ばれます。
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-</dd>
-
-<dt><a name="WD_IPC_SOCKET_DIR"></a>wd_ipc_socket_dir <span class="version">V3.5 ～</span></dt>
-<dd>
-    <p>
-    pgpool-II watchdog の IPC（プロセス間通信）で受け付ける UNIX ドメインソケットが作成されるディレクトリを指定します。
-    デフォルトは <code>'/tmp'</code> です。
-    このソケットが cron ジョブで削除されることのないよう気をつけてください。この値は <code>'/var/run'</code>
-    などのディレクトリに設定することを推奨します。
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-</dd>
-</dl>
-
-<h4>ハートビートモードの設定</h4>
-
-<dl>
-<dt><a name="WD_HEARTBEAT_PORT"></a>wd_heartbeat_port <span class="version">V3.3 ～</span></dt>
-    <dd>
-    <p>
-    ハートビート信号を受信するポート番号を指定します。
-    デフォルトは 9694 です。
-    ハートビートモードの場合のみ有効です。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-
-<dt><a name="WD_HEARTBEAT_KEEPALIVE"></a>wd_heartbeat_keepalive <span class="version">V3.3 ～</span></dt>
-    <dd>
-    <p>
-    ハートビート信号を送信する間隔（秒）を指定します。
-    デフォルトは 2 です。
-    ハートビートモードの場合のみ有効です。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-
-<dt><a name="WD_HEARTBEAT_DEADTIME"></a>wd_heartbeat_deadtime <span class="version">V3.3 ～</span></dt>
-    <dd>
-    <p>
-    このオプションで指定された間隔（秒）の間ハートビート信号が途絶えた場合、その pgpool-II に障害が発生したとみなされます。
-    デフォルトは 30 です。
-    ハートビートモードの場合のみ有効です。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-
-<dt><a name="HEARTBEAT_DESTINATION"></a>heartbeat_destination<font color="red">0</font> <span class="version">V3.3 ～</span></dt>
-    <dd>
-    <p>
-    ハートビート信号の送り先を、ホスト名か IP で指定します。
-    複数の送り先が指定可能です。
-    数値の部分は送り先の番号です。0 からの連番にします。
-    ハートビートモードの場合のみ有効です。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-
-<dt><a name="HEARTBEAT_DESTINATION_PORT"></a>heartbeat_destination_port<font color="red">0</font> <span class="version">V3.3 ～</span></dt>
-    <dd>
-    <p>
-    <a href="#HEARTBEAT_DESTINATION">heartbeat_destinationX</a>に指定したハートビート信号の送り先のポート番号を指定します。
-    通常は <a href="#WD_HEARTBEAT_PORT">wd_heartbeat_port</a> と同じ値を指定します。
-    そのポート番号が使用できないホストや、同じホストで複数の pgpool-II を動作させる場合には、異なる値を指定する必要があります。
-    数値の部分は送り先の番号です。0 からの連番にします。
-    ハートビートモードの場合のみ有効です。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-
-<dt><a name="HEARTBEAT_DEVICE"></a>heartbeat_device<font color="red">0</font> <span class="version">V3.3 ～</span></dt>
-    <dd>
-    <p>
-    <a href="#HEARTBEAT_DESTINATION">heartbeat_destinationX</a>に指定した送り先とのハートビートの送受信に用いる
-    ネットワークデバイス名を指定します。
-    数値の部分は送り先の番号です。デバイス毎に 0 からの連番にします。
-    複数の異なる送り先に同じデバイスを設定することが可能です。
-    ハートビートモードの場合のみ有効です。空文字列が指定された場合には無視されます。
-    また、SO_BINDTODEVICE ソケットオプションを使用しているため、pgpool-II が Linux で root 権限で起動している場合のみ有効です。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-</dl>
-
-<h4>クエリモードの設定</h4>
-
-<dl>
-<dt><a name="WD_LIFE_POINT"></a>wd_life_point <span class="version">V3.2 ～</span></dt>
-    <dd>
-    <p>
-    監視クエリの応答が得られなかった場合のリトライ回数です。
-    （1 以上の数値）
-    デフォルトの値は 3 です。
-    クエリモードの場合のみ有効です。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-
-<dt><a name="WD_LIFECHECK_QUERY"></a>wd_lifecheck_query <span class="version">V3.2 ～</span></dt>
-    <dd>
-    <p>
-    pgpool-II の死活監視のために発行されるクエリです。
-    デフォルトは "SELECT 1" です。
-    クエリモードの場合のみ有効です。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-
-<dt><a name="WD_LIFECHECK_DBNAME"></a>wd_lifecheck_dbname <span class="version">V3.3 ～</span></dt>
-    <dd>
-    <p>
-    監視クエリを送る際の接続先のデータベース名です。
-    デフォルトは 'template1' です。
-    クエリモードの場合のみ有効です。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-
-<dt><a name="WD_LIFECHECK_USER"></a>wd_lifecheck_user <span class="version">V3.3 ～</span></dt>
-    <dd>
-    <p>
-    監視クエリを送る際にデータベースに接続するユーザ名です。
-    デフォルトは 'nobody' です。
-    クエリモードの場合のみ有効です。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-
-<dt><a name="WD_LIFECHECK_PASSWORD"></a>wd_lifecheck_password <span class="version">V3.3 ～</span></dt>
-    <dd>
-    <p>
-    監視クエリを送る際にデータベースに接続するパスワードです。
-    デフォルトでは設定されていません。
-    クエリモードの場合のみ有効です。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-</dl>
-
-<h3>監視対象サーバ</h3>
-<dl>
-<dt><a name="OTHER_PGPOOL_HOSTNAME"></a>other_pgpool_hostname<font color="red">0</font> <span class="version">V3.2 ～</span></dt>
-    <dd>
-    <p>
-    監視対象の pgpool-II サーバのホスト名を指定します。
-    クエリやパケットの送受信の他、watchdog の識別子としても用います。
-    数値の部分は監視対象サーバの通し番号です。
-    監視対象のサーバ毎に 0 からの連番にします。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-
-<dt><a name="OTHER_PGPOOL_PORT"></a>other_pgpool_port<font color="red">0</font> <span class="version">V3.2 ～</span></dt>
-    <dd>
-    <p>
-    監視対象の pgpool-II サーバの pgpool ポート番号を指定します。
-    クエリモード使用時に、<a href="#WD_LIFECHECK_QUERY">wd_lifecheck_query</a> に指定したクエリがこのポートへ送られます。
-    数値の部分は監視対象サーバの通し番号です。
-    監視対象のサーバ毎に 0 からの連番にします。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-
-<dt><a name="OTHER_WD_PORT"></a>other_wd_port<font color="red">0</font> <span class="version">V3.2 ～</span></dt>
-    <dd>
-    <p>
-    監視対象の pgpool-II サーバの watchdog パケット受信ポート番号を指定します。
-    数値の部分は監視対象サーバの番号です。
-    監視対象のサーバ毎に 0 からの連番にします。
-    </p>
-    <p>
-    このパラメータを変更した時には pgpool-II を再起動してください。
-    </p>
-    </dd>
-</dl>
-
-<h2 id="INTEGRATE_EXT_LIFECHECK">外部死活監視ツールとの連携 <span class="version">V3.5 -</span></h2>
-<p>
-pgpool-II watchdog プロセスは他の pgpool-II プロセスとの通信に BSD ソケットを使用しており、
-このソケットはサードパーティシステムでローカルおよびリモートの pgpool-II watchdog
-ノードの死活監視をするために使用することが可能です。
-IPC（プロセス間通信）のための BSD ソケットの名前は、"s.PGPOOLWD_CMD" の後ろの pgpool-II の <a href="WD_PORT">wd_port</a>
-を続けた文字列となります。ソケットファイルは <a href="#WD_IPC_SOCKET_DIR">wd_ipc_socket_dir</a>
-で指定されたディレクトリに置かれます。
-</p>
-<h3 id="Watchdog_IPC_command_packet_format">Watchdog IPC コマンドパケットの書式</h3>
-<dl>
-<p>
-watchdog IPC コマンドパケットは 3 つのフィールドから構成されます。メッセージフィールドの詳細を以下の表に示します。
-</p>
-<table border>
-    <tr class="header"><th>フィールド</th>        <th>型</th>                        <th>説明</th></tr>
-    <tr><th>TYPE</th>        <td>BYTE1</td>                        <td>コマンドのタイプ</td></tr>
-    <tr><th>LENGTH</th>        <td>INT32（ネットワークバイトオーダ）</td>    <td>続くデータの長さ</td></tr>
-    <tr><th>DATA</th>        <td>JSON 形式データ</td>        <td>JSON 形式のコマンドデータ</td></tr>
-</table>
-
-</dl>
-<h3 id="Watchdog_IPC_result_packet_format">Watchdog IPC コマンド結果パケットの書式</h3>
-<dl>
-watchdog IPC コマンド結果パケットは 3 つのフィールドから構成されます。メッセージフィールドの詳細を以下の表に示します。
-<table border>
-    <tr class="header"><th>フィールド</th>        <th>型</th>                        <th>説明</th></tr>
-    <tr><th>TYPE</td>        <td>BYTE1</td>                        <td>コマンドのタイプ</td></tr>
-    <tr><th>LENGTH</td>        <td>INT32（ネットワークバイトオーダ）</td>    <td>続くデータの長さ</td></tr>
-    <tr><th>DATA</td>        <td>JSON 形式データ</td>        <td>JSON 形式のコマンド結果データ</td></tr>
-</table>
-</dl>
-<h3 id="Watchdog_IPC_command_packet_types">Watchdog IPC コマンドパケットのタイプ</h3>
-<dl>
-<p>
-watchdog プロセスに送られる、または watchdog プロセスから返される IPC コマンドパケットの最初のバイトはコマンド、またはコマンド結果のタイプとみなされます。
-有効なタイプとその意味の一覧を以下の表に示します。
-</p>
-<table border>
-    <tr class="header"><th>名前</th>                        <th>バイト値</th>    <th>タイプ</th><th>説明</th></tr>
-    <tr><th>Register for notifications</th>    <td>'0'</td>    <td>コマンド</td> <td>watachdog の通知を受信するための接続を登録するコマンド</td></tr>
-    <tr><th>Node status change</th>            <td>'2'</td>    <td>コマンド</td> <td>watchdog に watchdog ノードの状態変化を通知するコマンド</td></tr>
-    <tr><th>Get nodes list</th>                <td>'3'</td>    <td>コマンド</td> <td>設定された全ての watchdog ノードのリストを取得するコマンド</td></tr>
-    <tr><th>Nodes list data</th>            <td>'4'</td>    <td>結果</td>  <td>設定された全ての watchdog ノードのリストを含む JSON データのパケット</td></tr>
-    <tr><th>Cluster in transition</th>        <td>'7'</td>    <td>結果</td> <td>クラスタ状態が遷移中のためコマンドを処理できない</td></tr>
-    <tr><th>Result BAD</th>                    <td>'8'</td>    <td>結果</td> <td>IPC コマンドが失敗した</td></tr>
-    <tr><th>Result OK</th>                    <td>'9'</td>    <td>結果</td> <td>IPC コマンドが成功した</td></tr>
-
-</table>
-</dl>
-
-<h3 id="external_lifecheck_ipc">外部死活監視のための IPC パケットおよびデータ</h3>
-<dl>
-<p>
-外部の死活監視システムと連携に、IPC メッセージ "Get nodes list('3')", "Nodes list data('4')" および
-"Node status change('2')" が使用できます。
-内部の pgpool の死活監視もまた、同じチャネルとテクニックを使用していることに注意してください。
-</p>
-<h4 id="external_lifecheck_ipc">設定された watchdog ノードのリストの取得</h4>
-<dl>
-<p>
-サードパーティの死活監視システムはデータの長さが 0 の "Get nodes list('3')" タイプのパケットを watchdog IPC ソケットに送り、
-"Node list data('4')" タイプの結果パケットを取得することができます。このパケットは死活監視の対象となる全ての設定された watchdog ノードのリストが JSON 形式で含まれています。
-watchdog ノード全体を表す json は全ての watchdog ノードの配列 "WatchdogNodes" を格納しています。
-各 watchdog json ノードには、各ノードの "ID", "NodeName", "HostName", "DelegateIP", "WdPort" および "PgpoolPort" が格納されます。
-</p>
-<pre>
--- "Nodes list data('4')" に格納される JSON データの例
-
-  {
-    "NodeCount":3,
-    "WatchdogNodes":
-        [
-            {
-                "ID":0,
-                "State":1,
-                "NodeName":"Linux_ubuntu_9999",
-                "HostName":"watchdog-host1",
-                "DelegateIP":"172.16.5.133",
-                "WdPort":9000,
-                "PgpoolPort":9999
-            },
-            {
-                "ID":1,
-                "State":1,
-                "NodeName":"Linux_ubuntu_9991",
-                "HostName":"watchdog-host2",
-                "DelegateIP":"172.16.5.133",
-                "WdPort":9000,
-                "PgpoolPort":9991
-            },
-            {
-                "ID":2,
-                "State":1,
-                "NodeName":"Linux_ubuntu_9992",
-                "HostName":"watchdog-host3",
-                "DelegateIP":"172.16.5.133",
-                "WdPort":9000,
-                "PgpoolPort":9992
-            }
-        ]
-  }
-
--- ID 0 のノードは常にローカルの watchdog ノードのために使用されることに注意
-</pre>
-<p>
-設定された watchdog ノードの情報を取得した後は、外部の死活監視システムは watchdog ノードの死活監視を続けることが可能であり、
-いずれかのノードでなんらかの状態変化を検出した場合には、"Node status change('2')" IPC メッセージを使ってそのことを watchdog に通知することができます。
-そのメッセージ中のデータは、状態が変化したノードの ID（watchdog から WatchdogNodes リストで返されたものと同じであること）と、その新しい状態の
-JSON を含んでなければなりません。
-</p>
-<pre>
--- pgpool-II watchdog に ID 1 のノードの死活監視が失敗したことを通知する JSON の例
-
-  {
-    "NodeID":1,
-    "NodeStatus":1,
-    "Message":"optional message string to log by watchdog for this event"
-  }
-
--- NodeStatus の値の意味は以下の通り
-NODE STATUS DEAD  =  1
-NODE STATUS ALIVE =  2
-</pre>
-
-</dl>
-</dl>
-
-<h2 id="watchdog_restrictions">watchdog の制限事項</h2>
-<ul>
-  <li>
-  クエリモード使用時に、PostgreSQL サーバのダウンや pcp_detach_node の実行により pgpool-II から全ての DB ノードが切り離された場合、
-  watchdog は pgpool-II のサービスがダウンした状態とみなし、watchdog に割り当てられていた仮想 IP は停止されます。
-  そのため、クライアントは仮想 IP を使って pgpool-II への接続することは出来なくなります。
-  これは、アクティブの pgpool-II が複数できてしまう「スプリットブレイン」状況を避けるための仕様です。
-  </li>
-  <li>
-  ダウン状態の pgpool-II へ 実 IP を使った接続はしないでください。ダウン状態の pgpool-II は watchdog からの
-  情報を受け取ることが出来ないため、バックエンドの状態が他のpgpool-II と異なっている場合があります。
-  </li>
-  <li>
-  ダウン状態の pgpool-II はアクティブまたはスタンバイになることはできません。ダウン状態から復帰するためには
-  pgpool-II を再起動する必要があります。
-  </li>
-  <li>
-  アクティブな pgpool-II の停止後、スタンバイ pgpool-II が新しいアクティブに昇格するまでには数秒の時間がかかることに注意してください。
-  これは、アクティブ pgpool-II の停止を他の pgpool-II に通知する前に、仮想 IP が停止されたことの確認を行っているためです。
-  </li>
-</ul>
-
-<p class="top_link"><a href="#Top">△ back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1>PCP コマンド<a name="pcp_command"></a></h1>
-
-<h2>PCP コマンド一覧</h2>
-<p>pgpool-II を操作する UNIX コマンドとして、以下のものがあります。</p>
-<p><font color="red">注意</font>：pgpool-II 3.5 より、全ての PCP コマンドのパラメータ書式が変更されています。</p>
-
-<table border>
-<tr><th><a href="#pcp_node_count">pcp_node_count</a></th>
-    <td>ノード数を取得する</td></tr>
-<tr><th><a href="#pcp_node_info">pcp_node_info</a></th>
-    <td>ノード情報を取得する</td></tr>
-<tr><th><a href="#pcp_watchdog_info">pcp_watchdog_info</a></th>
-    <td>watchdog 情報を取得する <span class="version">V3.3 ～</span></td></tr>
-<tr><th><a href="#pcp_proc_count">pcp_proc_count</a></th>
-    <td>プロセス一覧を取得する</td></tr>
-<tr><th><a href="#pcp_proc_info">pcp_proc_info</a></th>
-    <td>プロセス情報を取得する</td></tr>
-<tr><th><a href="#pcp_pool_status">pcp_pool_status</a></th>
-    <td>pgpool.conf のパラメータ設定値を取得する <span class="version">V3.1 〜</span></td></tr>
-<tr><th><a href="#pcp_detach_node">pcp_detach_node</a></th>
-    <td>ノードを切り離す</td></tr>
-<tr><th><a href="#pcp_attach_node">pcp_attach_node</a></th>
-    <td>ノードを復帰させる</td></tr>
-<tr><th><a href="#pcp_promote_node">pcp_promote_node</a></th>
-    <td>ノードをマスターに昇格させる <span class="version">V3.1 〜</span></td></tr>
-<tr><th><a href="#pcp_stop_pgpool">pcp_stop_pgpool</a></th>
-    <td>pgpool-IIを停止させる</td></tr>
-<tr><th><a href="#pcp_recovery_node">pcp_recovery_node</a></th>
-    <td>マスタノードを使ってノードのデータを再同期、ノード起動させる</td></tr>
-</table>
-
-
-<h2 id="pcp_comand_password">PCP 接続認証</h2>
-
-<p>PCP ユーザ名とパスワードが <code>$prefix/etc</code> ディレクトリ内の <code>pcp.conf</code>
-で宣言されている必要があります。<code>pcp.conf</code> が他の場所にある場合には、pgpool-II
-の起動時に <code>-F</code>  オプションで指定することができます。</p>
-
-<h3 id="password_file">パスワードファイル</h3>
-<p>PCP 接続時にパスワードが指定されなかった場合、ユーザのホームディレクトリに配置された .pcppass
-ファイルか、環境変数 PCPPASSFILE で参照されるファイルに格納されたパスワードが使用可能です。</p>
-<p>このファイルの各行の書式は以下のとおりです：</p>
-
-<pre>
-hostname:port:username:password
-</pre>
-<p>
-（この文字列の行頭に # を付けてからファイルにコピーしておけば備忘録のコメントになります。）
-最初の３つのフィールドはそれぞれリテラル値か、任意のものにマッチする * を指定します。
-現在の接続パラメータにマッチした最初の行のpassword フィールドが使用されます。
-（したがって、ワイルドーカードを使用する場合には、具体的なエントリーの方を先に書きます。）
-エントリーの中に : か \ を含む必要がある場合には、その文字を \ をつかってエスケープしてください。
-ホスト名 localhost はローカルマシンからの TCP と Unix ドメインソケットの両方の接続にマッチします。</p>
-
-<p>.pcppass のパーミッションはグループおよび全ユーザからのアクセスを許してはいけません。
-chmod 0600 ~/.pcppass を実行してください。これよりパーミッションの制限が弱い場合には、
-このファイルは無視されます。</p>
-
-<h2 id="pcp_common_options">共通引数</h2>
-<p>全てのコマンドには共通する引数があります。そのほとんどは認証情報を指定するもので、
-他は冗長出力モードやデバッグなどに関するものです。</p>
-
-<pre>
--ex)
-$ pcp_node_count [-d] 10 localhost 9898 postgres hogehoge
-</pre>
-
-<dl class="options">
-<dt><code>
--h <strong>hostname</strong>, --host=<strong>hostname</strong>
-</code></dt>
-<dd><p>
-pgpool-II が稼働しているホスト名を指定します。
-スラッシュから始まる場合は、Unix ドメインソケットのディレクトリと解釈されます。
-</p></dd>
-
-<dt><code>
--p <strong>port</strong>, --port=<strong>port</strong>
-</code></dt>
-<dd><p>
-PCP ポート番号を指定します。(デフォルト: 9898)
-</p></dd>
-
-<dt><code>
--u <strong>username</strong>, --username=<strong>username</strong>
-</code></dt>
-<dd><p>
-PCP 認証のユーザ名を指定します。(デフォルト: OS のユーザ)
-</p></dd>
-
-<dt><code>
--w, --no-password
-</code></dt>
-<dd><p>
-パスワード入力プロンプトを表示しません。
-もしパスワードが .pcppass ファイルから取得できない場合には接続は失敗します。
-このオプションはバッチジョブやスクリプトなど、パスワード入力が行うユーザいない場合に有用です。</p>
-</p></dd>
-
-<dt><code>
--W, --password
-</code></dt>
-<dd><p>
-パスワード入力プロンプトを表示します。（自動的に選択される動作です）
-</p></dd>
-
-<dt><code>
--d, --debug
-</code></dt>
-<dd><p>
-デバッグメッセージを表示します。
-</p></dd>
-
-<dt><code>
--v, --verbose
-</code></dt>
-<dd><p>
-冗長出力を有効にします。
-</p></dd>
-
-<dt><code>
--V, --version
-</code></dt>
-<dd><p>
-バージョンを表示して終了します。
-</p></dd>
-
-<dt><code>
--?, --help
-</code></dt>
-<dd><p>
-コマンドラインのヘルプを表示して終了します。
-</p></dd>
-</dl>
-
-<h2>情報を取得するコマンド群</h2>
-<p>
-全てのコマンドは、実行した結果が標準出力に表示されます。
-</p>
-
-
-<h3 id="pcp_node_count">pcp_node_count</h3>
-<dl class="options">
-<dt>書式<dt>
-<dd>
-<pre><code>pcp_node_count [options...] </code></pre>
-</dd>
-<dt>説明</dt>
-<dd>
-    <p>pgpool-II の pgpool.conf で定義されたノードの総数を表示します。
-    切り離されているノードの区別はしません。</p>
-</dd>
-<dt>オプション</dt>
-<dd>
-    <p><a href="#pcp_common_options">common options</a> を参照してください。 </p>
-</dd>
-</dl>
-
-<h3><a name="pcp_node_info"></a>pcp_node_info</h3>
-<dl class="options">
-<dt>書式</dt>
-<dd>
-<pre><code>pcp_node_info [options...] [node_id] </code></pre>
-</dd>
-<dt>説明</dt>
-<dd>
-    <p>指定されたノードの情報を表示します。</p>
-</dd>
-<dt>オプション</dt>
-<dd>
-    <dl>
-    <dt><code>-n <strong>node_id</strong>, --node-id=<strong>node_id</strong></code></dt>
-    <dd>
-        <p>情報を表示するバックエンドノードのインデックスを指定します。</p>
-    </dd>
-    <dt>その他</dt>
-    <dd>
-        <p><a href="#pcp_common_options">common options</a> を参照してください。 </p>
-    </dd>
-    </dl>
-</dd>
-
-<dt>出力例</dt>
-<dd>
-<pre>
-$ pcp_node_info -h localhost -U postgres 0
-host1 5432 1 1073741823.500000
-</pre>
-
-<p>結果は以下の順のとおりです。</p>
-<ol>
-<li>ノードのホスト名</li>
-<li>ノードのポート番号</li>
-<li>ステータス</li>
-<li>ロードバランスウェイト</li>
-</ol>
-
-<p>ステータスは [0..3] までの数字で表わされます。各数字の意味は以下のとおりです。</p>
-<ul>
-<li>0 - 初期化時のみに表われる。PCP コマンドで表示されることはない。</li>
-<li>1 - ノード稼働中。接続無し</li>
-<li>2 - ノード稼働中。接続有り</li>
-<li>3 - ノードダウン</li>
-</ul>
-
-<p>ロードバランスウェイトは Normalize されたフォーマットで出力されます。</p>
-
-<p><code>--verbose</code> オプションは出力内容を理解するのに役に立ちます。例：</p>
-
- <pre>
-$ pcp_node_info --verbose -h localhost -U postgres 0
-Hostname: host1
-Port    : 5432
-Status  : 1
-Weight  : 0.5
-</pre>
-
-</dd>
-</dl>
-
-<h3><a name="pcp_watchdog_info"></a>pcp_watchdog_info</h3>
-<dl>
-<dt>書式</dt>
-<dd>
-    <pre><code>pcp_watchdog_info [options...] [watchdog_id]</code></pre>
-</dd>
-
-<dt>説明</dt>
-<dd>
-<p>pgpool-II の pgpool.conf の watchdog セクションで定義された pgpool-II の watchdog ステータスを表示します。</p>
-<p><code>watchdog_id</code> は情報を取得する watchdog ノードのインデックです。
-省略された場合には、クラスタ中の全ての pgpool-II の watchdog ノードのステータスが表示されます。</p>
-<p><code>watchdog_id</code> = 0 はローカルの pgpool-II ノードのために予約されています。
-そのため、リモートの watchdog ノードのインデックスは 1 から始まります。pgpool.conf ではリモート
-watchdog ノードのインデックスは 0 をベースにしていますが、pcp_watchdog_info ではそれが 1 から始まることに注意してください。
-pcp_watchdog_info コマンドで情報を取得する際には、他の watchdog のインデックスに 1 を足す必要があります。
-</p><p>
-例えば、other_pgpool_hostname0 パラメータで定義されている、添字 0 である最初のリモート watchdog
-ノードの情報を取得するには、pcp_watchdog_info で <code>watchdog_id</code> = 1 を指定します。
-</p>
-</dd>
-
-<dt>オプション</dt>
-<dd>
-	<dl class="options">
-	<dt><code>-n <strong>watchdog_id</strong>, --node-id=<strong>watchdog_id</strong></code></dt>
-	<dd>
-		<p>情報を取得する他の pgpool-II のインデックスを指定します。</p>
-		<p>0 の場合ははローカルの watchdog の情報を取得します。</p>
-		<p>省略された場合は、全ての watchdog ノードの情報を取得します。</p>
-	</dd>
-    <dt>その他</dt>
-    <dd>
-        <p><a href="#pcp_common_options">common options</a> を参照してください。 </p>
-    </dd>
-	</dl>
-</dd>
-
-<dt>出力例</dt>
-<dd>
-<pre>
-$ pcp_watchdog_info -h localhost -u postgres
-
-3 NO Linux_host1.localdomain_9991 host1
-
-Linux_host1.localdomain_9991 host1 9991 9001 7 STANDBY
-Linux_host2.localdomain_9992 host2 9992 9002 4 MASTER
-Linux_host3.localdomain_9993 host3 9993 9003 7 STANDBY
-</pre>
-
-<p>結果は以下の順のとおりです。</p>
-<p>最初に出力される行は、watchdog クラスタの情報を示しています:</p>
-<ol>
-<li>クラスタ内の全 watchdog ノード数</li>
-<li>仮想 IP がこのノードで起動しているか？</li>
-<li>マスターノード名</li>
-<li>マスターノードホスト</li>
-</ol>
-
-<p>それ以降は watchdog ノードのリストが出力されます:</p>
-<ol>
-	<li>ノード名</li>
-	<li>ホスト名</li>
-	<li>pgpool ポート番号</li>
-	<li>watchdog ポート番号</li>
-	<li>現在のノードステータス</li>
-	<li>現在のノードステータス名</li>
-</ol>
-</dd>
-
-<dt>verbose モード:</dt>
-<dd>
-<pre>
-$ pcp_watchdog_info -h localhost -v -u postgres
-
-Watchdog Cluster Information
-Total Nodes          : 3
-Remote Nodes         : 2
-Quorum state         : QUORUM EXIST
-Alive Remote Nodes   : 2
-VIP up on local node : NO
-Master Node Name     : Linux_host2.localdomain_9992
-Master Host Name     : localhost
-
-Watchdog Node Information
-Node Name      : Linux_host1.localdomain_9991
-Host Name      : host1
-Delegate IP    : 192.168.1.10
-Pgpool port    : 9991
-Watchdog port  : 9001
-Node priority  : 1
-Status         : 7
-Status Name    : STANDBY
-
-Node Name      : Linux_host2.localdomain_9992
-Host Name      : host2
-Delegate IP    : 192.168.1.10
-Pgpool port    : 9992
-Watchdog port  : 9002
-Node priority  : 1
-Status         : 4
-Status Name    : MASTER
-
-Node Name      : Linux_host3.localdomain_9993
-Host Name      : host3
-Delegate IP    : 192.168.1.10
-Pgpool port    : 9993
-Watchdog port  : 9003
-Node priority  : 1
-Status         : 7
-Status Name    : STANDBY
-
-</pre>
-</dd>
-</dl>
-
-<h3 id="pcp_proc_count">pcp_proc_count</h3>
-<dl>
-<dt>書式</dt>
-<dd>
-    <pre><code>pcp_proc_count [options...] </code></pre>
-</dd>
-<dt>説明</dt>
-<dd><p>pgpool-II の子プロセスのプロセス ID を一覧表示します。複数ある場合は空白文字で区切られます。<p></dd>
-<dt>オプション</dt>
-<dd>
-    <p><a href="#pcp_common_options">common options</a> を参照してください。 </p>
-</dd>
-</dl>
-
-<h3 id="pcp_proc_info">pcp_proc_info</h3>
-<dl>
-<dt>書式</dt>
-<dd>
-    <pre><code>pcp_proc_info [options...] [processid] </code></pre>
-</dd>
-<dt>説明</dt>
-<dd>
-<p>pgpool-II の子プロセス情報を表示します。</p>
-</dd>
-<dt>オプション</dt>
-<dd>
-    <dl class="options">
-    <dt><code>-P <strong>PID</strong>, --process-id=<strong>PID</strong></code></dt>
-    <dd>
-        <p>pgpool-II 子プロセスの PID を指定します。</p>
-    </dd>
-    <dt>その他</dt>
-    <dd>
-        <p><a href="#pcp_common_options">common options</a> を参照してください。 </p>
-    </dd>
-</dd>
-</dd>
-<dt>出力例</dt>
-<pre>
-$ pcp_proc_info 10 localhost 9898 postgres hogehoge 3815
-postgres_db postgres 1150769932 1150767351 3 0 1 14067 1
-postgres_db postgres 1150769932 1150767351 3 0 1 14068 1
-</pre>
-
-<p>結果は以下の順のとおりです。</p>
-<ol>
-<li>接続しているデータベース名</li>
-<li>接続しているユーザ名</li>
-<li>プロセススタート時刻</li>
-<li>コネクション作成時刻</li>
-<li>プロトコルメジャーバージョン</li>
-<li>プロトコルマイナーバージョン</li>
-<li>コネクション使用回数</li>
-<li>PostgreSQL バックエンドプロセスID</li>
-<li>フロントエンドから接続がある場合は 1、そうでなければ 0</li>
-</ol>
-
-<p>
-コネクションがバックエンドに対して張られていない場合、データは表示されません。
-コネクション情報が複数ある場合、複数行に 1 行 1 コネクション情報で表示されます。
-時刻は EPOCH タイムからの秒数で表わされます。
-</p>
-
-<p><code>--verbose</code> オプションは出力内容を理解するのに役に立ちます。例：</p>
-
-<pre>
-$ pcp_proc_info --verbose -U postgres 3815
-Database     : postgres_db
-Username     : postgres
-Start time   : 1150769932
-Creation time: 1150767351
-Major        : 3
-Minor        : 0
-Counter      : 1
-PID          : 1467
-Connected    : 1
-Database     : postgres_db
-Username     : postgres
-Start time   : 1150769932
-Creation time: 1150767351
-Major        : 3
-Minor        : 0
-Counter      : 1
-PID          : 1468
-Connected    : 1
-</pre>
-</dd>
-</dl>
-
-<h3 id="pcp_pool_status">pcp_pool_status <span class="version">V3.1 〜</span></h3>
-<dl>
-<dt>書式</dt>
-<dd>
-    <pre><code>pcp_pool_status [options...]</code></pre>
-</dd>
-<dt>説明</dt>
-<dd>
-<p>pgpool.conf のパラメータ設定値を取得します。</p>
-</dd>
-<dt>オプション</dt>
-<dd>
-    <p><a href="#pcp_common_options">common options</a> を参照してください。 </p>
-</dd>
-<dt>出力例</dt>
-<dd>
-<pre>
-$ pcp_pool_status 10 localhost 9898 postgres hogehoge
-name : listen_addresses
-value: localhost
-desc : host name(s) or IP address(es) to listen to
-
-name : port
-value: 9999
-desc : pgpool accepting port number
-
-name : socket_dir
-value: /tmp
-desc : pgpool socket directory
-
-name : pcp_port
-value: 9898
-desc : PCP port # to bind
-</pre>
-</dd>
-</dl>
-
-<h2>ノード等を操作するコマンド群</h2>
-
-<h3 id="pcp_detach_node">pcp_detach_node</h3>
-<dl>
-<dt>書式</dt>
-<dd>
-    <pre><code>pcp_detach_node [options...] [node_id] [grecefully]</code></pre>
-</dd>
-<dt>説明</dt>
-<dd>
-<p>pgpool-II のノードを切り離します。</p>
-<p>すでにpgpool-IIに接続しているセッションは強制的に切断されます。</p>
-</dd>
-<dt>オプション</dt>
-<dd>
-    <dl class="option">
-    <dt><code>-n <strong>node_id</strong>, --node-id=<strong>node_id</strong></code></dt>
-    <dd>
-        <p>切り離すバックエンドノードのインデックスを指定します。</p>
-    </dd>
-    <dt><code>-g, --gracefully</code></dt>
-    <dd>
-        <p>すべてのクライアントが接続を終了するまでノードを復帰しません。
-        （ただし、<a href="#CLIENT_IDLE_LIMIT_IN_RECOVERY">client_idle_limit_in_recovery</a> が -1
-        あるいは、<a href="#RECOVERY_TIMEOUT">recovery_timeout</a> が設定されている場合を除く）</p>
-    </dd>
-    <dt>その他</dt>
-    <dd>
-        <p><a href="#pcp_common_options">common options</a> を参照してください。 </p>
-    </dd>
-    </dl>
-</dd>
-</dl>
-
-<h3 id="pcp_attach_node">pcp_attach_node</h3>
-<dl>
-<dt>書式</dt>
-<dd>
-    <pre><code>pcp_attach_node [options...] [node_id]</code></pre>
-</dd>
-<dt>説明</dt>
-<dd><p>pgpool-II のノードを復帰させます。</p></dd>
-<dt>オプション</dt>
-<dd>
-    <dl class="options">
-    <dt><code>-n <strong>node_id</strong>, --node-id=<strong>node_id</strong></code></dt>
-    <dd>
-        <p>復帰させるバックエンドノードのインデックスを指定します。</p>
-    </dd>
-    <dt>その他</dt>
-    <dd>
-        <p><a href="#pcp_common_options">common options</a> を参照してください。 </p>
-    </dd>
-    </dl>
-</dd>
-</dl>
-
-<h3 id="pcp_promote_node">pcp_promote_node <span class="version">V3.1 〜</span></h3>
-<dl>
-<dt>書式</dt>
-<dd>
-    <pre><code>pcp_promote_node [options...] [node_id] [gracefully]</code></pre>
-</dd>
-<dt>説明</dt>
-<dd>
-<p>pgpool-II のノードをマスターに昇格させます。これは、マスタースレーブモードで
-ストリーミングレプリケーション構成の場合のみ使用できます。
-このコマンドは実際にPostgreSQLのスタンバイサーバを昇格するわけではないことに注意してください。
-単にpgpool-IIの内部ステータスを変更し、フェイルオーバするだけです。
-ですので、ユーザはこのコマンドを使う際には自分でPostgreSQLのスタンバイを昇格させるようにしてください。
-</p>
-</dd>
-<dt>オプション</dt>
-<dd>
-    <dl class="option">
-    <dt><code>-n <strong>node_id</strong>, --node-id=<strong>node_id</strong></code></dt>
-    <dd>
-        <p>マスターに昇格させるバックエンドノードのインデックスを指定します。</p>
-    </dd>
-    <dt><code>-g, --gracefully</code></dt>
-    <dd>
-        <p>すべてのクライアントが接続を終了するまでノードを復帰しません。
-        （ただし、<a href="#CLIENT_IDLE_LIMIT_IN_RECOVERY">client_idle_limit_in_recovery</a> が -1
-        あるいは、<a href="#RECOVERY_TIMEOUT">recovery_timeout</a> が設定されている場合を除く）</p>
-    </dd>
-    <dt>その他</dt>
-    <dd>
-        <p><a href="#pcp_common_options">common options</a> を参照してください。 </p>
-    </dd>
-    </dl>
-</dd>
-</dl>
-
-<h3 id="pcp_stop_pgpool">pcp_stop_pgpool</h3>
-<dl>
-<dt>書式</dt>
-<dd>
-    <pre><code>pcp_stop_pgpool [options...] [mode]</code></pre>
-</dd>
-<dt>説明</dt>
-<dd>
-    <p>pgpool-IIを指定されたモードでシャットダウンします。</p>
-</dd>
-<dt>オプション</dt>
-<dd>
-    <dl class="options">
-    <dt><code>-m <strong>mode</strong>, --mode=<strong>mode</strong></code></p>
-    <dd>
-        <p>シャットダウンモードを指定します。指定できるモードは以下のとおりです。</p>
-        <ul>
-            <li>s, smart        : smart モード</li>
-            <li>f, fast         : fast モード</li>
-            <li>i, immediate    : immediate モード</li>
-        </ul>
-        <p>
-        ※ 現在は fast モードと immediate シャットダウンの処理に区別はありません。
-        命令を送った時点でクライアントがいる・いないに関わらずシャットダウン処理を即座に行います。
-        </p>
-    </dd>
-    <dt>その他</dt>
-    <dd>
-        <p><a href="#pcp_common_options">common options</a> を参照してください。 </p>
-    </dd>
-    </dl>
-</dd>
-</dl>
-
-<h3 id="pcp_recovery_node">pcp_recovery_node</h3>
-<dl>
-<dt>書式</dt>
-<dd>
-    <pre><code>pcp_recovery_node [options...] [node_id] </code></pre>
-</dd>
-<dt>説明</dt>
-<dd><p>
-pgpool-II のノードをデータを再同期させた上で復帰させます。
-</p></dd>
-<dt>オプション</dt>
-<dd>
-    <dl class="options">
-    <dt><code>-n <strong>node_id</strong>, --node-id=<strong>node_id</strong></code></dt>
-    <dd>
-        <p>バックエンドノードのインデックスを指定します。</p>
-    </dd>
-    <dt>その他</dt>
-    <dd>
-        <p><a href="#pcp_common_options">common options</a> を参照してください。</p>
-    </dd>
-    </dl>
-</dd>
-</dl>
-
-<p class="top_link"><a href="#Top">△ back to top</a></p>
-
-<h1 id="pgpool_adm">pool_adm</h1>
-<p>
-  pgpoo_adm はSQLからPCPコマンド(実際にはpcpライブラリ)にアクセスすることを可能にするextensionです。
-  pgpool_admは、下の図に示すように、foreign data wrapper を使っています。
-</p>
-
-<p><img src="pgpool_adm.png" alt="Data flow in pgpool_adm" hight=70% width=70%></p>
-
-<p>
-  関数は、pgpool-II経由で呼び出すことも(1)、PostgreSQL直接で呼び出すこともできます(2)。
-  (1)の場合では、pgpool-IIはユーザからのクエリを受け付け(1)、PostgreSQLに転送します(3)。
-  PostgreSQLはpgpool-IIに接続し(5)、pgpool-IIはPostgreSQLに結果の値を返します(3)。
-  PostgreSQLは結果をpgpool-IIに返却し(5)、pgpool-IIはデータをユーザに転送します(6)。
-</p>
-<p>
-  (2)のケースでは、PostgreSQLはクエリをユーザから受け付けます(2)。
-  PostgreSQLはpgpool-IIに接続し(5)、pgpool-IIはPostgreSQLに結果の値を返します(3)。
-  PostgreSQLははユーザに結果を返します(6)。
-</p>
-<p>
-  pgpool_admの呼び出し方法は2つあります。最初の形式は、pgpool-IIのホスト名(またはIPアドレス)、PCPポート番号、PCPユーザ名、パスワード、そして他のパラメータを渡します。
-</p>
-<p>
-  後者の形式では、pgpool-IIのサーバ名が必要です。
-  サーバ名は「CREATE FOREIGN SERVER」コマンドであらかじめ登録しておかなければなりません。
-  PCPポート番号は9898にハードコードされています。
-  PCPユーザ名はPostgreSQLのユーザ名と同じと見なされます。
-  パスワードは、$HOME/.pcppassから取得されます。
-</p>
-
-<h2>Installing pgpool_adm</h2>
-<p>
-pgpool_admはextensionなので、すべてのPostgreSQLサーバにインストールしておかなければなりません。
-</p>
-<p>
-<pre>
-$ cd src/sql/pgpool_adm
-$ make
-$ make install
-</pre>
-</p>
-<p>
-次に下のSQLコマンドをアクセスしたいデータベース全てで実行します。
-</p>
-<p>
-<pre>
-$ psql ...
-$ CREATE EXTENSION pgpool_adm
-</pre>
-</p>
-
-<h2>pgpool_adm functions list</h2>
-<table border>
-<tr><th><a href="#func_pcp_node_info">pcp_node_info</a></th>
-  <td>ノード情報を取得します</td></tr>
-<tr><th><a href="#func_pcp_pool_status">pcp_pool_status</a></th>
-    <td>pgpool.confのパラメータを取得します</td></tr>
-<tr><th><a href="#func_pcp_node_count">pcp_node_count</a></th>
-  <td>ノード数を取得します</td></tr>
-<tr><th><a href="#func_pcp_attach_node">pcp_attach_node</a></th>
-  <td>pgpool-IIにノードをアタッチします</td></tr>
-<tr><th><a href="#func_pcp_detach_node">pcp_detach_node</a></th>
-  <td>pgpool-IIからノードをデタッチします</td></tr>
-</table>
-
-<h3 id="func_pcp_node_info">pcp_node_info</h3>
-<dl>
-<dt>形式:</dt>
-<dd>
-  <pre><code>pcp_node_info(integer node_id, text host, integer port, text username, text password, OUT status text, OUT weight float4) returns record</code></pre>
-  <pre><code>pcp_node_info(integer node_id, text pcp_server, OUT status text, OUT weight float4) returns record</code></pre>
-</dd>
-
-<dt>説明:</dt>
-<dd>
-  <p>ノード情報を取得します。
-  詳細は<a href="#pcp_node_info">pcp_node_infoコマンド</a>を参照してください。</p>
-  <p>
-    実行例を示します。
-<pre>
-test=# SELECT * FROM pcp_node_info(0,'',11001,'t-ishii','t-ishii');
- host | port  |      status       | weight
-------+-------+-------------------+--------
- /tmp | 11002 | Connection in use |      0
-(1 row)
-</pre>
-  </p>
-</dd>
-
-<dt>引数:</dt>
-<dd>
-  <dl class="options">
-  <dt><code>node_id</strong></code></dt>
-<dd>
-  <p>バックエンドノードの番号</p>
-
-  <dt><code>host</strong></code></dt>
-  <p>PCPが稼働中のホスト名とIPアドレス</p>
-
-  <dt><code>port</strong></code></dt>
-  <p>PCPサーバがリッスンしているポート番号です</p>
-
-  <dt><code>username</strong></code></dt>
-  <p>PCPサーバにアクセスするためのユーザ名</p>
-
-  <dt><code>password</strong></code></dt>
-  <p>PCPサーバにアクセスするためのパスワード</p>
-
-  <dt><code>pcp_server</strong></code></dt>
-  <p>PCPサーバのforeign server名</p>
-
-</dd>
-
-</dd>
-</dl>
-</h3>
-
-<h3 id="func_pcp_pool_status">pcp_pool_status</h3>
-<dl>
-<dt>形式:</dt>
-<dd>
-  <pre><code>pcp_pool_status(text host, integer port, text username, text password) returns record</code></pre>
-  <pre><code>pcp_pool_status(text pcp_server) returns record</code></pre>
-</dd>
-
-<dt>説明:</dt>
-<dd>
-  <p>pgpool.confのパラメータを取得します。
-  See <a href="#pool_status">pool_status</a> for more details.</p>
-  <p>
-    実行例を示します。
-<pre>
-test=# SELECT * FROM pcp_pool_status('localhost',11001,'t-ishii','t-ishii') WHERE item ~ 'backend.*0';
-          item           |                     value                      |          description
--------------------------+------------------------------------------------+-------------------------------
- backend_hostname0       | /tmp                                           | backend #0 hostname
- backend_port0           | 11002                                          | backend #0 port number
- backend_weight0         | 0.500000                                       | weight of backend #0
- backend_data_directory0 | /home/t-ishii/work/pgpool-II/current/aaa/data0 | data directory for backend #0
- backend_status0         | 2                                              | status of backend #0
- backend_flag0           | ALLOW_TO_FAILOVER                              | backend #0 flag
-(6 rows)
-</pre>
-  </p>
-</dd>
-
-<dt>引数:</dt>
-<dd>
-  <dl class="options">
-<dd>
-  <dt><code>host</strong></code></dt>
-  <p>PCPが稼働中のホスト名とIPアドレス</p>
-
-  <dt><code>port</strong></code></dt>
-  <p>PCPサーバがリッスンしているポート番号</p>
-
-  <dt><code>username</strong></code></dt>
-  <p>PCPサーバにアクセスするためのユーザ名</p>
-
-  <dt><code>password</strong></code></dt>
-  <p>PCPサーバにアクセスするためのパスワード</p>
-
-  <dt><code>pcp_server</strong></code></dt>
-  <p>PCPサーバのforeign server名</p>
-
-</dd>
-
-</dd>
-</dl>
-</h3>
-
-<h3 id="func_pcp_node_count">pcp_node_node_count</h3>
-<dl>
-<dt>形式:</dt>
-<dd>
-  <pre><code>pcp_node_count(integer node_id, text host, integer port, text username, text password, OUT node_count integer) returns integer</code></pre>
-  <pre><code>pcp_node_count(integer node_id, OUT node_count integer) returns record</code></pre>
-</dd>
-
-<dt>説明:</dt>
-<dd>
-  <p>ノード数を取得します。
-  詳細は<a href="#pcp_node_count">pcp_node_countコマンド</a>を参照してください。</p>
-  <p>
-    実行例を示します。
-<pre>
-test=# SELECT * FROM pcp_node_count('localhost',11001,'t-ishii','t-ishii');
- node_count
-------------
-          2
-(1 row)
-</pre>
-  </p>
-</dd>
-
-<dt>引数:</dt>
-<dd>
-  <dl class="options">
-
-<dd>
-  <dt><code>host</strong></code></dt>
-  <p>PCPが稼働中のホスト名とIPアドレス</p>
-
-  <dt><code>port</strong></code></dt>
-  <p>PCPサーバがリッスンしているポート番号です</p>
-
-  <dt><code>username</strong></code></dt>
-  <p>PCPサーバにアクセスするためのユーザ名</p>
-
-  <dt><code>password</strong></code></dt>
-  <p>PCPサーバにアクセスするためのパスワード</p>
-
-  <dt><code>pcp_server</strong></code></dt>
-  <p>PCPサーバのforeign server名</p>
-
-</dd>
-
-</dd>
-</dl>
-</h3>
-
-<h3 id="func_pcp_attach_node">pcp_attach_node</h3>
-<dl>
-<dt>形式:</dt>
-<dd>
-  <pre><code>pcp_attach_node(integer node_id, text host, integer port, text username, text password, OUT node_attached boolean) returns boolean</code></pre>
-  <pre><code>pcp_attach_node(integer node_id, text pcp_server, OUT node_attached boolean) returns boolean</code></pre>
-</dd>
-
-<dt>説明:</dt>
-<dd>
-  <p>attaches a node to pgpool-II.
-  詳細は<a href="#pcp_attach_node">pcp_attach_nodeコマンドを</a>参照してください。</p>
-  <p>
-    実行例を示します。
-<pre>
-test=# SELECT * FROM pcp_attach_node(1,'localhost',11001,'t-ishii','t-ishii');
- node_attached
----------------
- t
-(1 row)
-</pre>
-  </p>
-</dd>
-
-<dt>説明:</dt>
-<dd>
-  <dl class="options">
-  <dt><code>node_id</strong></code></dt>
-  <p>バックエンドノードの番号</p>
-
-  <dt><code>host</strong></code></dt>
-  <p>PCPが稼働中のホスト名とIPアドレス</p>
-
-  <dt><code>port</strong></code></dt>
-  <p>PCPサーバがリッスンしているポート番号</p>
-
-  <dt><code>username</strong></code></dt>
-  <p>PCPサーバにアクセスするためのユーザ名</p>
-
-  <dt><code>password</strong></code></dt>
-  <p>PCPサーバにアクセスするためのパスワード</p>
-
-  <dt><code>pcp_server</strong></code></dt>
-  <p>PCPサーバのforeign server名</p>
-
-</dd>
-
-</dd>
-</dl>
-</h3>
-
-<h3 id="func_pcp_detach_node">pcp_detach_node</h3>
-<dl>
-<dt>形式:</dt>
-<dd>
-  <pre><code>pcp_detach_node(integer node_id, boolean gracefully, text host, integer port, text username, text password, OUT node_detached boolean) returns boolean</code></pre>
-  <pre><code>pcp_detach_node(integer node_id, boolean gracefully, text pcp_server, OUT node_detached boolean) returns boolean</code></pre>
-</dd>
-
-<dt>説明:</dt>
-<dd>
-  <p>Detaches a node to pgpool-II and initiate fail over.
-  See <a href="#pcp_detach_node">pcp_detach_node</a> for more details.</p>
-  <p>
-    実行例を示します。
-<pre>
-test=# SELECT * FROM pcp_detach_node(1, 'false', 'localhost',11001,'t-ishii','t-ishii');
- node_detached
----------------
- t
-(1 row)
-</pre>
-  </p>
-</dd>
-
-<dt>引数:</dt>
-<dd>
-  <dl class="options">
-  <dt><code>node_id</strong></code></dt>
-  <p>バックエンドノードの番号</p>
-
-  <dt><code>gracefully</strong></code></dt>
-  <p>もしtrueなら、pgpool-IIのすべてのセッションが切断されるまで待ちます。
-    実際には、この引数にtrueをセットするのはおすすめできません。
-    なぜなら、このSQLの結果を待っているセッション自体が終わらないからです。
-    このパラメータはfalseにすることを強くおすすめします。
-  </p>
-
-  <dt><code>host</strong></code></dt>
-  <p>PCPが稼働中のホスト名とIPアドレス</p>
-
-  <dt><code>port</strong></code></dt>
-  <p>PCPサーバがリッスンしているポート番号です</p>
-
-  <dt><code>username</strong></code></dt>
-  <p>PCPサーバにアクセスするためのユーザ名</p>
-
-  <dt><code>password</strong></code></dt>
-  <p>PCPサーバにアクセスするためのパスワード</p>
-
-  <dt><code>pcp_server</strong></code></dt>
-  <p>PCPサーバのforeign server名</p>
-
-</dd>
-
-</dd>
-</dl>
-</h3>
-
-<p class="top_link"><a href="#Top">△ back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1><a name="troubleshooting"></a>トラブルシューティング</h1>
-<p>
-この章では、pgpool-IIを運用中に直面しやすい障害と、その対策方法をケース別に説明します。
-</p>
-
-<dl>
-<dt id="health_check_failed">health check failed</dt>
-    <dd>
-    <p>
-    ヘルスチェックでpgpool-IIがDBノードの障害を検出しました。
-    </p>
-<pre>
-2010-07-23 16:42:57 ERROR: pid 20031: health check failed. 1 th host foo at port 5432 is down
-2010-07-23 16:42:57 LOG:   pid 20031: set 1 th backend down status
-2010-07-23 16:42:57 LOG:   pid 20031: starting degeneration. shutdown host foot(5432)
-2010-07-23 16:42:58 LOG:   pid 20031: failover_handler: set new master node: 0
-2010-07-23 16:42:58 LOG:   pid 20031: failover done. shutdown host foo(5432)
-</pre>
-    <p>
-    このログは、DBノード1(ホスト名 foo)がダウンして切り離され、
-    新しくDBノード0がマスタとして扱われ出したことを示しています。
-    DBノード1をチェックし、異常原因を取り除いた後に、可能であればオンラインリカバリ機能を使っ
-    てDBノード1を復帰させてください。
-    </p>
-    </dd>
-
-<dt id="failed_to_read_kind_from_frontend">failed to read kind from frontend</dt>
-    <dd>
-<pre>
-2010-07-26 18:43:24 LOG:   pid 24161: ProcessFrontendResponse: failed to read kind from frontend. frontend abnormally exited
-</pre>
-    <p>
-    pgpool-IIから見てクライアントが突然セッションを切断した際にこのようなログが残ります。
-    原因としては、アプリケーションのバグ、アプリケーションが強制終了された、
-    やネットワークの一時的な障害が考えられます。
-    このログが出ても、DBが壊れるとか一貫性がなくなるような問題は起きませんが、
-    継続してこのログが出力されるようであれば、アプリケーションやネットワークの障害を調査することをおすすめします。
-    </p>
-    </dd>
-
-<dt id="kind_mismatch">kind mismatchエラー</dt>
-    <dd>
-    <p>
-    レプリケーションモードで運用している場合に出ることがあるエラーです。
-    </p>
-<pre>
-2010-07-22 14:18:32 ERROR: pid 9966: kind mismatch among backends. Possible last query was: "FETCH ALL FROM c;" kind details are: 0[T] 1[E: cursor "c" does not exist]
-</pre>
-    <p>
-    pgpool-IIは、SQLコマンドを各DBノードに送信したら、各DBノードから同じレスポンスが返ってくることを期待します。
-    このエラーは、異なるレスポンスが返ってきたことを示します。
-    Possible last query was:のあとに、このエラーを返す原因となった問い合わせのSQL文が表示されます。
-    そのあとで、各DBノードからのレスポンスの種類と、レスポンスがエラーの場合は、
-    PostgreSQLのエラーメッセージが表示されます。
-    ここでは、"0[T]"により、0番目のDBノードが"T"(行情報の開始)という応答を返したこと、
-    一方"1[E"で、DBノード1がエラーを返したとこと、そのエラーメッセージは
-    「cursor "c" does not exist」であったことがわかります。
-    <p>
-    注意: このエラーは、マスタースレーブモードでも出ることがあります。
-    たとえば、SETコマンドは、各セッションの状態を同じにするために、基本的にすべてのDBノードに送信されるからです。
-    </p>
-    <p>
-    データベースを調べて原因を特定し、もしDBの同期が崩れているようであれば、
-    オンラインリカバリを使って正しいデータと同期させてください。
-    </p>
-    </dd>
-
-<dt id="difference_of_number">pgpool detected difference of the number of inserted, updated or deleted tuples</dt>
-    <dd>
-    <p>
-    レプリケーションモードにおいて、pgpool-IIが、DBノード間でINSERT/UPDATE/DELETEが返す結果行の違いを検出しました。
-    </p>
-<pre>
-2010-07-22 11:49:28 ERROR: pid 30710: pgpool detected difference of the number of inserted, updated or deleted tuples. Possible last query was: "update t1 set i = 1;"
-2010-07-22 11:49:28 LOG:   pid 30710: ReadyForQuery: Degenerate backends: 1
-2010-07-22 11:49:28 LOG:   pid 30710: ReadyForQuery: Affected tuples are: 0 1
-</pre>
-    <p>
-    この例では、update t1 set i = 1によって更新された行数が、DBノードで異なっています。
-    また、次の行では、DBノード1を切り離したこと、更にDBノード0での結果行数が0だったのに対して、DBノード1では、1行だったことを表しています。
-    </p>
-    <p>
-    正しくないデータを持っていると思われるDBノードを停止し、オンラインリカバリを使って
-    正しいデータと同期させてください。
-    </p>
-    </dd>
-</dl>
-
-<p class="top_link"><a href="#Top">△ back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1>制限事項<a name="restriction"></a></h1>
-<p>
-<h2>PostgreSQLの機能</h2>
-<ul>
-    <li>pg_terminate_backend()でバックエンドを終了させるとフェイルオーバしてしまいます。
-        これは、PostgreSQLがpostmasterをシャットダウンしたときと同じメッセージをpgpoolに送るためです。
-        今のところ対応方法はないので、この関数を使わないようにしてください。
-    </li>
-</ul>
-
-<h2><a name="md5"></a>認証・アクセス制御方式</h2>
-<p>
-<ul>
-    <li>レプリケーションモードまたマスタ/スレーブモード時にはtrust, reject, clear
-        text password, pam, 認証方式だけが利用できます。
-        crypt認証は利用できません。
-        md5認証に関しては、PostgreSQLに該当ユーザをmd5認証付でPostgreSQLに登録し、
-        次にpgpoolに付属するpg_md5コマンドを使って、pool_passwdという認証ファイルを作成することにより
-        利用できるようになります。
-        pool_passwdは認証ファイルのデフォルトのファイル名です。
-        ファイル名は<a href="#POOL_PASSWD">pool_passwd</a>で変更することができます。
-        <ol>
-        <li>DBユーザのアカウントでログインし、"pg_md5 --md5auth パスワード"
-            または "pg_md5 --md5auth --username=ユーザ名 パスワード" を実行します。
-        </li>
-        <li>md5により暗号化されたユーザ名とパスワードがpool_passwdに登録されます。
-            pool_passwdがまだ存在しなければ、pgpool.confと同じディレクトリ内に作成されます。
-        </li>
-        <li>pool_passwdのフォーマットは、"ユーザ名:パスワード"となっています。
-        </li>
-        <li>pool_hba.confにmd5認証のエントリを作成します。
-            pool_hba.confについては、<a href="#hba">クライアント認証(HBA)のためのpool_hba.conf設定方法</a>
-            を参照してください。
-        </li>
-        <li>注意事項: pool_passwdに登録するパスワードは、PostgreSQLに登録したパスワードと
-            完全に同じでなければなりません。
-        </li>
-        <li>pool_passwdとPostgreSQLのmd5パスワードを変更したら、pgpool reload を実行してください。
-            pgpool-II 3.1またはそれよりも以前のバージョンでは、pgpool-IIの再起動が必要です。
-        </li>
-    </ol>
-
-    <li>それ以外のモードでは、trust, reject, clear text password, pam, crypt, md5認証方式だけが利用できます。
-    </li>
-    </ul>
-
-<h2 id="temp_table_in_master_slave_mode">一時テーブルの扱い</h2>
-<p>
-制限対象:マスタースレーブモード
-</p>
-
-<p>
-一時テーブルの作成、更新は常にマスタ(primary)で行なわれます。
-一時テーブルの検索も、pgpool-II 3.0以降では、マスタで行なわれるので、
-一時テーブルを使っているかどうかを意識する必要はありません。
-ただし、文字列として一時テーブル名をSELECTの中で使っている場合は一時テーブルかどうかの確認のしようがないので、
-負荷分散されてしまい、その一時テーブルが見つからないか、
-もしくは同じ名前の別のテーブルを検索してしまうことになります。
-そのような問い合わせは避けるか、/*NO LOAD BALANCE*/のコメントを挿入してください。
-</p>
-<pre>
-SELECT 't1'::regclass::oid;
-</pre>
-
-<p>
-ちなみに、psqlの\dコマンドのように、システムカタログを問い合わせる中で
-文字列としてのテーブル名を使っている場合は、pgpool-II 3.0以降ではマスタで検索が行なわれるので、問題になりません。
-なぜなら、システムカタログへの検索は常にマスタで行なわれるからです。
-</p>
-
-<h2 id="caution_in_replication_mode">レプリケーションモードで注意が必要な関数など</h2>
-<p>
-pgpool-IIでは同じ問い合わせを送っても異なる結果を返すようなデータ、
-たとえば乱数やトランザクションID、OIDのようなものに関してはレプリケーションはしますが、
-2台のホストでまったく同じ値がコピーされる保証はありません。
-</p>
-<p>
-シリアル型に関しては、insert_lockを有効にしておけばテーブルロックを利用して同期が取られます。
-シーケンスを扱う関数をSELECT setval()、SELECT nextval()で呼び出している場合は
-自動的にレプリケーションされるので同期が取れます。
-</p>
-<p>
-pgpool-II 2.3以降では、テーブルのデフォルト値での利用も含め、
-CURRENT_TIMESTAMP, CURRENT_DATE, now()は、自動的にマスタ側から取得した時刻値に置き換えることによって
-レプリケーションできるようになっています。
-ただし、以下の点に注意してください。
-</p>
-
-<ul>
-    <li>
-        pgpool-II 3.1より前のバージョンではDEFAULTにタイムスタンプを返す式が
-        含まれているかどうかの判定は正確ではありません。例えば
-<pre>
-CREATE TABLE rel1(
-  d1 date DEFAULT CURRENT_DATE + 1
-)
-</pre>
-    のようなものも現在のタイムスタンプとして書き換えを行います。
-    pgpool-II 3.1以降では、拡張プロトコルとPREPARE以外の場合にこの点が改善されており、
-    上記の例にあるような例も正しく処理されます(つまり、デフォルト値として明日の日付がセットされます)。
-    </p>
-    <p>
-    なお、列の定義が、
-    </p>
-<pre>
-foo bigint default (date_part('epoch'::text,('now'::text)::timestamp(3) with time zone) * (1000)::double precision)
-</pre>
-    <p>
-    のように、データ型が日付、時刻以外になっている場合は書き換えは行ないません。
-    </p>
-    </li>
-
-<li>INSERT ... SELECTでは、列のDEFAULTに対する書き換えを行いません。例えば、
-<pre>
-CREATE TABLE rel1(
-  c1 int,
-  c2 timestamp default now()
-)
-</pre>
-    の時、
-<pre>
-INSERT INTO rel1(c1) VALUES(1)
-</pre>
-    は
-<pre>
-INSERT INTO rel1(c1, c2) VALUES(1, '2009-01-01 23:59:59.123456+09')
-</pre>
-    のように書き換えられますが
-<pre>
-INSERT INTO rel1(c1) SELECT 1
-</pre>
-    は書き換えられません。
-    </li>
-</ul>
-
-<p>
-PostgreSQL 8.2かそれより前のPostgreSQLをお使いの場合、
-CREATE TEMP TABLEで作成されたテーブルはフロントエンドがセッションを終了しても削除されません。
-これは、コネクションプールの効果でバックエンドから見るとセッションが継続しているように見えるからです。
-セッションの終了時に明示的にDROP TABLEするか、トランザクションブロックの中で
-CREATE TEMP TABLE ... ON COMMIT DROPをお使い下さい。
-</p>
-<p>
-PostgreSQL 8.3以降では、reset_query_listにDISCARD ALLを指定すれば自動的に削除されるので問題ありません。
-</p>
-
-<h2 id="ng_queries">クエリについて</h2>
-<p>
-pgpool-II では扱うことができないクエリについて説明します。
-</p>
-
-<h3 id="ng_multibyte_chars">マルチバイト文字について</h3>
-<p>
-制限対象:全モード
-</p>
-<p>
-現在の実装では、マルチバイト文字の変換処理を行いません。
-クライアントエンコーディング、バックエンドノードのサーバエンコーディングを一致させるようにしてください。
-</p>
-
-<h3 id="ng_multi_statement">マルチステートメント</h3>
-<p>
-制限対象:全モード
-</p>
-<p>
-マルチステートメント(';' で区切って複数の文をまとめた SQL)を pgpool が
-正しく処理することができません。必ず文を分けて送信してください。
-</p>
-<p>
-なお、psql を使って pgpool に接続した場合は、psql 内部でマルチステートメントを分解し、
-1 つずつ送信するので、実際には問題になりません。
-</p>
-
-<h2>ビルドに必要な環境</h2>
-
-<h3>libpq</h3>
-<p>
-pgpool-II では libpq をリンクします。libpq のバージョンは 2.0 の場合、
-configure に失敗します。必ず libpq 3.0 以降(PostgreSQL 7.4以降) をリンクするよ
-うにしてください。
-</p>
-
-<p class="top_link"><a href="#Top">△ back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1 id="release">リリースノート</h1>
-
-<ul class="flat_ul">
-<li><a href="#release3.5.x">V3.5.x</a></li>
-<li><a href="#release3.4.x">V3.4.x</a></li>
-<li><a href="#release3.3.x">V3.3.x</a></li>
-<li><a href="#release3.2.x">V3.2.x</a></li>
-<li><a href="#release3.1.x">V3.1.x</a></li>
-<li><a href="#release3.0.x">V3.0.x</a></li>
-<li><a href="#release2.3.x">V2.3.x</a></li>
-<li><a href="#release2.2.x">V2.2.x</a></li>
-<li><a href="#release2.1.x">V2.1.x</a></li>
-<li><a href="#release2.0.x">V2.0.x</a></li>
-<li><a href="#release1.3.x">V1.3.x</a></li>
-<li><a href="#release1.2.x">V1.2.x</a></li>
-<li><a href="#release1.1.x">V1.1.x</a></li>
-<li><a href="#release1.0.x">V1.0.x</a></li>
-</ul>
-
-<!-- ================================================================================ -->
-<!-- 3.5                                                                              -->
-<!-- ================================================================================ -->
-<hr><a name="release3.5.x"></a>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.5.0"></a>3.5.0 (ekieboshi) 2016/01/29</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<p>
-このバージョンは 3.5 系列の最初の版で、3.4 系からの「メジャーバージョンアップ」にあたります。
-</p>
-
-<h3>互換性のない変更</h3>
-<ul>
-    <li>パラレルクエリモードのコードが削除されました。(Yugo Nagata)
-     <p>
-      これは、パラレルクエリモードのユーザが少ない割に維持に手間がかかるためです。
-      また、システムDBに関するコードも削除されました。
-      これらはパラレルクエリモードと古いオンディスクのクエリキャッシュででしか使用されていなかったためです。
-     </p>
-    </li>
-
-    <li>パラメータ "ifconfig_path" が"<a href=#IF_CMD_PATH>if_cmd_path</a>"に名前が変更になりました。(Yugo Nagata)
-     <p>
-     ifconfig が非推奨になり現在では ip コマンドがデフォルトで使われており、ifconfig_path がパラメータ名として不適切になったためです。
-     </p>
-    </li>
-    <li>pcp コマンド引数の文法が変更されました。(Muhammad Usama)</li>
-    <li><a href="#pcp_watchdog_info">pcp_watchdog_info</a>の出力とパラメータの意味が変更されました。
-      (Muhammad Usama)
-    <p>
-    このコマンドはクラスタ中の全ての pgpool-II ノードの watchdog 情報を表示するよう改善されました。
-    それに伴い、ノードインデックスを指定するパラメータの意味が変更され、0 が最初のリモート pgpool-II
-    ノードではなくローカル pgpool-II ノードを意味するようになりました。</p>
-    </li>
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h3 id="3.5_new_features">新機能</h3>
-
-<ul>
-<li>新しいパラメータ <a href="#SERIALIZE_ACCEPT">serialize_accept</a> が追加されました。(Tatsuo Ishii)
-<p>
-クライアントからの接続を受け付ける際に accept() の呼び出しをシリアライズするかどうかを指定します。
-デフォルトはoffです(シリアライズしません)で、これは pgpool-II 3.4 以前と同じ挙動です。
-このパラメータがoffの場合、カーネルはすべてのpgpool-II子プロセスを起こして accept() を実行させます。
-そして子プロセスのうちひとつだけが実際に接続を受け付けます。
-問題は、ここで多くの子プロセスが一度に起こされるため、重いコンテキストスイッチングが起こり、性能に影響がでることです。
-この現象は「thundering herd problem」と呼ばれる古典的な問題です。
-serialize_accept を有効にすることにより、pgpool-II子プロセスのうちひとつだけが起こされて accept() を実行するようになり、この問題は回避されます
-</p>
-</li>
-<li>
-PostgreSQL 9.5 のパーサを取り込みました。(Yugo Nagata)
-<p>これにより、pgpool-II は PostgreSQL 9.5 で導入された新しい構文を理解可能です。
-とくに GROUPING SET、CUBE、ROLLUP、そして TABLESAMPLE の負荷分散とクエリキャッシュ（TABLESAMPLE を除く）が可能になりました。
-また、INSERT ... ON CONFLICT と UPDATE tab SET (col1, col2, ..) = (SELLECT ...) ...
-もネイティブレプリケーションで適切にクエリ書き換え処理が可能です。
-</p>
-</li>
-<li>
-ヘルスチェックとストリーミングレプリケーション遅延チェックに使うデータベースを指定できるようになりました。(Tatsuo Ishii)
-<p>
-そのために、新しいパラメータ <a href="#HEALTH_CHECK_DATABASE">health_check_database</a> と
-<a href="#SR_CHECK_DATABASE">sr_check_database</a> が追加されました。
-</p>
-</li>
-
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h3 id="3.5_enhancements">改善点</h3>
-
-<ul>
-<li>
-拡張問い合わせプロトコル使用時の性能が改善されました。(Tatsuo Ishii)
-<p>
-拡張プロトコルメッセージ(parse, bind, describe, execute) の各段階で送信され通信のオーバヘッドとなっていた、
-不必要な "flush" メッセージが取り除かれました。現在のところ、この改善はストリーミングレプリケーションモード
-でのみ効果があり、他のモードでは性能は変わりません。
-</p>
-</li>
-
-<li>
-watchdog 機能の改善 (Muhammad Usama, Yugo Nagata)
-<p>
-この改善は pgpool-II のwachdog の弱点や問題点を見直し watchdog システムをよりロバストで適応的なものにすることです。パッチは Usama により作成され、Yugo がレビュー、テスト、デバッグを行いました。
-</p>
-<ul>
-<li>
-watchdog はクォーラム（定足数）を考慮し、所属する watchdog クラスタに全体の半数以上のノードが存在する場合のみマスター/リーダに選ばれます。
-</li>
-<li>
-watchdog クラスタに参加している全ての pgpool-II ノードは同じ設定となっている必要があります。
-</li>
-<li>
-watchdog ノードは優先度の設定を持ち、ユーザはどのノードがリーダになるべきかを制御しやすくなりました。
-</li>
-<li>
-watchdog はスプリットブレイン現象のような問題の状況を監視し続け、自動的にそこから復帰します。
-</li>
-<li>
-ユーザは、ノードのマスター/リーダへの昇格時および降格時に実行するスクリプトを指定可能です。
-</li>
-</ul>
-<p>
-以下のパラメータが追加されました：
-</p>
-<ul>
-<li>
-<a href="#WD_IPC_SOCKET_DIR">wd_ipc_socket_dir</a>:
-<p>
-pgpool-II watchdog の IPC（プロセス間通信）で受け付ける UNIX ドメインソケットが作成されるディレクトリを指定します。
-</p>
-</li>
-<li>
-<a href="#WD_PRIORITY">wd_priority</a>:
-<p>
-このパラメータによって自身の watchdog ノードがリーダに選ばれる優先度を上げることができます。
-</p>
-</li>
-<li>
-<a href="#WD_DE-ESCALATION_COMMAND">wd_de_escalation_command</a>:
-<p>
-pgpool-II watchdog のマスターノードがマスターの責務を辞退し降格するときに、ここで指定したコマンドが実行されます。
-</p>
-</li>
-<li>
-<a href="#WD_MONITORING_INTERFACES_LIST">wd_monitoring_interfaces_list</a>:
-<p>
-watchdog プロセスがリンク状態を監視するネットワークデバイス名をカンマ区切りで指定します。
-</p>
-</li>
-</ul>
-</li>
-<li>
-pcp コマンドが改善されました。(Muhammad Usama)
-<ul>
-<li>コマンド引数の改善：<p>長いコマンドライン形式のオプションが使用可能になりました。</p></li>
-<li>安全な pcp パスワード：<p>セキュリティリスクとなるため、パスワードをコマンドラインで渡さなくなりました。</p></li>
-<li>複数の pcp コマンドの同時実行：<p>例えば、実行に時間のかかる pcp_recovery_node の最中に他の pcp コマンドの実行が可能です。</p></li>
-</ul>
-</li>
-</p>
-<li>
-"show pool_nodes" コマンドの結果に SELECT 回数を表示するようになりました。 (Tatsuo Ishii)
-<p>
-show pool_nodes の結果には各バックエンドの状態が出力されますが、これに SELECT
-が何回発行されたかが出力されるようなりました。これにより、ロードバランスの効果をすぐに確認することができます。
-</p>
-<pre>
-例：
-test=# show pool_nodes;
- node_id | hostname | port  | status | lb_weight |  role   | select_cnt
----------+----------+-------+--------+-----------+---------+------------
- 0       | /tmp     | 11002 | 2      | 0.500000  | primary | 338230
- 1       | /tmp     | 11003 | 2      | 0.500000  | standby | 163939
-(2 rows)
-</pre>
-</li>
-<li>
-クエリ書き換えのためのパーサ改善 (Yugo Nagata)
-<p>
-ネイティブレプリケーションのクエリ書き換えで WITH 句付きの INSERT/UPDATE/DELETE、
-更新可能 CTE、RETURNING 句が適切に扱えるようになりました。
-</p>
-</li>
-<li>
-pool_passwd ファイルが読み込み権限で開けるようになりました。(Tatsuo Ishii)
-</li>
-<li>
-test: レグレッションテストで pgpool-II をデバッグモードで実行できるようになりました。
-(Tatsuo Ishii)
-</li>
-<li>
-doc: pgpool_adm のドキュメントを追加しました。(Tatsuo Ishii)
-</li>
-<li>
-doc: 中国語のドキュメントを更新しました。 (Bambo Huang)
-</li>
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h3 id="3.5_fixes">バグ修正 (pgpool-II 3.4.3以降のもの)</h3>
-
-<ul>
-
-<li>
-doc: ドキュメントのロードバランスに関する情報を修正しました。(Tatsuo Ishii)
-<p>
-ストリーミングレプリケーションでは DECLARE, FETCH, CLOSE, SHOW はプライマリノードにのみ送られます。
-[pgpool-general-jp: 1378] での指摘によります。
-</p>
-</li>
-
-<li>
-pgpool_status 書き込み時に fsync() を実行するようになりました。(Tatsuo Ishii)
-<p>
-これにより、pgpool_status が永続ストレージに保存され、システムクラッシュ時も情報が失われないことを保証します。
-</p>
-</li>
-
-<li>
-リセットクエリがスタックする問題を修正しました。(Muhammad Usama)
-<p>
-DISCARD ALL などのリセットクエリが時々終了せずに pgpool 子プロセスはバックエンドからの応答を待ったままとなり、
-その結果、クライアントが pgpool-II に接続できなくなるという報告があります（例えば bug #107 の報告）。
-原因はまだ特定できていませんが、クライアントがクエリ処理中に突然 pgpool-II への接続をクローズした場合、
-バックエンドは ready for query でないために、リセットクエリを受け付けられなくなるかもしれません。
-</p>
-<p>
-これは、フロントエンドのソケットの状態を追跡し続け、フロントエンドへの接続が適切に終了できない場合には
-PostgreSQL の接続をキャッシュしないことで修正しました。
-</p>
-</li>
-
-<li>test: レグレッションテスト 062 の誤報を修正しました。(Yugo Nagata)</li>
-
-<li>test: ネイティブレプリケーションのレグレッションテストが壊れていたのを修正しました(Yugo Nagata)
-<p>insert-lock のテストが動作していませんでした。</p>
-</li>
-
-<li>test: レグレッションテストで pgpool_reload の後に sleep を実行するよう修正しました。(Yugo Nagata)
-<p>
-いくつかのテストでは設定ファイルを変更しリロードしますが、時々のリロードを実行した直後では設定の変更が適用されていないことがありました。
-</p>
-</li>
-
-<li>
-レプリケーションモードで発生するシーケンス値の不整合を修正しました。(Yugo Nagata)
-<p>
-スキーマ名が与えられときに、テーブル名が正しくない方法で引用符がつけられていました。
-例えば、"public"."mytbl" ではなく "public.mytbl" というようにです。このため、
-pool_regclass または to_regclass が正しくテーブルの OID を取得できず、insert-lock
-が常に実行されなくなっていました。これは DB 間の不整合の原因となっていました。
-</p></li>
-
-<li>test: timestamp rewrite テストのコンパイラエラーとセグメンテーションフォルトを修正しました。(Yugo Nagata)</li>
-
-<li>doc: 日本語ドキュメントに未翻訳の文があったのを修正しました。(Yugo Nagata)</li>
-
-<li>古くから存在していた pool_push() 関連関数のバグを修正しました。(Tatsuo Ishii)
-<p>
-これはバッファを realloc で割り当て、返却されたポインタを使っていますが、realloc
-が呼ばれる前にポインタの計算を行っていたため、古いポインタ値が使われることになり、
-セグメンテーションフォルトを含む様々な問題の原因となっていました。
-</p>
-<p>
-また、他にも問題がありました。バッファポインタやバッファサイズが初期化されていない、
-バッファが pool_close で解放されていない、デバッグメッセージの typo などです。
-これらも同時に修正されました。
-</p></li>
-
-<li>doc: log_standby_delay に関するドキュメントの誤った記述が修正されました。(Yugo Nagata)</li>
-
-<li>FROM 句に関数が使われた場合に発生するセグメンテーションフォルトが修正されました。(Yugo Nagata)
-<p>
-ストリーミングレプリケーションモードでの PREPARE 文、ネイティブレプリケーションモードでの
-SELECT を伴う INSERT/UPDATE 文が影響を受けていました。
-<pre>
-例）
-prepare p as select * from generate_series(1,1);
-insert into tbl select now(), * from generate_series(1,1);
-</pre>
-</p>
-</li>
-
-<li>
-doc: app_name_redirect_preference_list の JDBC ドライバに関する注意をドキュメントに追加しました。(Tatsuo Ishii)
-</li>
-
-<li>
-bug #145 で報告されたハングを修正しました。(Tatsuo Ishii)
-<p>
-この問題は以下の全ての条件が揃うと発生します：
-</p>
-<ol>
-<li>pgpool-II 3.4 か、それ以降</li>
-<li>ストリーミングレプリケーションモード</li>
-<li>プライマリノードがロードバランス先</li>
-<li>拡張プロトコルが使われている</li>
-<li>client_idle_limit に達した</li>
-</ol>
-</li>
-<li>
-インメモリクエリキャッシュのバグを修正しました。(Tatsuo Ishii)
-<p>
-拡張プロトコルが使用されており、以前の parse メッセージで作成された文を使用する
-bind/execute メッセージが到着した際に、一時キャッシュが parse メッセージで初期され
-ておらず、メッセージは既存の一時キャッシュに追加されていました。これが、キャッシュ
-の結果を返すときに Data Row メッセージと Command Complete メッセージが２重に現れる
-というトラブルの原因になっていました。
-
-bug #152 の報告によります。
-</p>
-</li>
-
-<li>test: レグレッションテスト 065 を修正しました。(Tatsuo Ishii)
-<p>
-JDBC ドライバのパスが明示的に定義されていました。これは良くないため、
-JDBC_DRIVER 環境変数の値を用いるように変更されました。
-</p>
-</li>
-
-<li>test: レグレッションテスト 054.postgres_fdw で発生し得るハングアップを修正しました。(Yugo Nagata)</li>
-
-<li>test: レグレッションテストと pgpool_setup に unix ドメインソケットディレクトリを指定するオプションを追加しました。
-(Yugo Nagata)</li>
-
-<li>doc: ドキュメントに欠けていたデフォルト値の記述を追加しました。(Yugo Nagata)</li>
-
-<li>リセットクエリがスタックする問題を修正しました。(Muhammad Usama)
-<p>
-この問題は他のブランチでは既に修正済みであり、今回も 3.3 シリーズと同じ方法で解決されました。
-すなわち、client idle limit に達した際に、バックエンドの接続を閉じるようにしました。
-</p>
-</li>
-
-<li>"SET TRANSACTION READ ONLY" のバグを修正しました。(Tatsuo Ishii)
-<p>
-pgpool-II は読み込み以外を行うクエリ（SET を含む）が明示的なトランザクションの中で実行されたことを記憶し、
-それが「書き込みトランザクション」であることをマークします。
-これはストリーミングレプリケーション時のクエリの振り分け処理に影響します。
-pgpool-II はそのマークの後、クエリをプライマリに送信するようになります。
-これは、ストリーミングレプリケーションで書き込みクエリの結果がスタンバイで遅れて現れるために、
-クエリはプライマリに送られが方がより安全だからです。
-
-ただし、見過ごされていましたが "SET TRANSACTION READ ONLY" はデータを変更しないので、例外として扱われるべきでした。
-
-バグ報告 #157 によります。
-</p></li>
-
-<li>test: レグレッションテスト 063 のタイムアウト処理で timeout コマンドを使用するよう修正しました。(Yugo Nagata)</li>
-
-<li>エラー出力が誤っていた箇所を修正しました。(Tatsuo Ishii)
-<p>
-connect_with_timeout() で getsockopt(SO_ERROR) がエラーを報告した際に、適切なエラー情報が表示できていませんでした。
-bug #159 の報告によります。
-</p>
-
-</li>test: regress.sh のヘルプメッセージで抜けていた改行を追加しました。(Yugo Nagata)</li>
-
-<li>get_backends_status() 関数のロジックの誤りを修正しました。(Muhammad Usama)
-<p>get_backends_status () 関数は現在の有効でかつダウンしているバックエンドノードの数をカウントします。このとき、有効ではないノードは常にダウンステータスにあることを前提にしていましたが、この前提は常に正しい訳ではありません。</p>
-</li>
-
-<li>white/black_memqcache_table_list パラメータがクォーテーションを要求しないよう修正しました。(Yugo Nagata)
-<p>*_memqcache_table_list でテーブル名およびスキーマ名を指定する際に、ダブルクォーテーションが必要となっていました。修正パッチは Dang Minh Huong によって提供されました。[pgpool-hackers: 1323] の報告によります。</p>
-</li>
-
-<li>設定リロード時の FATAL エラーを修正しました。(Tatsuo Ishii)
-<p>
-pgpool.conf をリロードする際には DB ノードの数が一時的に 0 にセットされたのちに pgpool メインプロセスにより実際のバックエンド数に達するまでカウントアップされます。この変数が共有メモリ上にあったため pgpool 子プロセスで問題が発生し FATAL エラーの原因となっていました。</p>
-<p>Bug #156 の harukat の報告によります。</p>
-</li>
-
-<li>test: レグレッションテスト 006.memqcache に white/black_memqcache_table_list のテストを追加しました。 (Yugo Nagata)</li>
-
-<li>リセットクエリがスタックする問題を修正しました。(Muhammad Usama, Tatsuo Ishii)
-<p>pool_read がフロントエンドからの読み込みに失敗した場合、または poll_flush
-がフロントエンドへの書き込みに失敗した場合に、pgpool 子プロセスの切断・終了処理を行う
-ERROR ではなく、FRONTEND_ERROR を報告するようにしました。これによりクエリがスタックすることを防止します。
-</p>
-</li>
-
-<li>test: デバッグモードで失敗していたレグレッションテストを修正しました。(Yugo Nagata)</li>
-
-<li>IPv6 使用時のパフォーマンス低下を修正しました。(Muhammad Usama)
-<p>Bug #165 の報告によります。</p></li>
-</ul>
-
-<!-- ================================================================================ -->
-<!-- 3.4                                                                              -->
-<!-- ================================================================================ -->
-<hr><a name="release3.4.x"></a>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.4.3"></a>3.4.3 (tataraboshi) 2015/07/24</h2>
-<!-- -------------------------------------------------------------------------------- -->
-
-<h3>概要</h3>
-<p>
-このバージョンは 3.4.2 に対するバグ修正リリースです。
-</p>
-
-<h3>バグ修正</h3>
-<ul>
-
-<li>
-    pgpool-recovery の "cannot find xlog functions" エラーを修正しました。(Muhammad Usama)
-    <p>
-    PostgreSQL 9.4 より、PostgreSQL の pg_xlogfile_name() 関数の引数型はtext からpg_lsn に変更されていますが、pgpool-recovery は依然として古いシグネチャで関数を配置しようとしていました。
-    </p>
-</li>
-
-<li>
-    メモリキャッシュ無効化の問題を修正しました。(Muhammad Usama)
-    <p>
-    テーブルのOIDを保持する内部バッファは、子プロセスの中でずっと使われるため、長寿命のメモリコンテキストに確保される必要がありました。
-    </p>
-    <p>
-    詳しくは [pgpool-general: 3643] を参照してください。
-    </p>
-</li>
-
-<li>
-    failover コマンドのパラメータに対して pgpool-II が値を持たない場合は、空文字列を渡すようにしました。(Muhanmmad Usama)
-    <p>
-    あるパラメータに対して pgpool-II が値を持たない場合には、その値を取り除くのではなく、空の文字列を failover コマンドに渡すようになりました。これにより、failover スクリプトが常に期待した個数のパラメータを受け取るようになります。
-    </p>
-</li>
-
-<li>
-    pgpool-II が独自に定義した snprintf 関数を使うのは、それが OS によって提供されていない場合のみとなりました。(Muhammad Usama)
-</li>
-
-<li>
-    共有メモリがどのくらい割り当てられているのかを表示するデバッグ情報が追加されました。(Tatsuo Ishii)
-</li>
-
-<li>
-    バックエンド接続がメインプロセスに EOF を返した時のエラーレベルを引き下げました。(Muhammad Usama)
-    <p>
-    バックエンドから EOF が返されたときに pgpool メインプロセスで FATALエラーを投げるのはやりすぎで、望ましくない振る舞いの原因となっていました。このエラーレベルは ERROR に引き下げられました。
-    </p>
-</li>
-
-<li>
-    doc: ロードバランスが行われる条件をより明確にしました。(Tatsuo Ishii)
-</li>
-
-<li>
-    doc: pcp_promote_node の記述をより明確にしました。(Tatsuo Ishii)
-    <p>
-    このコマンド PostgreSQL スタンバイを実際に昇格させるわけではありません。
-    </p>
-</li>
-
-<li>
-    doc: JDBC ドライバ使用時のロードバランス条件について制限事項の内容が古かったので修正しました。(Tatsuo Ishii)
-    <p>
-    autocommit が false であっても、ある条件下ではロードバランスが可能です。
-    </p>
-</li>
-
-<li>
-    あるログの出力コードが到達不能になっていた不具合と、ログメッセージの内容を修正しました。(Muhammad Usama)
-</li>
-
-<li>
-    フロントエンドのクライアントにメッセージを送る際の elog.c の問題を修正しました。(Muhammad Usama)
-    <p>
-    フロントエンドクライアントにメッセージを送っている間に発生したエラーは、無限ループを引き起こし、ERRORDATA_STACK_SIZE 超過エラーのために子プロセスが異常終了する可能性がありました。
-    </p>
-    <p>
-    send_message_to_frontend() 関数の深さをチェックし、それが２を越えた場合には処理を中断することにより、この問題は修正されました。
-    </p>
-</li>
-
-<li>
-    "select() system call interrupted" エラーが修正されました。(Tatsuo Ishii)
-    <p>
-    ヘルスチェックの過程でこのエラーに続いて以下のエラーが出力されていました。
-    </p>
-    <p>
-    ERROR:  failed to make persistent db connectionDETAIL:  connection to host:"x.x.x.x:5432 failed
-    </p>
-    <p>
-    しかし、ヘルスチェックはファイルオーバも再試行も実行しないので、これらのメッセージに煩わされる以外には問題はありませんでした。これは 1)num_init_children が大きく、2) pgpool の子プロセスが idle 状態にある（child_life_time 秒の間、クライアントからクエリが来ていない）場合に容易に発生していました。
-    </p>
-    <p>
-    もとのバグ報告は[pgpool-general: 3756] Connection Interrupted で行われ、パッチは Tatsuo Ishii により作成され、Usama により改善されました。
-    </p>
-</li>
-
-<li>
-    ユーザテーブルにスペースが含まれる場合の問題を修正しました。(Tatsuo Ishii)
-    <p>
-    例えばテーブル名にスペースが含まれる場合、pgpool-II のシステムカタログにアクセスする内部関数でこれを正しく扱うことができず、SQL エラーとなっていました。この問題は、常に識別子に区切り文字を付与することで解決しました。
-    </p>
-    <blockquote>
-    bug #136 の報告によります。<br />
-    <a href="http://www.pgpool.net/mantisbt/view.php?id=136">
-    http://www.pgpool.net/mantisbt/view.php?id=136
-    </a>
-    </blockquote>
-    <blockquote>
-    詳しくは [pgpool-general: 3818] も参照してください。
-    </blockquote>
-</li>
-
-<li>
-    インメモリクエリキャッシュが 4GB より大きなメモリサイズを使えるように修正しました。(Tatsuo Ishii)
-    <p>
-    これはインメモリクエリキャッシュ機能が完成した時点で可能にしておくべきでした。
-    </p>
-</li>
-
-<li>
-    拡張問い合わせクエリで、レプリケーションモード以外の場合には、insertlock をチェックするクエリを送信しないようになりました。(Tatsuo Ishii)
-</li>
-
-<li>
-    pgpool_status が変更されたときに、これをディスクに保存するようになりました。(Tatsuo Ishii)
-    <p>
-    以前は pgpool-II が明示的に終了するときに pgpool_status を保存していました。これは多くの場合は問題なく、CPU サイクルの節約になっていましたが、pgpool-IIが異常終了したり、OOM キラーによって強制的に終了させられた場合には、次回の再起動時に古いステータスファイルを読む可能性がありました。
-    </p>
-</li>
-
-
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.4.2"></a>3.4.2 (tataraboshi) 2015/04/08</h2>
-<!-- -------------------------------------------------------------------------------- -->
-
-<h3>概要</h3>
-<p>
-このバージョンは 3.4.1 に対するバグ修正リリースです。
-</p>
-
-<h3>バグ修正</h3>
-<ul>
-
-<li>
-    rpm: %tmpfiles_create を RHEL/CentOS6 では実行しないように修正しました。(Nozomi Anzai)
-</li>
-
-<li>
-    exec_if_cmd および exec_ping 関数で fork されるプロセスで on_exit コールバック関数をリセットするように修正しました。(Muhammad Usama)
-    <p>
-    exec_if および exec_ping の子プロセスでは親プロセスの exit コールバック関数を継承していましたが、コマンド実行が失敗したときに不本意な振る舞いをすることがありました。これを、子プロセス起動時に on_exit_reset()を呼ぶことで修正しました。
-    </p>
-</li>
-
-<li>
-    スレッド関数の戻り値を void * 型で受け取るように修正しました。(Yugo Nagata)
-    <p>
-    以前は int 型が使われており、スタックバッファオーバフローの原因となっていました。これにより、仮想IPの起動/停止時に、ping エラーの無限ループが発生することがありました。
-    </p>
-</li>
-
-<li>
-    watchdog プロセスで、SIGCHLD を SIG_IGN ではなく SIG_DFL に設定するよう修正しました。(Yugo Nagata)
-    <p>
-    waitpid 使用時は SIGCHLD を SIG_IGN にする必要はなく、むしろ有害であり、これにより ping コマンドが正常終了した場合でも異常終了したとみなされる場合がありました。
-    </p>
-</li>
-
-<li>
-    exec_ifconfig 関数内で wait はなく waitpid を使うように修正しました。(Yugo Nagata)
-</li>
-
-<li>
-    不必要な include ディレクティブを取り除きました。(Yugo Nagata)
-</li>
-
-<li>
-    POOLCONFIG_MAXDESCLEN を 80 まで増やしました (Tatsuo Ishii)
-    <p>
-    これは show pool_status コマンドでパラメータの説明文の長さ制限に使われていますが、recovery_timetout ではこれが 64 文字であり、以前のマクロ定義では 1 文字分不足していました。
-    </p>
-</li>
-
-<li>
-    doc: ロードバランスの条件についてドキュメントを更新しました。(Yugo Nagata)
-    <p>
-    3.3.0 より、レプリケーションモードにおいても、明示的なトランザクションブロック内のロードバランスが可能になっています。
-    </p>
-</li>
-
-<li>
-    フロントエンド接続の証明書ファイルで SSL 証明書チェーンに対応しました。(Muhammad Usama)
-</li>
-
-<li>
-    レプリケーションモードで時刻の書き換えを行う際に、可能であれば to_regclass を使用するようになりました。(Tatsuo Ishii)
-</li>
-
-<li>
-    パスワード認証が使用時に FATAL エラーメッセージが出力されないように修正しました。(Muhammad Usama)
-    <p>
-    この問題は pgpool-II に例外マネージが取り入れてから発生したものです。パスワード認証を使用する場合、クライアント認証中にフロントエンドから EOF が送られてきても、これをエラーと扱うべきではありません。例えば psql はパスワードを端末から取得するために一度サーバへの接続を切ったのちに、再接続してパスワードをサーバに送信します。
-    </p>
-</li>
-
-<li>
-    エラーで終了した pgpool-II 子プロセスが別セッションで再利用された際に発生するセグメンテーションフォルトを修正しました。(Muhammad Usama)
-</li>
-
-<li>
-    レプリケーションモードでトランザクションブロック中でエラーが発生した際にハングする不具合を修正しました。(Yugo Nagata)
-    <p>
-    レプリケーションモードでトランザクションブロック内でエラーが発生した際、バックエンド間でトランザクション状態を同じに保つために、pgpool-II は無効なクエリを他のバックエンドに送信します。しかし、これがマスターノードに送られていなかったため、pgpool-II はマスターからの反応を永遠に待ち続けていました。
-    </p>
-</li>
-
-<li>
-    pcp_detach_node が graceful にノードを切り離す際の問題を修正しました。(Muhammad Usama)
-    <p>
-    graceful なノード切り離しでは、そのノードの切り離し処理が許されているかの判断を、pcp_detach_node は新しい接続のブロックと既存の接続の切断よりも前に行う必要があります。
-    </p>
-</li>
-
-<li>
-    doc: クエリの送り先を示した表とフローチャートを更新しました。(Yugo Nagata)
-</li>
-
-<li>
-    rpm: pgpool.spec は RHEL/CentOS 7 にのみ必要です。(Nozomi Anzai)
-</li>
-
-<li>
-    BSD での sighandler_t 型に関するコンパイラエラーを修正しました。(Muhammad Usama)
-</li>
-
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.4.1"></a>3.4.1 (tataraboshi) 2015/02/05</h2>
-<!-- -------------------------------------------------------------------------------- -->
-
-<h3>概要</h3>
-<p>
-このバージョンは 3.4.0 に対するバグ修正リリースです。
-</p>
-
-<h3>バグ修正</h3>
-<ul>
-
-<li>
-    RPM: memcached に対応しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    pgpool_recovery 関数の引数を 3 から 4 に修正しました。(Tatsuo Ishii)
-    <p>
-    これは本来 3.4.0 リリース時に修正されるべきものでした。
-    </p>
-</li>
-
-<li>
-    test: pgpool_setup で使用する設定ファイルのディレクトリを環境変数 PGPOOLDIR で指定できるようになりました。(Tatsuo Ishii)
-</li>
-
-<li>
-    RPM: RPM ファイル名を変更しました。(Yugo Nagata)
-    <p>
-    新しいファイル名は PostgreSQL の公式 RPM ファイルのように RHEL のバージョン番号を含みます。(例. pgpool-II-pg93-3.4.0-2pgdg.rhel6.x86_64.rpm)
-    </p>
-</li>
-
-<li>
-    trigger_failover_command() 関数のノード ID 範囲検査のバグを修正しました。(Tatsuo Ishii)
-    <p>
-    ノード ID は定数 NUM_BACKENDS 未満である必要があります。実際にはNUM_BACKENDS 以上の値はこの関数に渡されていなかったので、おそらく害はありませんでした。
-    </p>
-</li>
-
-<li>
-    NOTIFY メッセージがバックエンドから送信された時に起こりうるスタックが修正されました。(Muhammad Usama)
-    <p>
-    これはマスタースレーブモードで、ロードバランスが有効であり、クライアントが拡張クエリを使用しているときに発生する可能性がありました。
-    </p>
-    <blockquote>
-    bug #116 の報告によります。<br />
-    <a href="http://www.pgpool.net/mantisbt/view.php?id=116">
-    http://www.pgpool.net/mantisbt/view.php?id=116
-    </a>
-    </blockquote>
-</li>
-
-<li>
-    test:pgpool_setup の failover スクリプトがデータベースクラスタの絶対パスを使用するように修正しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    test: pgpool_setup で使われるポート番号の割り当て方を変更しました。(Tatsuo Ishii)
-    <p>
-    ベースとなる番号（デフォルト 11000）を pgpool-II のポートに、ベース + 1を pcp のポートに、ベース + 2 以降を PostgreSQL のポートに割り当てるようになりました。
-    </p>
-</li>
-
-<li>
-    pgpool-II 3.4 でクエリをキャンセルできないバグを修正しました。(Muhammad Usama)
-</li>
-
-<li>
-    test: クエリキャンセルのレグレッションテストを追加しました。(Muhammad Usama)
-</li>
-
-<li>
-    スレッド安全ではない API をスレッド関数で使用しないよう修正しました。(Muhammad Usama)
-    <p>
-    pgpool-II は PostgreSQL のメモリと例外の管理機能を流用していますが、これらはスレッドセーフではありません。修正前は、これらのグローバル変数を扱う API がスレッドの関数の中で使用されており、未定義の動作やセグメンテーションフォルトの原因となっていました。特に、親プロセスが突然異常終了することがありました。
-    </p>
-</li>
-
-<li>
-    test: メモリリークのレグレッションテストを追加しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    長期間のコネクションがあるときのメモリリークが修正されました。(Muhammad Usama)
-    <p>
-    この問題は [pgpool-general: 3325] で報告されました。
-    </p>
-</li>
-
-<li>
-    "Frontend Terminated" メッセージのログレベルを LOG から DEBUG1 に変更しました。(Muhammad Usama)
-</li>
-
-<li>
-    exec_ifconfig() 関数での SIGCHLD ハンドリングの不具合をを修正しました。(Tatsuo Ishii)
-    <p>
-    何らかの理由により、SIGCHLD は SIG_IGN にセットされているにもかからず子プロセスの終了状態を取得しようとしていました。SIGCHLD は無視されるため、これは常に失敗します。このため watchdog の pgpool-II 切り替わり時に "ifconfig up" が失敗とみなされていました。
-    </p>
-    <p>
-    詳しくは "[pgpool-general: 3310] をご参照ください。
-    </p>
-</li>
-
-<li>
-    if_up_cmd, if_down_cmd でアドレスプレフィックス付きの $_IP_$ を使用できるように修正しました。(Muhammad Usama)
-    <p>
-    以前は "$_IP_$" の直後には空白が来ることが前提となっていたため、アドレスプレフィックスがある場合（例：$_IP_$/24 ）、このプレフィックスは無視されていました。
-    </p>
-    <blockquote>
-    bug #122 の報告によります。<br />
-    <a href="http://www.pgpool.net/mantisbt/view.php?id=122">
-    http://www.pgpool.net/mantisbt/view.php?id=122
-    </a>
-    </blockquote>
-</li>
-
-<li>
-    シグナルを init プロセスに送信しないよう修正しました。(Muhammad Usama)
-    <p>
-    これは、pgpool-II の親プロセスがクラッシュし、子プロセスがシステムの init プロセスにシグナルを送信可能になってしまうような状況に備えた対応です。
-    </p>
-    <blockquote>
-    bug #119 の報告によります。<br />
-    <a href="http://www.pgpool.net/mantisbt/view.php?id=119">
-    http://www.pgpool.net/mantisbt/view.php?id=119
-    </a>
-    </blockquote>
-</li>
-
-<li>
-    RPM: PostgreSQL 9.4 向けの RPM 作成時に発生していたエラー<br>"error: Installed ("error: Installed (but unpackaged) file(s) found"<br>を修正しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    show pool_nodes が 2 桁以上のノード ID を表示できるように修正しました。(Muhammad Usama)
-    <p>
-    この問題は [pgpool-general: 3374] で報告されました。
-    </p>
-</li>
-
-<li>
-    古いクライアントでアプリケーション名の指定がなかった場合に、メッセージ<br>"WARNING: failed to execute regex matching, pattern is NULL"<br>が出力されていたのを修正しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    起動時に子プロセスの立ち上げに失敗した場合には pgpool-II 全体で起動失敗とするように修正しました。(Muhammad Usama)
-    <p>
-    [pgpool-general: 3358] での報告によります。
-    </p>
-</li>
-
-<li>
-    子プロセスでエラーが発生したときに起こりうるセグメンテーションフォルトを修正しました。(Muhammad Usama)
-    <p>
-    この問題は [pgpool-general: 3377] で報告されました。
-    </p>
-</li>
-
-<li>
-    レグレッションテスト '004.watchdog' が失敗する場合があるのを修正しました。(Yugo Nagata)
-    <blockquote>
-    パッチは uehara によって bug #127 で提供されました。<br />
-    <a href="http://www.pgpool.net/mantisbt/view.php?id=127">
-    http://www.pgpool.net/mantisbt/view.php?id=127
-    </a>
-    </blockquote>
-</li>
-
-<li>
-    クライアント接続の閉じ忘れを修正しました。(Tatsuo Ishii)
-    <p>
-    pgpool-II 3.4.0 よりセッション終了時にクライアントへの接続が閉じられていませんでした。これにより "CLOSE_WAIT" が大量に滞留し、pgpool-II はクライアントからの新規の接続を受け付けられなくなります。
-    </p>
-    <p>
-    この問題は Pablo Sanchez により [pgpool-general: 3394] で報告されました。
-    </p>
-</li>
-
-<li>
-    if_up_cmd, if_down_cmd 実行後は SIGCHLD ハンドラを元に戻すように修正しました。(Yugo Nagata)
-    <p>
-    修正前は SIGCHLD は常に SIG_IGN にセットされていたので、ping など他のコマンドの終了状態の取得が正しく行えず、コマンド自体が正常終了してもログには警告メッセージが出力されていました。
-    </p>
-</li>
-
-<li>
-    RPM: RHEL/CentOS7 で systemd を使用するため pgpool.service を追加しました。(Nozomi Anzai)
-</li>
-
-<li>
-    enabled_pool_hba 有効時に pgpool reload を繰り返すとプロセスが異常終了するバグを修正しました。(Muhammad Usama)
-</li>
-
-<li>
-    app_name_redirect_preference_list と database_redirect_preference_listの値のチェックをより強固にしました。(Tatsuo Ishii)
-    <p>
-    以前はアプリケーション名・データベース名が空の場合や、不正なノード番号も許容されていましたが、この検査を厳しくし、起動時に fatal エラーを出力するように変更されました。
-    </p>
-    <p>
-    [pgpool-general-jp: 1337] の報告によります。
-    </p>
-</li>
-
-<li>
-    RPM: systemd が使用可能な場合は使用するよう変更しました。(Nozomi Anzai)
-</li>
-
-<li>
-    設定パラメータ "client_min_messages" の振る舞いを修正しました。(Muhammad Usama)
-    <p>
-    このパラメータはフロントエンドに送られる最小のメッセージレベルを制御するものですが、以前はこの値にかかわらず、NOTICE より低いレベルのメッセージは一切クライアントに送信されていませんでした。
-    </p>
-</li>
-
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.4.0"></a>3.4.0 (tataraboshi) 2014/11/07</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<p>
-このバージョンは 3.4 系列の最初の版で、3.3 系からの「メジャーバージョンアップ」にあたります。
-</p>
-
-<h3>互換性のない変更</h3>
-<ul>
-    <li>パラレルクエリモードが廃止され、pgpool.confから削除されました。
-      これは、パラレルクエリモードのユーザが少ない割に維持に手間がかかるためです。
-      実際にはパラレルクエリモード用のコードはまだ存在しており、pgpool.confに必要なパラメータを書くことで使用は可能です。
-      しかしながら、次のpgpool-IIのバージョン(3.5.0)では、コードも削除される予定です</li>
-
-    <li>"print_timestamp"が削除されました。代わりに"<a href=#LOG_LINE_PREFIX>log_line_prefix</a>を使ってください</li>
-
-
-    <li>リカバリスクリプトが従来の3つではなく、4つのパラメータを受け取るようになりました(4番目のパラメータは、PostgreSQLのマスタサーバのポート番号です)。
-      もし4番目のパラメータの情報を必要としないのであれば、従来の3つのパラメータを受け取るリカバリスクリプトも利用できます</li>
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h3 id="3.4_new_features">新機能</h3>
-
-<ul>
-<li>アプリケーション名あるいはデータベース名できめ細かく負荷分散を制御できるようになりました(<a href="#DATABASE_REDIRECT_PREFERENCE_LIST">database_redirect_preference_list</a>と
-<a href="#APP_NAME_REDIRECT_PREFERENCE_LIST">app_name_redirect_preference_list</a>を参照)。
-  たとえば、クライアントのアプリケーション名の場合に、どれかのスレーブサーバに検索を分散させるのではなく、マスタサーバに投げるような設定も可能です(Tatsuo)</li>
-
-<li>pgpool-IIのプロセス名をログに出力できるようになりました。そのための新しいパラメータは "log_line_prefix"で、printfで指定するようなやり方で、ログの先頭に文字列を追加できます(Muhanmmad Usama)</li>
-
-<li>PostgreSQLのように、ログの詳しさを指定できるようになりました。
-あたらしいパラメータは "<a href="#LOG_ERROR_VERBOSITY">log_error_verbosity</a>", "<a href="#CLIENT_MIN_MESSAGES">client_min_messages</a>", "<a href="#LOG_MIN_MESSAGES">log_min_messages</a>" です(Tatsuo Ishii)</li>
-
-<li>新しいパラメータ "<a href="#ALLOW_SQL_COMMENTS">allow_sql_comments</a>" がオンの場合、負荷分散に干渉すること無くSQLコメントを使えるようになりました。オフの場合は今までと同様の振る舞いになります(Tatsuo Ishii)</li>
-
-<li>"<a href="#CHECK_UNLOGGED_TABLE">check_unlogged_table</a>"という新しいパラメータにより、unloggedテーブルが使われているかどうかのチェックが省略できるようになりました。これにより、pgpool-IIが発行する内部的なカタログ参照のためのクエリの数を減らして性能を向上できます(Tatsuo Ishii)</li>
-
-<li>新しいパラメータ"<a href="#LISTEN_BACKLOG_MULTIPLIER">listen_backlog_multiplier</a>"を使って、非常に負荷の高いシステムにおけるListenバックログのあふれを防ぐことができるようになりました(Tatsuo Ishii)</li>
-
-<li>新しいパラメータ"<a href="#CONNECT_TIMEOUT">connect_timeout</a>"を使って、バックエンドへの接続タイムアウトを防ぐことができるようになりました。この機能は、不安定なネットワーク環境で役に立ちます(Tatsuo Ishii)</li>
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h3 id="3.4_enhancements">改善点</h3>
-
-<ul>
-<li>組み込みのSQLパーサがPostgreSQL 9.4と互換性のあるものになりました(Muhammad Usama)</li>
-
-<li>PostgreSQLのメモリマネージャと例外処理マネージャが移植されました(Muhammad Usama)</li>
-
-<li>ソースツリーを再構成しました(Muhammad Usama)</li>
-
-<li>pgpool_statusのフォーマットがASCIIファイルになりました。これにより、たとえばpgpool-IIを起動するまえにダウンしているPostgreSQLノードを登録するようなことが可能です(Tatsuo Ishii)</li>
-
-<li>リカバリスクリプトに新しい第4のパラメータが追加されました。マスターノードのポート番号が指定可能です(Tatsuo Ishii)</li>
-
-<li>3つより多いデータベースをpgpool_setupで扱えるようになりました(Tatsuo Ishii)</li>
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h3 id="3.4_fixes">バグ修正(pgpool-II 3.3.4以降のもの)</h3>
-
-<ul>
-
-<li>failoverの際にデッドロックを起こすことがあるwatchdogのバグを修正しました。詳細はバグトラックの105番および[pgpool-committers: 2195] をご覧ください(Muhammad Usama)</li>
-
-<li>Close portalリクエストを存在しないポータルに発行してもエラーにならなくなりました。これが元々PostgreSQLのフロントエンド／バックエンドプロトコルで要求されていた仕様です。このようなケースでは、バックエンドを経由すること無く"close complete"メッセージがクライアントに直ちに返るようになりました(Muhammad Usama)</li>
-
-<li>Coverityにより見つかった多くのバグが修正されました(Muhammad Usama, Tatsuo Ishii)</li>
-
-</ul>
-
-<!-- ================================================================================ -->
-<!-- 3.3                                                                              -->
-<!-- ================================================================================ -->
-<hr><a name="release3.3.x"></a>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.3.7"></a>3.3.7 (tokakiboshi) 2015/07/24</h2>
-<!-- -------------------------------------------------------------------------------- -->
-
-<h3>概要</h3>
-<p>
-このバージョンは 3.3.6 に対するバグ修正リリースです。
-</p>
-
-<h3>バグ修正</h3>
-<ul>
-
-<li>
-    pgpool-recovery の "cannot find xlog functions" エラーを修正しました。(Muhammad Usama)
-    <p>
-    PostgreSQL 9.4 より、PostgreSQL の pg_xlogfile_name() 関数の引数型はtext からpg_lsn に変更されていますが、pgpool-recovery は依然として古いシグネチャで関数を配置しようとしていました。
-    </p>
-</li>
-
-<li>
-    failover コマンドのパラメータに対して pgpool-II が値を持たない場合は、空文字列を渡すようにしました。(Muhanmmad Usama)
-    <p>
-    あるパラメータに対して pgpool-II が値を持たない場合には、その値を取り除くのではなく、空の文字列を failover コマンドに渡すようになりました。これにより、failover スクリプトが常に期待した個数のパラメータを受け取るようになります。
-    </p>
-</li>
-
-<li>
-    doc: ロードバランスが行われる条件をより明確にしました。(Tatsuo Ishii)
-</li>
-
-<li>
-    doc: pcp_promote_node の記述をより明確にしました。(Tatsuo Ishii)
-    <p>
-    このコマンド PostgreSQL スタンバイを実際に昇格させるわけではありません。
-    </p>
-</li>
-
-<li>
-    doc: JDBC ドライバ使用時のロードバランス条件について制限事項の内容が古かったので修正しました。(Tatsuo Ishii)
-    <p>
-    autocommit が false であっても、ある条件下ではロードバランスが可能です。
-    </p>
-</li>
-
-<li>
-    "select() system call interrupted" エラーが修正されました。(Tatsuo Ishii)
-    <p>
-    ヘルスチェックの過程でこのエラーに続いて以下のエラーが出力されていました。
-    </p>
-    <p>
-    ERROR:  failed to make persistent db connectionDETAIL:  connection to host:"x.x.x.x:5432 failed
-    </p>
-    <p>
-    しかし、ヘルスチェックはファイルオーバも再試行も実行しないので、これらのメッセージに煩わされる以外には問題はありませんでした。これは 1)num_init_children が大きく、2) pgpool の子プロセスが idle 状態にある（child_life_time 秒の間、クライアントからクエリが来ていない）場合に容易に発生していました。
-    </p>
-    <p>
-    もとのバグ報告は[pgpool-general: 3756] Connection Interrupted で行われ、パッチは Tatsuo Ishii により作成され、Usama により改善されました。
-    </p>
-</li>
-
-<li>
-    ユーザテーブルにスペースが含まれる場合の問題を修正しました。(Tatsuo Ishii)
-    <p>
-    例えばテーブル名にスペースが含まれる場合、pgpool-II のシステムカタログにアクセスする内部関数でこれを正しく扱うことができず、SQL エラーとなっていました。この問題は、常に識別子に区切り文字を付与することで解決しました。
-    </p>
-    <blockquote>
-    bug #136 の報告によります。<br />
-    <a href="http://www.pgpool.net/mantisbt/view.php?id=136">
-    http://www.pgpool.net/mantisbt/view.php?id=136
-    </a>
-    </blockquote>
-    <blockquote>
-    詳しくは [pgpool-general: 3818] も参照してください。
-    </blockquote>
-</li>
-
-<li>
-    インメモリクエリキャッシュが 4GB より大きなメモリサイズを使えるように修正しました。(Tatsuo Ishii)
-    <p>
-    これはインメモリクエリキャッシュ機能が完成した時点で可能にしておくべきでした。
-    </p>
-</li>
-
-<li>
-    拡張問い合わせクエリで、レプリケーションモード以外の場合には、insertlock をチェックするクエリを送信しないようになりました。(Tatsuo Ishii)
-</li>
-
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.3.6"></a>3.3.6 (tokakiboshi) 2015/04/08</h2>
-<!-- -------------------------------------------------------------------------------- -->
-
-<h3>概要</h3>
-<p>
-このバージョンは 3.3.5 に対するバグ修正リリースです。
-</p>
-
-<h3>バグ修正</h3>
-<ul>
-
-<li>
-    rpm: %tmpfiles_create を RHEL/CentOS6 では実行しないように修正しました。(Nozomi Anzai)
-</li>
-
-<li>
-    スレッド関数の戻り値を void * 型で受け取るように修正しました。(Yugo Nagata)
-    <p>
-    以前は int 型が使われており、スタックバッファオーバフローの原因となっていました。これにより、仮想IPの起動/停止時に、ping エラーの無限ループが発生することがありました。
-    </p>
-</li>
-
-<li>
-    watchdog プロセスで、SIGCHLD を SIG_IGN ではなく SIG_DFL に設定するよう修正しました。(Yugo Nagata)
-    <p>
-    waitpid 使用時は SIGCHLD を SIG_IGN にする必要はなく、むしろ有害であり、これにより ping コマンドが正常終了した場合でも異常終了したとみなされる場合がありました。
-    </p>
-</li>
-
-<li>
-    不必要な include ディレクティブを取り除きました。(Yugo Nagata)
-</li>
-
-<li>
-    POOLCONFIG_MAXDESCLEN を 80 まで増やしました (Tatsuo Ishii)
-    <p>
-    これは show pool_status コマンドでパラメータの説明文の長さ制限に使われていますが、recovery_timetout ではこれが 64 文字であり、以前のマクロ定義では 1 文字分不足していました。
-    </p>
-</li>
-
-<li>
-    doc: ロードバランスの条件についてドキュメントを更新しました。(Yugo Nagata)
-    <p>
-    3.3.0 より、レプリケーションモードにおいても、明示的なトランザクションブロック内のロードバランスが可能になっています。
-    </p>
-</li>
-
-<li>
-    フロントエンド接続の証明書ファイルで SSL 証明書チェーンに対応しました。(Muhammad Usama)
-</li>
-
-<li>
-    レプリケーションモードで時刻の書き換えを行う際に、可能であれば to_regclass を使用するようになりました。(Tatsuo Ishii)
-</li>
-
-<li>
-    レプリケーションモードでトランザクションブロック中でエラーが発生した際にハングする不具合を修正しました。(Yugo Nagata)
-    <p>
-    レプリケーションモードでトランザクションブロック内でエラーが発生した際、バックエンド間でトランザクション状態を同じに保つために、pgpool-II は無効なクエリを他のバックエンドに送信します。しかし、これがマスターノードに送られていなかったため、pgpool-II はマスターからの反応を永遠に待ち続けていました。
-    </p>
-</li>
-
-<li>
-    pcp_detach_node が graceful にノードを切り離す際の問題を修正しました。(Muhammad Usama)
-    <p>
-    graceful なノード切り離しでは、そのノードの切り離し処理が許されているかの判断を、pcp_detach_node は新しい接続のブロックと既存の接続の切断よりも前に行う必要があります。
-    </p>
-</li>
-
-<li>
-    doc: クエリの送り先を示した表とフローチャートを更新しました。(Yugo Nagata)
-</li>
-
-<li>
-    rpm: pgpool.service は RHEL/CentOS 7 にのみ必要です。(Nozomi Anzai)
-</li>
-
-
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.3.5"></a>3.3.5 (tokakiboshi) 2015/02/05</h2>
-<!-- -------------------------------------------------------------------------------- -->
-
-<h3>概要</h3>
-<p>
-このバージョンは 3.3.4 に対するバグ修正リリースです。
-</p>
-
-<h3>バグ修正</h3>
-<ul>
-
-<li>
-    doc: スレーブノードの数は１である必要でないことを明記しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    watchdog を使用しているときにフェイルオーバ時に発生しうるデッドロックを修正しました。(Muhammad Usama)
-    <blockquote>
-    bug #105 の報告によります。<br />
-    <a href="http://www.pgpool.net/mantisbt/view.php?id=105">
-    http://www.pgpool.net/mantisbt/view.php?id=105
-    </a>
-    </blockquote>
-</li>
-
-<li>
-    未初期化の変数があったのを修正しました。(Tatsuo Ishii)
-    <p>
-    Coverity の報告 #1234603 によります。
-    </p>
-</li>
-
-<li>
-    doc: 前回のリリースで抜け落ちていたリリースノートを追記しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    test: pgpool_setup の wait_for_pgpool_startup 関数が test データベースではなく postgres データベースを使用するように修正しました。(Tatsuo Ishii)
-    <p>
-    test データベースは存在しない場合があり、その場合はタイムアウト（20秒）になるまでリトライしつづけるので、レグレッションテストに必要以上に時間がかかっていました。
-    </p>
-</li>
-
-<li>
-    クエリキャッシュで発生しうるセグメンテーションフォルトを修正しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    RPM: memcached に対応しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    test: pgpool_setup で使用する設定ファイルのディレクトリを環境変数 PGPOOLDIR で指定できるようになりました。(Tatsuo Ishii)
-</li>
-
-<li>
-    RPM: RPM ファイル名を変更しました。(Yugo Nagata)
-    <p>
-    新しいファイル名は PostgreSQL の公式 RPM ファイルのように RHEL のバージョン番号を含みます。(例. pgpool-II-pg93-3.4.0-2pgdg.rhel6.x86_64.rpm)
-    </p>
-</li>
-
-<li>
-    trigger_failover_command() 関数のノード ID 範囲検査のバグを修正しました。(Tatsuo Ishii)
-    <p>
-    ノード ID は定数 NUM_BACKENDS 未満である必要があります。実際にはNUM_BACKENDS 以上の値はこの関数に渡されていなかったので、おそらく害はありませんでした。
-    </p>
-</li>
-
-<li>
-    test:pgpool_setup の failover スクリプトがデータベースクラスタの絶対パスを使用するように修正しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    test: メモリリークのレグレッションテストを追加しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    exec_ifconfig() 関数での SIGCHLD ハンドリングの不具合をを修正しました。(Tatsuo Ishii)
-    <p>
-    何らかの理由により、SIGCHLD は SIG_IGN にセットされているにもかからず子プロセスの終了状態を取得しようとしていました。SIGCHLD は無視されるため、これは常に失敗します。このため watchdog の pgpool-II 切り替わり時に "ifconfig up" が失敗とみなされていました。
-    </p>
-    <p>
-    詳しくは "[pgpool-general: 3310] をご参照ください。
-    </p>
-</li>
-
-<li>
-    if_up_cmd, if_down_cmd でアドレスプレフィックス付きの $_IP_$ を使用できるように修正しました。(Muhammad Usama)
-    <p>
-    以前は "$_IP_$" の直後には空白が来ることが前提となっていたため、アドレスプレフィックスがある場合（例：$_IP_$/24 ）、このプレフィックスは無視されていました。
-    </p>
-    <blockquote>
-    bug #122 の報告によります。<br />
-    <a href="http://www.pgpool.net/mantisbt/view.php?id=122">
-    http://www.pgpool.net/mantisbt/view.php?id=122
-    </a>
-    </blockquote>
-</li>
-
-<li>
-    show pool_nodes が 2 桁以上のノード ID を表示できるように修正しました。(Muhammad Usama)
-    <p>
-    この問題は [pgpool-general: 3374] で報告されました。
-    </p>
-</li>
-
-<li>
-    レグレッションテスト '004.watchdog' が失敗する場合があるのを修正しました。(Yugo Nagata)
-    <blockquote>
-    パッチは uehara によって bug #127 で提供されました。<br />
-    <a href="http://www.pgpool.net/mantisbt/view.php?id=127">
-    http://www.pgpool.net/mantisbt/view.php?id=127
-    </a>
-    </blockquote>
-</li>
-
-<li>
-    if_up_cmd, if_down_cmd 実行後は SIGCHLD ハンドラを元に戻すように修正しました。(Yugo Nagata)
-    <p>
-    修正前は SIGCHLD は常に SIG_IGN にセットされていたので、ping など他のコマンドの終了状態の取得が正しく行えず、コマンド自体が正常終了してもログには警告メッセージが出力されていました。
-    </p>
-</li>
-
-<li>
-    RPM: RHEL/CentOS7 で systemd を使用するため pgpool.service を追加しました。(Nozomi Anzai)
-</li>
-
-<li>
-    RPM: pgpool_regclass と pgpool_recovery を extension パッケージとして他から分離させました。(Tatsuo Ishii)
-    <p>
-    PostgreSQL サーバでは extension パッケージのみが必要で、pgpool-II の全パッケージをインストールする必要はありません。
-    </p>
-    <p>
-    Andrew N Golovkov によります。
-    </p>
-</li>
-
-<li>
-    RPM: spec ファイルで SSL の configure オプションが誤っていたのを修正しました。(Tatsuo Ishii)
-    <p>
-    SSL を有効にするオプションが "--with-openssl=/usr" となっていましたが、正しくは "--with-openssl" でした。
-    </p>
-    <blockquote>
-    bug #115 の報告によります。<br />
-    <a href="http://www.pgpool.net/mantisbt/view.php?id=115">
-    http://www.pgpool.net/mantisbt/view.php?id=115
-    </a>
-    </blockquote>
-</li>
-
-<li>
-    RPM: systemd が使用可能なら使用するとともに、PostgreSQL 9.4 への対応を行いました。(Nozomi Anzai)
-</li>
-
-<li>
-    設定ファイルのリロードにより debug モードを無効にできるよう修正しました。(Yugo Nagata)
-    <blockquote>
-    bug #114 の報告によります。<br />
-    <a href="http://www.pgpool.net/mantisbt/view.php?id=114">
-    http://www.pgpool.net/mantisbt/view.php?id=114
-    </a>
-    </blockquote>
-</li>
-
-
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.3.4"></a>3.3.4 (tokakiboshi) 2014/09/05</h2>
-<!-- -------------------------------------------------------------------------------- -->
-
-<h3>概要</h3>
-<p>
-このバージョンは 3.3.3 に対するバグ修正リリースです。
-</p>
-
-<h3>バグ修正</h3>
-<ul>
-
-<li>
-    pgpool.spec のタイポを修正しました。(Yugo Nagata)
-</li>
-
-<li>
-    プライマリバックエンドが存在しない場合に、ワーカー子プロセスが終了と再起動を繰り返すバグを修正しました。(Tatsuo Ishii)
-    <p>
-    問題の同定と修正は Junegunn Choi さんの貢献によります。
-    </p>
-    <p>
-    詳しくは、[pgpool-hackers: 471] を参照してください。
-    </p>
-</li>
-
-<li>
-    スマートシャットダウンの実行時には受信用ソケットを閉じるように修正しました。(Tatsuo Ishii)
-    <p>
-    スマートシャットダウンが実行された場合でも、pgpool の子プロセスは受信用のポートを開いており、最終的に失敗するにもかからわずクライアントは接続要求を送信可能です。これは時間の無駄であるだけではなく、pgpool のフロントにいるロードバランサによる pgpool の停止の検出を妨げます。
-    </p>
-    <p>
-    この問題は [pgpool-hackers 474] にて Junegunn Choi によって解析され、パッチが提供されました。これを Tatsuo Ishii が改良し、inet ドメインだけではなく UNIX ドメインのソケットにも対応させました。
-    </p>
-</li>
-
-<li>
-    doc: PostgreSQL の statement_timeout によって、リカバリコマンドが終了させられる可能性を追記しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    test: wait_for_pgpool_startup 関数が正しく動いていなかったのを修正しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    test: watchdog のテストドライバが wait_for_pgpool_startup 関数を正しく使用するように修正しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    ifconfig コマンドの実行時に無害なエラーコードを無視するよう修正しました。(Yugo Nagata)
-    <p>
-    Linux で SIGCHLD のハンドラが SIG_IGN となっている場合、fork した子プロセスの中で execv() を用いて ifconfig や ping などのコマンドを実行した結果、wait()が実際にはプロセスが正常終了しているにもかからわず、エラーコード ECHILD で失敗する場合があります。このエラーは無視して、コマンドの実行は成功とみなすよう修正しました。
-    </p>
-</li>
-
-<li>
-    test: スクリプトのコメントに記載漏れのあった -j オプションの説明を追記しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    test: JDBC のレグレッションテストが想定外の失敗するのを修正しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    test: 遅いマシンでレグレッションテストが失敗しないよう修正しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    test: PostgreSQL ライブラリのディレクトリを環境変数で指定できるようになりました。(Tatsuo Ishii)
-</li>
-
-<li>
-    to_regclass 関数を持つ PostgreSQL 9.4 に対応しました。(Tatsuo Ishii)
-    <p>
-    PostgreSQL 9.4 は pgpool_regclass と同じ機能を持つ組み込み関数to_regclass を持っています。そのため、pgpool はまず to_regclassを探し、その後に pgpool_regclass を探すようになりました。
-    </p>
-</li>
-
-<li>
-    SO_REUSEPORT に関するコードの移植性の問題を修正しました。(Tatsuo Ishii)
-    <p>
-    何か所かで、setsockopt(sock, SOL_SOCKET, SO_REUSEPORT...) を使用していますが、SO_REUSEPORT は全ての Linux カーネルで使用可能ではありません。そのためコンパイル時に ifdef を用いて機能の有無を判断していました。しかし、あるカーネルで作成したバイナリが他のカーネルで実行できないという問題があったため、setsockopt() が返すエラーコードを用いて実行時に機能の有無を判断するように修正しました。
-    </p>
-</li>
-
-<li>
-    dic: 現在は当てはまらない古い制限事項を削除しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    text_to_lsn() 関数の返却値型を修正しました。(Yugo Nagata)
-    <p>
-    コンパイル時の警告の原因となっていました。
-    </p>
-</li>
-
-<li>
-    デーモン化した際にファイル識別子が閉じられていなかったのを修正しました。(Tatsuo Ishii)
-    <p>
-    Coverity の報告 #1111471 によります。
-    </p>
-</li>
-
-<li>
-    メモリリークを修正しました。 (Tatsuo Ishii)
-    <p>
-    Coverity の報告 #1111442 によります。
-    </p>
-</li>
-
-<li>
-    長らく放置されていた pgool.init の stop/restart のバグを修正しました。(Yugo Nagata)
-    <p>
-    以前は pgpool の停止に pgpool.init は killproc を用いていましたが、これにはいくつか問題がありました。これを、"pgpool -m fast stop" を用いるように修正しました。
-    </p>
-    <p>
-    Ryan DeShone により提供されたパッチを Yugo Nagata が修正しました。
-    </p>
-    <p>
-    詳しくは、[pgpool-hackers: 239][pgpool-hackers: 512] を参照してください。
-    </p>
-</li>
-
-<li>
-    pgpool_setup とレグレッションテストが Ubuntu で動くよう修正しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    test: -i オプション（pgpool インストールディレクトリの指定）が動作していなかったのを修正しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    不足していたインクルードファイル sys/wait.h を追加しました。(Tatsuo Ishii)
-    <blockquote>
-    bug #104 の報告によります。<br />
-    <a href="http://www.pgpool.net/mantisbt/view.php?id=104">
-    http://www.pgpool.net/mantisbt/view.php?id=104
-    </a>
-    </blockquote>
-</li>
-
-<li>
-    仮想IPの切り替わり時に、新しいアクティブ pgpool で起こる ping エラーの無限ループを修正しました。(Yugo Nagata)
-    <p>
-    また、新アクティブが無限ループにより応答できなくなるため、これの応答を待っている旧アクティブ pgpool がハングする原因にもなっていました。
-    </p>
-    <p>
-    この問題は [pgpool-hackers: 520] にて Qian Peng により報告されました。
-    </p>
-</li>
-
-<li>
-    オンラインリカバリの実行時は PostgreSQL の statement_timeout を無効にするようになりました。(Tatsuo Ishii)
-    <p>
-    オンラインリカバリは異常に長い時間を要する可能性がある一方、ユーザは statement_timeout を有効にしている可能性があります。これによりオンラインリカバリがキャンセルされるのを防ぐため、リカバリの最中は statement_timeout を無効にするようになりました。
-    </p>
-    <p>
-    詳しくは [pgpool-general: 2919] を参照してください。
-    </p>
-</li>
-
-<li>
-    pool_table_nameto_oid 関数が PostgreSQL 9.4 で導入された to_regclass を使えるように修正しました。(Tatsuo Ishii)
-    <p>
-    ここで用いる relcache 関数は、対象のテーブルが存在しない場合は 0 を返す必要がありますが、to_regclass はこの場合 NULL を返します。これに対処するため COALESCE を用いるように修正しました。
-    </p>
-</li>
-
-<li>
-    test: PostgreSQL 9.4 以降でレグレッションテスト #057 がハングするバグを修正しました。(Tatsuo Ishii)
-    <p>
-    PostgreSQL 9.4 以降では libpq の振る舞いに変化があり、接続文字列のusername が NULL の場合でもエラーになりません。以前のテストはエラーになることが前提となっていました。
-    </p>
-</li>
-
-<li>
-    ping コマンド失敗時にパイプを閉じるように修正しました。(Yugo Nagata)
-    <p>
-    このバグにより "pipe open error: Too many open files" を引き起こすため、watchdog 有効時に上位サーバへの接続確認が失敗し、その結果 pgpool がダウンステータスとなってしまうことがありました。
-    </p>
-</li>
-
-<li>
-    リソースリークを修正しました。(Muhanmmad Muhammad Usama)
-    <p>
-    Coverity の報告 #1222998, #1222999 によります。
-    </p>
-</li>
-
-<li>
-    pcp_detach_node コマンドが接続中のセッションを切断することを記載しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    pgpool_setup が生成する failover.sh を修正しました。(Tatsuo Ishii)
-    <p>
-    常に node0 か node1 を昇格させようとしており、3 ノード以上の構成に対応していませんでした。
-    </p>
-</li>
-
-<li>
-    unsigned int 変数の意味の無い符号のチェックを取り除きました。(Tatsuo Ishii)
-    <p>
-    Coverity の報告 #1111419, #1111420, #1111422 によります。
-    </p>
-</li>
-
-<li>
-    strcpy() をより安全で推奨される strlcpy() に置き換えました。(Muhammad Muhammad Usama)
-    <p>
-    Coverity の報告 #1111480 によります。
-    </p>
-</li>
-
-<li>
-    openssl に対応させるよう pgpool.spec を修正しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    pgpool.spec が 3.3-stable ツリーの head を使用するよう修正しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    不適切にセマフォを削除しないよう不必要な pool_shmem_exit() 呼び出しを取り除きました。(Tatsuo Ishii)
-    <p>
-    exit_handler はプロセスが親プロセスがどうかをチェックしていますが、子プロセスであった場合にも pool_shmem_exit() が呼ばれることがあり、これにより不適切にセマフォが削除されていました。この関数は親プロセス以外に呼ばれてはなりません。
-    </p>
-    <blockquote>
-    bug #102 によります。<br />
-    <a href="http://www.pgpool.net/mantisbt/view.php?id=102">
-    http://www.pgpool.net/mantisbt/view.php?id=102
-    </a>
-    </blockquote>
-</li>
-
-<li>
-    get_insert_command_tabel_name() 関数が解放済ポインタを使用しないよう修正しました。(Muhammad Usama)
-    <p>
-    Coverity の報告 #1223007 によります。
-    </p>
-</li>
-
-<li>
-    pool_handle_query_cache() 関数が NULL ポインタを解放しないよう修正しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    頼りないネットワークのため、connect() のタイムアウトを長め（10秒）に変更しました。(Tatsuo Ishii)
-    <p>
-    AWS などの頼りないネットワークに対応するため、connect_inet_domain_socket_by_port()の中の connect()のタイムアウトを１秒から10秒に変更しました。これにより頻発していたフェイルオーバを減らすことができます。
-    </p>
-</li>
-
-<li>
-    リセット用クエリにより発生するハングを修正しました。(Tatsuo Ishii)
-    <p>
-    DISCARD ALL などのリセットクエリが完了せず、pgpool の子プロセスがバックエンドからの反応を待ったまま固まってしまい、新しいクライアントからの接続が受けられなくなる問題が報告されました。
-    </p>
-    <p>
-    原因はまだ特定されていませんが、クライアントの接続がクエリ処理の最中に突然切断された場合、バックエンドがクエリを処理できない状態となり、リセットクエリを受け付けられなくのかもしれません。
-    </p>
-    <p>
-    これに対処するため、フロントエンドから接続が予期せず切断された場合は、クエリ処理ループを即座に終了し PostgreSQL への接続を切断し、新しい接続要求を待つように修正しました。
-    </p>
-    <p>
-    また client_idle_limit が設定されており、リミットに達した場合にもpgpool はバックエンドへの接続を切断するよう修正されました。
-    </p>
-    <blockquote>
-    bug #107 の報告によります。<br />
-    <a href="http://www.pgpool.net/mantisbt/view.php?id=107">
-    http://www.pgpool.net/mantisbt/view.php?id=107
-    </a>
-    </blockquote>
-</li>
-
-<li>
-    その他の何十もの Coverity 報告バグが修正されました。(Muhammad Usama)
-</li>
-
-
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.3.3"></a>3.3.3 (tokakiboshi) 2014/03/24</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<p>
-このバージョンは 3.3.2 に対するバグ修正リリースです。
-</p>
-
-<h3>バグ修正</h3>
-<ul>
-
-<li>
-    installer: pgpool-II の RPM インストールが失敗するバグを修正しました。
-    (Yugo Nagata)
-</li>
-
-<li>
-    installer: localhost の apache ユーザから localhost の postgres ユーザにパスワードなし
-    SSH を設定するするように修正しました。(Yugo Nagata)
-</li>
-
-<li>
-    再起動した pgpool-II の watchdog ステータスがダウンと見なされることがあるバグを修正しました。
-    (Yugo Nagata)
-</li>
-
-<li>
-    doc: num_init_children の項に「listen キュー」の説明とその「バックログ」を増やす方法について追記しました。
-    (Tatsuo Ishii)
-</li>
-
-<li>
-    指定した上位サーバの内たった１台への ping が失敗した場合にも watchdog
-    ステータスがダウンになってしまうバグを修正しました。(Yugo Nagata)
-</li>
-
-<li>
-    UNLOGGED テーブルを検出する処理のパフォーマンスが悪かったのを修正しました。
-    (Tatsuo Ishii)
-    <p>
-    この問題は <a href="http://www.sraoss.jp/pipermail/pgpool-hackers/2014-January/000435.html">[pgpool-hackers: 435]</a>
-    <a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-December/002354.html">[pgpool-general:2325]</a> で指摘されました。
-    </p>
-</li>
-
-<li>
-    プライマリノードの検出ロジックを修正しました。(Tatsuo Ishii)
-    <p>
-    プライマリノードが検出されないことがありました。例えば、node 0 がプライマリ、node 1
-    がスタンバイのときに、node 0 が落ちたとします。ヘルスチェックがそれを検出しますが、
-    内部のステータスがまだ更新されていない場合 node 0 には問題がないよう見えるため node 0
-    への接続が試みられます。実際にはこの接続は失敗するため、node 1
-    が新プライマリであることを検出する前に処理が終了していました。
-    </p>
-    <p>
-    この問題は <a href="http://www.sraoss.jp/pipermail/pgpool-general/2014-January/002442.html">[pgpool-general: 2409]</a> にて報告されました。
-    </p>
-</li>
-
-<li>
-    pgpool_setup が raw モードに対応しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    test: JDBC のテストをレグレッションテストに統合しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    raw モードで自動コミットが off で JDBC を使用したときに、DML
-    が失敗するバグを修正しました。(Tatsuo Ishii)
-    <p>
-    この問題は <a href="http://www.pgpool.net/mantisbt/view.php?id=92">bug #92</a> で報告されました。
-    </p>
-</li>
-
-<li>
-    wd_escalation_command が終了コード 0
-    以外で終了したときにエラーメッセージを出力するように修正しました。(Yugo Nagata)
-    <p>
-    この修正は <a href="http://www.sraoss.jp/pipermail/pgpool-general/2014-January/002492.html">
-    [pgpool-general: 2457]</a> で Sergey Arlashin によって示唆されました。
-    </p>
-</li>
-
-<li>
-    test: クエリキャッシュのレグレッションテストを追加しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    拡張プロトコルにおけるクエリキャッシュのバグを修正しました。(Tatsuo Ishii)
-    <p>
-    明示的なトランザクション内で DML が実行された場合でも、SELECT
-    実行時に古いキャッシュが読み込まれていました。
-    これはインメモリクエリキャッシュが実装された時点から存在していたバグです。
-    </p>
-    <p>
-    <a href="http://www.sraoss.jp/pipermail/pgpool-general-jp/2014-January/001251.html">
-    [pgpool-general-jp: 1252]</a> で報告されました。
-    </p>
-</li>
-
-<li>
-    SHOW pool_status の結果から抜けていた relcashe_size と check_temp_table
-    を追加しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    if_up_cmd が失敗した際にエラーメッセージを出力するよう修正しました。(Yugo Nagata)
-    <p>
-    この修正は <a href="http://www.sraoss.jp/pipermail/pgpool-general/2014-January/002492.html">
-    [pgpool-general: 2457]</a> で Sergey Arlashin によって示唆されました。
-    </p>
-</li>
-
-<li>
-    ストリーミングレプリケーションモードで無関係なノードにはクエリを送信しないように修正しました。
-    (Tatsuo Ishii)
-    <p>
-    pgpool-II は BEGIN, END, SET などのクエリを全ての DB ノードに送っています。
-    しかし、ストリーミングレプリケーションではプライマリノードと高々１台のスタンバイノードにしか送る必要がありません。
-    （もしプライマリノードがロードバランスノードとして選択されている場合には１台だけで充分です。）
-    </p>
-    <p>
-    詳細は <a href="http://www.sraoss.jp/pipermail/pgpool-hackers/2014-February/000464.html">
-    [pgpool-hackers: 464]</a> を参照してください。
-    </p>
-</li>
-
-<li>
-    バッファオーバランとメモリリークの可能性を修正しました。(Tatsuo Ishii)
-    <p>
-    Coverity 1111465, 1111482 の報告によります。
-    </p>
-</li>
-
-<li>
-    バッファオーバランを修正しました。(Tatsuo Ishii)
-    <p>
-    strcpy() を strlcpy() で置き換えました。Coverity 1111478, 1111480 の報告によります。
-    </p>
-</li>
-
-<li>
-    if_up_cmd のエラーを解析するためのデバッグメッセージを追加しました。(Yugo Nagata)
-</li>
-
-<li>
-    NULL ポインタの解放を修正しました。(Tatsuo Ishii)
-    <p>
-    Coverity 1111384 の報告によります。
-    </p>
-</li>
-
-<li>
-    マテリアライズドビューをキャッシュしないよう修正しました。(Tatsuo Ishii)
-    <p>
-    <a href="http://www.pgpool.net/mantisbt/view.php?id=92">bug #95</a> で報告されました。
-    </p>
-</li>
-
-<li>
-    メモリリークを修正しました。(Tatsuo Ishii)
-    <p>
-    Coverity 1111446 の報告によります。
-    </p>
-</li>
-
-<li>
-    パラレルモードで system_db_hostname
-    が空欄の場合に発生するセグメンテーションフォルトを修正しました。
-    (Yugo Nagata)
-</li>
-
-<li>
-    -d オプションで起動した場合に pgpool.conf
-    の処理中のデバッグメッセージを出力するように修正しました
-    (Yugo Nagata)
-    <p>
-    以前は -d オプション使用時でも出力されていないデバッグメッセージがありました。
-    </p>
-</li>
-
-<li>
-    レプリケーションモードで JDBC 使用時に now()
-    を含む準備文で発生する例外を修正しました。(Yugo Nagata)
-    <p>
-    JDBC で準備文を PrepareThreshold 回以上実行した場合には、文に名前が付けられ Parse
-    の後に Describe メッセージが発行されます。このとき、pgpool は now()
-    をパラメータに書き換えるため、元のクエリには無かった新しいパラメータが追加されます。
-    この場合、フロントエンドに返されるParameterDscription メッセージ（Describe
-    の返答）は、元のクエリが持つパラメータと同じ数の OID を含むべきです。そうしないと、JDBC
-    はArrayIndexoutOfBoundsException 例外を発生させてしまいます。
-    </p>
-    <p>
-    このバグは <a href="http://www.sraoss.jp/pipermail/pgpool-general-jp/2013-September/001191.html">
-    [pgpool-general-jp: 1192]</a> で報告されました。
-    </p>
-</li>
-
-<li>
-    レプリケーションモードにて、デフォルト値が now()
-    のカラムを持つテーブルに対する準備文でエラーが発生するバグを修正しました。
-    (Yugo Nagata)
-    <p>
-    デフォルト値が now() を持つ名前付き準備文を parse する際に、pgpool-II
-    は時刻値をパラメータで置き換えます。そのため、その後の bind
-    メッセージも追加されたパラメータの形式コードを含んでいる必要があります。
-    しかし、元のクエリのパラーメータ形式数が１だった場合、この処理がなされていませんでした。これが
-    "incorrect binary data format in bind parameter 2" のようなエラーの原因となっていました。
-    </p>
-</li>
-
-<li>
-    test: JDBC のレグレッションテストでテスト失敗時でも ok と出力されるバグを修正しました。
-    (Yugo Nagata)
-</li>
-
-<li>
-    test: JDBC の PrepareThreshold に関するレグレッションテストを追加しました。(Yugo Nagata)
-</li>
-
-<li>
-    doc: パラレルモードは PREPARE 文の実行に対応していないことを追記しました。(Yugo Nagata)
-    <p>
-    <a href="http://www.pgpool.net/mantisbt/view.php?id=93">bug #93</a> の指摘によります。
-    </p>
-</li>
-
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.3.2"></a>3.3.2 (tokakiboshi) 2013/11/29</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<p>
-このバージョンは 3.3.1 に対するバグ修正リリースです。
-</p>
-<h3>バグ修正</h3>
-<ul>
-
-<li>レプリケーションモード稼働時、一部のタイムゾーンでタイムスタンプの書き換えが誤っていました。(Tatsuo Ishii)
-<p>タイムスタンプの書き換え処理では、現在日時を取得するために "SELECT now()" を実行します。
-しかし一部のタイムゾーンにおいては、"02:30" のような場合に現在日時のためのバッファの大きさが
-十分ではありませんでした。"0900" のように 30 分刻みでのタイムゾーンでないときは、この問題は発生しません。
-そのため、これまでこの不具合が報告されたことはありませんでした。</p>
-<p>この不具合は <a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-September/002142.html" target="_blank">[pgpool-general: 2113]</a> で報告され、Sean Hogan さんによって修正が提供されました。</p>
-</li>
-
-<li>installer: redhat/rpm_installer/getsources.sh での pgpoolAdmin の
-バージョン指定方法を修正しました。 (Yugo Nagata)
-</li>
-
-<li>Makefile: Makefiles 内の pg_config を $(PG_CONFIG) に置き換えました。
-したがって、PostgreSQL のメジャーバージョンが異なる場合には、コンパイル中で上書きされるようになります。(Tatsuo Ishii)
-<p>パッチは Christoph Berg さんから提供されました。（<a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-September/002156.html" target="_blank">[pgpool-general: 2127]</a>）</p>
-</li>
-
-<li>watchdog: <code>-Werror=format-security</code> をつけてコンパイルしたときの、warning/error を修正しました。(Tatsuo Ishii)
-<p>パッチは Christoph Berg さんから提供されました。（<a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-September/002156.html" target="_blank">[pgpool-general: 2127]</a>）</p>
-</li>
-
-<li>configure: FreeBSD で問題があったため、-lcompat を削除しました。(Tatsuo Ishii)
-<p><a href="http://www.pgpool.net/mantisbt/view.php?id=15">bug#15</a> で報告されました。</p>
-</li>
-
-<li>pgpool.conf で <a href="#LOG_STANDBY_DELAY">log_standby_delay</a> を設定してないときに
-segfault していたのを修正しました。(Tatsuo Ishii)
-<p>これは、pool_config.l での log_standby_delay の初期化が誤っていたためです。
-<a href="http://www.pgpool.net/mantisbt/view.php?id=74" target="_blank">bug#74</a> として報告されました。</p>
-</li>
-
-<li>doc: パラレルモードの制限事項を追記しました。VALUES 句を使った複数行の INSERT はパラレルモードではサポートされていません。(Yugo Nagata)</li>
-
-<li>スタンバイノードがダウンしようとしているときに find_primary_node_repeatedly() が
-呼ばれないようにしました。(Tatsuo Ishii)
-<p>これによってフェイルオーバの所要時間が短くなります。
-<a href="http://www.pgpool.net/mantisbt/view.php?id=75" target="_blank">bug#75</a> として報告され、
-パッチを Tatsuo Ishii が編集しました。</p>
-</li>
-
-<li>レプリケーションモードと拡張プロトコルを組み合わせた場合に、
-データ不整合があったのでこれを修正しました。(Tatsuo Ishii)
-<p>JDBC ドライバを使った同時 INSERT で、ノード間でのデータ不整合があるという報告がありました。
-この事象は以下の条件で必ず発生します。
-</p>
-<ol>
-    <li>レプリケーションモードを使用している</li>
-    <li>拡張プロトコルを使用している</li>
-    <li>parse で作成された portal が bind で再利用される</li>
-    <li>autocommit が on である</li>
-    <li>SERIAL（シーケンス）を使用している</li>
-</ol>
-
-<p>pgpool-II の parse 関数は、クライアントが INSERT (+ 5 の状態）を発行すると、対象テーブルをロックされていることを
-認識しています。しかし、bind 関数はそれを認識していませんでした。
-一度 parse / bind / execute が完了すると、pgpool は 4 の理由により parse で獲得したロックを解放します。
-そして JDBC は portal を再利用しようとし、ロックを獲得しないまま bind からのサイクルを開始してしまいます。
-その結果、ロックのない INSERT がノード間でのデータ不整合を引き起こします。
-この解決方法としては、bind でテーブルをロックするようにしました。
-</p>
-<p>この問題は、たいていのユーザは JDBC を autocommit = off で使っているために、
-今まで報告されることがありませんでした。off であれば、ユーザが commit / rollback を発行するまで、
-parse によるロックが残存するためです。</p>
-<p>この不具合は Steve Kuekes さんにより、<a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-September/002171.html" target="_blank">[pgpool-general: 2142]</a> で報告されました。</p>
-</li>
-
-<li>クエリキャッシュにおけるメモリ確保サイズの不具合を修正しました。(Tatsuo Ishii)
-<p>execute() において、メモリ確保サイズが一部の場合において小さすぎました。</p>
-</li>
-
-<li>クエリキャッシュ + 拡張プロトコルの組み合わせで使っている場合に、segfault する可能性があったのを
-修正しました。(Tatsuo Ishii)
-<p>クエリが "cache safe" でないときに、bind_msg-&gt;param_offset が Bind() でセットされていませんでした。
-しかし Execute() では無条件に bind_msg-&gt;param_offset を使おうとしていました。
-</p>
-<p>この不具合は <a href="http://www.pgpool.net/mantisbt/view.php?id=76" target="_blank">bug#76</a> で報告されました。</p>
-</li>
-
-<li>クエリキャッシュの hash index エントリがいっぱいにならないようにしました。(Tatsuo Ishii)
-<p>hash index エントリがいっぱいになると、pgpool-II は hash index の残りが少なくとも 1 つはある前提だったため、
-古いキャッシュエントリを再利用できませんでした。
-これを改善するために、hash index エントリがいっぱいになったら、再利用できるキャッシュブロックを
-探すようにしました。</p>
-<p>この不具合は <a href="http://www.pgpool.net/mantisbt/view.php?id=70" target="_blank">bug#70</a> で報告されました。</p>
-</li>
-
-<li>installer: checkEnv() が何もせず必ず 0（成功）を返していました。(Nozomi Anzai)</li>
-
-<li>clock hand の不適切なサイズの共有メモリ確保を修正しました。(Tatsuo Ishii)
-<p>clock hand のメモリは、sizeof(pool_fsmm_clock_hand) 分確保されており、
-この変数が「<code>static int *pool_fsmm_clock_hand</code>」と定義されていることから、8 バイトでした。</p>
-<p>しかしこれは誤りで、実際に必要なのは「<code>sizeof(*pool_fsmm_clock_hand)</code>」での 4 バイトでした。</p>
-<p>これは Coverity "1111476 Wrong sizeof argument" で発見されました。</p>
-</li>
-
-<li>"<a href="#pool_status">show pool_status</a>" で
-<a href="#MEMQCACHE_AUTO_CACHE_INVALIDATION">memqcache_auto_cache_invalidation</a> が常に
-0 と表示されていました。 (Tatsuo Ishii)
-<p>この不具合は <a href="http://www.pgpool.net/mantisbt/view.php?id=80" target="_blank">bug#80</a> で報告されました。</p>
-</li>
-
-<li>read_password_packet() のエラーメッセージを修正しました。(Tatsuo Ishii)</li>
-
-<li>watchdog: 一部関数で、引数を指定するのに大きな値そのものを渡さず、そのポインタを渡すようにしました。
-(Yugo Nagata)</li>
-
-<li>SSL 要求でのメモリリークを修正しました。(Tatsuo Ishii)
-<p>SSL での要求があったとき、pgpool 子プロセスは start up packet の読み込みをリトライしていました。
-しかし子プロセスは、以前の start up packet のメモリを解放していませんでした。</p>
-<p>これは Coverity "1111443 Resource" で発見されました。</p>
-</li>
-
-<li>do_query() がタイムスタンプの書き換えに失敗したとき、メモリリークしていました。(Tatsuo Ishii)
-<p>この修正のために、free_select_result() で NULL 引数を受け取れるようにしました。</p>
-<p>これは Coverity "1111454, 1111455 Resource leak" で発見されました。</p>
-</li>
-
-<li>レプリケーションモードでのロードバランスにおける不具合を修正しました。(Tatsuo Ishii)
-<p>load_balance_mode = off のとき、書き込みを関数を使った SELECT はすべての DB ノードに送られるべきでした。</p>
-<p>これは <a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-October/002250.html" target="_blank">
-[pgpool-general: 2221]</a> で報告されました。
-また、この不具合は <a href="http://git.postgresql.org/gitweb/?p=pgpool2.git;a=commitdiff;h=1ac45a28258074ea4d9d902aca016f970d31f311" target="_blank">3.3.1</a> で混入しました。
-</p>
-</li>
-
-<li>watchdog: ping 結果を格納する文字列で、終端に NULL 文字を追加しました。（Yugo Nagata)</li>
-
-<li>"<code>DEALLOCATE portal|statement</code>" 実行時の対象ノードの選定ロジックを修正しました。(Tatsuo Ishii)
-<p>"<code>DEALLOCATE portal|statement</code>" 実行時、最後の prepared statement や portal が見つからない場合に、
-対象ノード選定マップがセットされていませんでした。
-おそらく、そうした場合はエラーなので、実際には問題ありません。</p>
-<p>これは Coverity "1111491 Structurally dead code" で発見されました。</p>
-</li>
-
-<li>MAX_NUM_BACKENDS の範囲チェックにおける不具合を修正しました。 (Tatsuo Ishii)
-<p>MAX_NUM_BACKENDS は DB ノードの最大数が限界値でした（現時点では 128）。
-実際には 128 の DB ノードで試す人がいなかったために、発見されなかった不具合のようです。</p>
-<p>これは Coverity "1111429, 1111430 and 1111431 Out-of-bounds write" で発見されました。</p>
-</li>
-
-<li>フロントエンド接続情報を、すでに無効なバックエンドについて set/unset しないようにしました。(Tatsuo Ishii)
-<p>この不具合は <a href="http://www.pgpool.net/mantisbt/view.php?id=82" target="_blank">bug#82</a> で報告されました。</p>
-</li>
-
-<li>pgpool_catalog への public access を許可していませんでした。
-<p>これは、pgpool_catalog がレプリケーションモードで作成されている場合に、
-ユーザテーブルにデータを INSERT すると発生します。</p>
-<p>この不具合は <a href="http://www.sraoss.jp/pipermail/pgpool-general-jp/2013-November/001228.html" target="_blank">[pgpool-general-jp: 1229]</a> で報告されました。</p>
-</li>
-
-<li>doc: <a href="#TRUSTED_SERVERS">trusted_servers</a> に複数のサーバを指定すべきであることを記述しました。
-(Yugo Nagata)</li>
-
-<li>pool_do_auth() のエラーケースで変数を初期化していませんでした。 (Tatsuo Ishii)
-<p>有効なバックエンドがいないとき、pgpool は認証フェーズのフロントエンドにごみの pid を返していました。
-実際に、有効なバックエンドがいないために、フロントエンドは認証後に接続することができません。
-もちろんこれは問題あるものではありません。</p>
-<p>これは Coverity "1127331 Uninitialized scalar variable" で発見されました。</p>
-</li>
-
-<li>ノード ID を使ったエラーメッセージの発行時に、ノード ID の範囲チェックをするようにしました。
-(Tatsuo Ishii)
-<p>これは Coverity "1111433 "Out-of-bounds read" で発見されました。</p>
-</li>
-
-<li>parse_copy_data() でのバッファオーバーランとリソースリークを修正しました。 (Tatsuo Ishii)
-<p>これは Coverity "1111427 Out-of-bounds write"、"1111453 Resource leak" で発見されました。</p>
-</li>
-
-<li>CopyDataRaws() で segfault する可能性があったのを修正しました。(Tatsuo Ishii)
-<p>pool_get_id() がエラーを返した場合に VALID_BACKEND が配列外にアクセスしようとしていました。</p>
-<p>これは Coverity "1111433 Out-of-bounds read" で発見されました。</p>
-</li>
-
-<li>クエリキャッシュ有効 + プロトコルバージョン = 2 の組み合わせでの処理を修正しました。(Tatsuo Ishii)
-<p>プロトコルバージョンが 2 のとき、セッション状態が "idle" である前提でしたが、
-実際にはそうではありませんでした。
-プロトコルバージョンが 2 の場合はクエリキャッシュを使用しないことをおすすめします。</p>
-<p>これは Coverity "1111488 Uninitialized scalar variable" で発見されました。</p>
-</li>
-
-<li>pool_pools() での strftime() の用法を修正しました。(Tatsuo Ishii)
-<p>バッファが第 2 引数で期待する値にたいして十分な大きさではありませんでした。
-実際にはそのような長い値がわたることはなく、問題ないものです。</p>
-<p>これは Coverity "1111426 Out-of-bounds access" で発見されました。</p>
-</li>
-
-<li>RPM: spec ファイルで、pgpool-II と PostgreSQL のバージョンを指定できるようにしました。(Nozomi Anzai)</li>
-
-<li>make_persistent_db_connection のリソースリークを修正しました。(Tatsuo Ishii)
-<p>この修正ののために、新しく free_persisten_db_connection_memory 関数を追加しました。</p>
-<p>これは Coverity #1111468 で発見されました。</p>
-</li>
-
-<li>watchdog: RTT が非常に短いときに <a href="#TRUSTED_SERVERS">trusted servers</a> への
-コネクションチェックに失敗する不具合をを、修正しました。(Yugo Nagata)
-</li>
-
-<li>Coverity で見つかったさまざまな不具合を修正しました。(Tatsuo Ishii)</li>
-
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.3.1"></a>3.3.1 (tokakiboshi) 2013/09/06</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<p>
-このバージョンは 3.3.0 に対するバグ修正リリースです。
-</p>
-
-<h3>バグ修正</h3>
-<ul>
-
-<li>
-    tar ball 作成時にレグレッションテストを含めるよう修正しました。(Tatsuo Ishii)
-    <p>
-    3.3.0 リリースの tar ball にはレグレッションテストが含まれていませんでした。
-    </p>
-</li>
-
-<li>
-    レグレッションテストの watchdog テストスクリプトを修正しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    メモリオーバーランを修正しました。(Tatsuo Ishii)
-    <p>
-    このバグは [pgpool-general: 1956] で Sean Hogan さんにより指摘されました。
-    </p>
-    <blockquote>
-    [pgpool-general: 1956] memory overrun bug?<br />
-    <a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-July/001984.html">
-    http://www.sraoss.jp/pipermail/pgpool-general/2013-July/001984.html
-    </a>
-    </blockquote>
-</li>
-
-<li>
-    コンパイル時のエラーを修正しました。(Yugo Nagata)
-</li>
-
-<li>
-    インメモリクエリキャッシュ使用時に子プロセスが sig abort で異常終了するバグを修正しました。
-    (Tatsuo Ishii)
-    <p>
-    parse メッセージの後に複数の bind/execute メッセージが来た場合に発生していた、メモリの二重解放がこのバグの原因です。
-    parse メッセージが来ると、クエリコンテキストと共に一時的なキャッシュが作成され、
-    クエリの実行時にこの一時キャッシュを指すポインタが配列に追加されます。そして、続く複数の bind
-    メッセージがこの同じポインタを使用することが、キャッシュ削除の際に二重解放を引き起こす原因となっていました。
-    </p>
-    <p>
-    このバグはバグトラック #68 にて harukat さんにより報告されました。
-    </p>
-    <blockquote>
-    #68: child process termination with sigabort when memory_cache_enabled = on<br />
-    <a href="http://www.pgpool.net/mantisbt/view.php?id=68">
-    http://www.pgpool.net/mantisbt/view.php?id=68
-    </a>
-    </blockquote>
-</li>
-
-<li>
-    いくつかのテストケースをレグレッションテストに追加しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    ドキュメントの pgpool-recovery のインストールの節の typo を修正しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    ログメッセージの typo を修正しました。 (Yugo Nagata)
-</li>
-
-<li>
-    日本語ドキュメントの typo を修正しました。 (Yugo Nagata)
-</li>
-
-<li>
-    レプリケーションモードにてロードバランスモードが off の場合には、SELECT
-    クエリをマスターノードにのみ送信するよう修正しました。(Tatsuo Ishii)
-    <p>
-    レプリケーションモードでロードバランスモードが off の場合には、明示的なトランザクションの中で
-    SELECT クエリは、全てのノードにではなく、マスターノードにのみ送られなくてはなりません。
-    </p>
-    <p>
-    このバグは [pgpool-general: 2038] にて Rypl Lukas さんにより報告されました。
-    </p>
-    <blockquote>
-    [pgpool-general: 2038] SELECT sent to both nodes in replication mode<br />
-    <a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-August/002066.html">
-    http://www.sraoss.jp/pipermail/pgpool-general/2013-August/002066.html
-    </a>
-    </blockquote>
-</li>
-
-<li>
-    pgpool_setup が単独で動作しなくなっていたのを修正しました。(Tatsuo Ishii)
-</li>
-
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.3.0"></a>3.3.0 (tokakiboshi) 2013/07/30</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<p>
-このバージョンは 3.3 系列の最初の版で、3.2 系からの「メジャーバージョンアップ」にあたります。
-</p>
-
-<h3>互換性のない変更</h3>
-
-<p>以下は全て watchdog に関する変更です。詳細は以下の<a href="3.3_new_features">新機能</a>の項目を
-参照してください。</p>
-
-<ul>
-    <li>デフォルトの監視方法がクエリモードからハートビートモードに変更されました。</li>
-
-    <li>failover/failback コマンドが１つの pgpool-II でのみ実行されるようになりました。</li>
-
-    <li>デフォルトで、アクティブ pgpool-II への昇格時には共有メモリ内のクエリキャッシュを
-    全て削除するようになりました。</li>
-
-    <li>クエリモードで他の pgpool-II を監視する際に用いられるデータベース名、ユーザ名、パスワードは
-        専用のパラメータで指定されるようになりました。
-        以前は template1, <a href="#RECOVERY_USER">recovery_user</a>,
-        <a href="#RECOVERY_PASSWORD">recovery_password </a> が使われていました。</li>
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h3 id="3.3_new_features">新機能</h3>
-<h4>watchdog</h4>
-
-<ul>
-<li>UDP のパケットのハートビート信号を用いた新しい監視方法が追加されました。(Yugo Nagata)
-    <p>「ハートビート」モードと「クエリ」モードのから監視方法を選ぶことができます。</p>
-
-    <dl>
-    <dt>ハートビートモード</dt>
-    <dd>
-        <p>ハートビートモードは今回新しく追加された方法です。</p>
-        <p>
-        このモードでは、watchdog はハートビート信号を用いて 他の pgpool-II プロセスの死活監視を行います。
-        watchdog は、他の pgpool-II の watchdog より定期的に送られるハートビート信号を受け取り、
-        これが一定期間以上途切れた場合にはその pgpool-II プロセスに障害が発生したと判断します。
-        </p>
-        <p>冗長性を高めるため、複数のネットワーク用いたハートビート交換が可能です。</p>
-        <p>デフォルトではこのモードで動作し、これが推奨設定です。</p>
-    </dd>
-    <dt>クエリモード</dt>
-    <dd>
-        <p>
-        クエリモードでは従来と同じ動作になります。
-        このモードではwatchdog は pgpool-II のプロセスではなく「サービス」の応答を監視します。
-        このモードでは、監視対象の pgpool-II にクエリを発行しその応答をチェックします。
-        </p>
-        <p>
-        この方法では他の pgpool-II から接続を受ける必要があるため、
-        <a href="#NUM_INIT_CHILDREN">num_init_children</a> が十分大きくない場合には
-        監視が失敗する場合があることに注意してください。
-        </p>
-        <p>これは非推奨の監視方法であり、下位互換のために残されています。</p>
-    </dd>
-    </dl>
-
-    <p>以下のパラメータが追加されました。</p>
-    <ul>
-    <li><a href="#WD_LIFECHECK_METHOD">wd_lifecheck_method</a></li>
-    <li><a href="#WD_HEARTBEAT_PORT">wd_heartbeat_port</a></li>
-    <li><a href="#WD_HEARTBEAT_KEEPALIVE">wd_heartbeat_keepalive</a></li>
-    <li><a href="#WD_HEARTBEAT_DEADTIME">wd_heartbeat_deadtime</a></li>
-    <li><a href="#HEARTBEAT_DESTINATION">heartbeat_destinationX</a></li>
-    <li><a href="#HEARTBEAT_DESTINATION_PORT">heartbeat_destination_portX</a></li>
-    <li><a href="#HEARTBEAT_DEVICE">heartbeat_deviceX</a></li>
-    </ul>
-</li>
-
-<li>filover/failback コマンドを排他的に実行するインターロック機能が追加されました。(Yugo Nagata)
-    <p>
-    watchdog で複数の pgpool-II を連携した場合、failover/failback コマンド
-    （<a href="#FAILOVER_COMMAND">failover_command</a>, <a href="#FAILBACK_COMMAND">failback_command</a>,
-    <a href="#FOLLOW_MASTER_COMMAND">follow_master_command</a>）は１つの pgpool-II でのみ実行されます。
-    </p>
-    <p>以前は、これらのコマンドは全ての pgpool-II で実行されていました。</p>
-</li>
-
-<li>watchdog パケット通信に認証機構が追加されました。(Yugo Nagata)
-<p>
-間違った認証キーを持つ pgpool-II から送られた watchdog パケットは拒絶されます。（ハートビート信号を含む）
-全ての pgpool-II は同じキーを pgpool.conf の wdauthkey パラメータに持っている必要があります。
-間違った認証キーを持っていると、スタートアップパケットも他の pgpool-II から拒絶されるため、
-起動することもできません。
-</p>
-</li>
-
-<li><a href="#CLEAR_MEMQCACHE_ON_ESCALATION">clear_memqcache_on_escalation</a> パラメータを
-    追加しました。(Yugo Nagata)</dt>
-    <p>これが on の場合は、pgpool-II がアクティブに昇格した時に、
-    共有メモリ上のメモリキャッシュが全てクリアされます。</p>
-    <p>これは、新しいアクティブの pgpool-II が以前のアクティブと矛盾する
-    古いキャッシュを使わないようにするためです。</p>
-</li>
-
-<li><a href="#WD_ESCALATION_COMMAND">wd_escalation_command</a> パラメータを追加しました. (Yugo Nagata)
-    <p>
-    このパラメータに指定されたコマンドは、pgpool-II がアクティブに昇格した時に実行されます。
-    実行のタイミングは、仮想 IP が立ち上がった直後です。
-    </p>
-</li>
-
-<li><a href="#WD_LIFECHECK_DBNAME">wd_lifeccheck_dbname</a>, <a href="#WD_LIFECHECK_USER">wd_lifecheck_user</a>,
-    <a href="#WD_LIFECHECK_PASSWORD">wd_lifecheck_password</a> パラメータを追加しました。(Yugo Nagata)
-    <p>
-    これらのパラメータは、クエリモードで監視の際に使用するデータベース名、ユーザ名、パスワードを提要します。
-    以前はそれぞれ templat1, <a href="#RECOVERY_USER">recovery_user</a>,
-    <a href=="#RECOVERY_PASSWORD">recovery_password</a> が使われていました。
-    </p>
-</li>
-
-<li><a href="#DELEGATE_IP">delegate_ip</a> オプションが空の場合には、
-    仮想 IP の立ち上げ/切り替えを行わないようになりました。(Yugo Nagata)
-    <p>これにより、各 pgpool-II に固定 IP を用いてアクセスするマルチマスタ的運用で、
-    仮想 IP を用意する必要がなくなりました。</p>
-</li>
-
-<li><a href="#pcp_watchdog_info">pcp_watchdog_info</a> コマンドを追加しました。(Yugo Nagata)</dt>
-    <p>これは watchdog ステータスを取得する pcp コマンドです。</p>
-</li>
-
-</ul>
-
-<h4>その他</h4>
-<ul>
-<li>PostgreSQL 9.2 の raw パーサを取り入れました。 (Nozomi Anzai, Tatsuo Ishii)</li>
-
-<li>pgpool_setup を追加しました。(Tatsuo Ishii)</dt>
-<p>これはカレントディレクトリ下 pgpool-II と PostgreSQL のテスト環境を構築するツールです。</p>
-<pre>
-ex.) $ ./pgpool_setup -m s
-
-usage: pgpool_setup [-m r|s][-n num_clusters][--no-stop]
-   -m s: ストリームレプリケーションモードで構築（デフォルト）
-   -m r: ネイティブレプリケーションモードで構築
-   -n num_clusters: num_clusters 台で PostgreSQL データベースクラスタノードを作成
-   -p base_port: ベースとなるポート番号を指定。最初の PostgreSQL ノードのポートは
-                 base_port, 次の PostgreSQL ノードのポートは base_port + 1, n 番目
-                 の PostgreSQL ノードのポートは base_port + n-1, pgpool のポートは
-                 base_port + n, pcp のポートは base_port + n + 1 となる。
-   --no-stop: セットアップ終了後に pgpool-II, PostgreSQL を終了しない
-</pre>
-</li>
-
-<li>pgpool-recovery, pgpool-regclass を CREATE EXTENSION を使って
-    インストールできるようになりました。(Tatsuo Ishii)
-    <p>古いインストール方法も継続して利用可能です。</p>
-    <p>
-    エクステンションの名前が "pgpool-recovery", "pgpool-regclass" ではなく
-    "pgpool_recovery", "pgpool_regclass" であることに注意してください。
-    前者では二重引用符が必要であり CREATE EXTENSION コマンドでは不便なためです。
-    </p>
-    </li>
-
-<li><a href="#pgpool_pgctl">pgpool_pgctl() 関数</a> を追加しました。(Nozomi Anzai)
-    <p>これを用いると、SQL から pg_ctl stop/restart/reload の実行が可能です。（ただし、start は除きます。）</p>
-<pre>
-$ psql sales -c "select pgpool_pgctl('reload', 'fast')";
- pgpool_pgctl
---------------
- t
-(1 row)
-</pre>
-    <p>
-    この関数は実行結果を無視して常に 't' を返すため、ユーザは pg_ctl が成功したか失敗したか知ることができません。
-    この関数を使用するには、セキュリティ上の理由から PostgreSQL で「pgpool.pg_ctl」というカスタム変数を設定し、
-    データディレクトリへの権限を持ち pg_ctl を実行するユーザを限定する必要があります。
-</p>
-</li>
-
-<li>pgpool-II と pgpoolAdmin の RPM をインストールするシェルスクリプトを追加しました。
-    (Nozomi Anzai, Yugo Nagata)
-    <p>
-    getsources.sh を実行することで作成された work/installer に RPM ファイルをコピーし、
-    このディレクトリを tar ボールで固めたものがインストーラパッケージとなります。
-    このインストーラは、RPM をインストールするだけではなく、postgresql.conf, pgpool.conf, pg_hba.conf
-    recovery.conf, ファイルオーバやオンラインリカバリ用のスクリプトの設定も行ないます。
-    </p>
-    <p>２ノード構成を前提としており、インストールスクリプトは両方のノードで実行する必要があります。</p>
-</li>
-
-<li>新しいパラメータ <a href="#SEARCH_PRIMARY_NODE_TIMEOUT">search_primary_node_timeout</a> を追加しました。
-    (Muhammad Usama, Tatsuo Ishii)
-    <p>
-    このパラメータはファイルオーバ時にプライマリノードを探す最大の秒数を指定します。
-    パッチは Muhammad Usama さんが作成し、日本語マニュアルの作成と、英語マニュアルの若干の修正を
-    Tatsuo Ishii が行いました。</p>
-</li>
-
-<li>インメモリクエリキャッシュと watchdog の 中国語のチュートリアルを追加しました。(Bambo Huang)</li>
-
-<li>レグレッションテストを作成しました。(Tatsuo Ishii)</li>
-
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h3>バグ修正</h3>
-<ul>
-
-<li>オンラインリカバリ時のフェイルバックの完了待機でタイムアウト処理をするようにしました。(Tatsuo Ishii)
-    <p>
-    これによりリカバリが永遠に終わらず pgpool-II が終了できなくなる状況を回避します。
-    この現象は特に <a href="#FOLLOW_MASTER_COMMAND">follow_master_command</a> の実行中に起こり得ました。
-    </p>
-</li>
-
-<li>ストリームレプリケーションモードでの <a href="#FOLLOW_MASTER_COMMAND">follow_master_command</a> 実行時に、
-    %H に新しいプライマリノードが正しく割り当てられないバグを修正しました。(Tatsuo Ishii)
-</li>
-
-<li>他の pgpool-II からダウン通知を受け取った pgpool-II が既にアクティブである場合には、
-    昇格処理を実行しないよう修正しました。(Yugo Nagata)
-</li>
-
-<li>watchdog ソケット作成時に、connect() の前に select() を実行していたのを修正しました。(Yugo Nagata)
-    <p>
-    未接続のソケットで select() を実行したときの処理は未定義で、プラットフォームで異なります。
-    Linux では 2 を返し、結果としては無害です。
-    しかし、Solaris では 0 を返し、これはタイムアウトと区別がつかないため、
-    watchdog が正しく動いていませんでした。
-    </p>
-</li>
-
-<li>pgpool_regclass がインストールされていない場合に生じるエラーを修正しました。(Tatsuo Ishii)
-    <p>
-    pgpool_rgcalss が存在しない場合に、pool_has_pgpool_regcalss() で使われているクエリが失敗していました。
-    詳しくは、<a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-May/001749.html">
-    [pgpool-general:1722]</a> を参照してください。
-    </p>
-</li>
-
-<li>PostgreSQL がエラーを返したときに do_query() がハングしないよう修正しました。(Tatsuo Ishii)
-    <p>
-    典型的な症状が「pg_stat_activety によると SELECT が実行されたままのように見える」というものです。
-    これを解決するため、pgpool-II は当該プロセスを終了させ、既存のコネクションを捨てるように修正しました。
-    あまり行儀のよい方法ではありませんが、これが最善の方法と信じています。
-    </p>
-</li>
-
-<li>watchdog を有効にしたときに、フェイルオーバの最中に起こりうるデッドロックを修正しました。(Yugo Nagata)
-    <p>このバグは、バグトラッカ #54 にて arshu arora さんによって報告されました。</p>
-    <blockquote>
-    #54: pgpool-II semaphore lock problem<br />
-    <a href="http://www.pgpool.net/mantisbt/view.php?id=54">
-    http://www.pgpool.net/mantisbt/view.php?id=54
-    </a>
-    </blockquote>
-</li>
-
-<li>COMMIT 時エラーに不要なバックエンド切り離しを行わないようにしました。(Tatsuo Ishii)
-    <p>
-    マスタースレーブモードで、COMMIT 時にマスターノードでエラーが発生していたとしても、
-    他のスレーブノードが正常な場合にはバックエンドを切り離す必要はありません。
-    これは、遅延トリガーのために "kind mismatch error" が発生しうるからです。
-    </p>
-</li>
-
-<li>拡張プロトコルの際に do_query で発生しうるハングアップを修正しました。(Tatsuo Ishii)
-    <p>
-    これは insert_lock が有効で、pgpool_catalog.insert_lock が存在することに起こり得ます。
-    詳しくは <a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-May/001711.html">
-    [pgpool-general: 1684]</a> を参照してください。
-    </p>
-</li>
-
-<li>トランザクション内の DML で、クエリキャッシュの無効化が失敗する場合があるのを修正しました。(Tatsuo Ishii)
-<pre>
-CREATE TABLE t1(i INTEGER);
-CREATE TABLE t2(i INTEGER);
-SELECT * FROM t1;
-BEGIN;
-DELETE FROM t2 WHERE i = 0;
-INSERT INTO t1(i) VALUES(1);
-COMMIT;
-
-SELECT * FROM t1;
-</pre>
-
-    <p>
-    上の SQL で、COMMIT 発行時に pgpool は t2 のキャッシュを削除しようとしますが、実際には t2 の
-    OID テーブルエントリがないのでこれは失敗します。そのときに、t1 の OID テーブルの確認までも失敗とみなされ、
-    直前の t1 の SELECT 結果のキャッシュが不正に残っていました。
-    </p>
-
-    <p>この問題はバグトラッカ #58 で wms さんにより報告されました。</p>
-    <blockquote>
-    #58: query cache invalidation does not fire for multiple DML in transaction<br />
-    <a href="http://www.pgpool.net/mantisbt/view.php?id=58">http://www.pgpool.net/mantisbt/view.php?id=58</a>
-    </blockquote>
-</li>
-
-<li>pgpool_regclass を pg_catalog スキーマに登録するよう修正しました。(Tatsuo Ishii)
-    <p>これは postgres_fdw のような、スキーマ検索パスが pg_catalog に限定されているクライアントに
-    対応するために必要です。
-</p>
-</li>
-
-<li>"pgpool -m f stop" で起こるハングアップを修正しました。(Tatsuo Ishii)
-    <p>
-    これは管理を外れた子プロセスが終了されずに残ってしまうのが原因で、複数のバックエンドがダウンしたときや、
-    バックエンドの起動前に pgpool-II が起動した場合に発生することがありました。
-    </p>
-</li>
-
-<li>pg_md5 コマンドで起こりうるクラッシュを修正しました。(Muhammad Usama)</li>
-
-<li>インメモリクエリキャッシュ有効時に発生するセグメンテーション違反が修正されました。(Tatsuo Ishii))
-    <p>
-    これは、拡張クエリモードで実行されたクエリが長い結果を返すときに発生します。
-    このバグはバグトラック #63 にて、harukat さんにより報告、解析され、テストケースが提供されました。
-    </p>
-    <blockquote>
-    #63 Child process was terminated by segmentation fault with memcached<br />
-    <a href="http://www.pgpool.net/mantisbt/view.php?id=63">
-    http://www.pgpool.net/mantisbt/view.php?id=63
-    </a>
-    </blockquote>
-</li>
-
-<li>スタートアップパケットに PostgreSQL ユーザ情報が含まれていなかった場合に発生する子プロセスの
-    セグメンテーション違反を修正しました。(Yugo Nagata)
-    <p>このバグは以下を実行することにより再現できます。</p>
-<pre>
-$ psql -p 9999 -U ''
-</pre>
-    <p>
-    <a href="#ENABLE_POOL_HBA">enable_pool_hba</a> が有効の場合は子プロセスがセグメンテーション違反で異常終了し、
-    無効の場合には以下のメッセージがログに出力されていました。
-    </p>
-<pre>
-ERROR: pool_discard_cp: cannot get connection pool for user (null) database (null)
-</pre>
-
-    <p>
-    また、両方の場合で psql はフロントエンドに何のメッセージ出力せずに終了していました。
-    修正後は、スタートアップパケットに PostgreSQL ユーザが指定されていない場合には
-    以下のメッセージがログとフロントエンドの両方に出力されます。
-    これは PostgreSQLと同じ振る舞いです。
-    </p>
-<pre>
-FATAL: no PostgreSQL user name specified in startup packet
-</pre>
-</li>
-
-<li>インメモリクエリキャッシュを有効にした時の拡張クエリの処理におけるメモリ割り当てロジックを修正しました。(Tatsuo Ishii)
-    <p>
-    バインドパラメータ付きの拡張クエリで、1024 バイト以上の長いクエリ文字列が渡されたときに、
-    十分なメモリ割り当てができていませんでした。
-    </p>
-</li>
-
-<li><a href="#pcp_recovery_node">pcp_recovery_node</a> コマンドで、
-    バックエンドノード番号をチェックするように修正しました。(Yugo Nagata)
-    <p>
-    不正な値が使用された場合、リカバリで実行されるスクリプトの引数に空の値が渡されており、
-    誤動作の原因となっていました。
-    特にベースバックアップを行うスクリプトで、rsync が関係のないファイルを削除してしまうことがありました。
-    </p>
-</li>
-
-<li>バックエンドエラー検出時に発生することがあるメインプロセスの
-    セグメンテーション違反を修正しました。(Tatsuo Ishii)
-    <p>この問題はバグトラック #62 で tuomas さんにより報告されました。</p>
-    <blockquote>
-    #62 Slave network outage causes a segmentation fault on main process <br />
-    <a href="http://www.pgpool.net/mantisbt/view.php?id=62">
-    http://www.pgpool.net/mantisbt/view.php?id=62
-    </a>
-    </blockquote>
-</li>
-
-<li><a href="#CHILD_LIFE_TIME">child_life_time</a> 使用時に発生しうる
-    ヘルスチェックのバグを修正しました。(Tatsuo Ishii)
-    <p>
-    バックエンドが正しく動作しているにも関わらずフェイルオーバが発生することがありました。
-    この問題は [pgpool-general: 1892] で larisa sabban さんにより報告されました。
-    </p>
-    <blockquote>
-    [pgpool-general: 1892] Pgpool is unable to connect backend PostgreSQL<br />
-    <a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-July/001920.html">
-    http://www.sraoss.jp/pipermail/pgpool-general/2013-July/001920.html
-    </a>
-    </blockquote>
-</li>
-
-<li>レプリケーションモードにおけるプリペアド文のパース処理を修正しました。
-    (Tatsuo Ishii)
-    <p>
-      レプリケーションモードで SELECT 以外のクエリをパースする際には、ノード間の
-      一貫性保持のため自動的にトランザクションが開始されますが、トランザクション
-      を閉じる処理が行われていませんでした。そのため、実際に誤っているクエリだけ
-      ではなく、その次にパース処理されたクエリもアボートされていました。
-      このバグは [pgpool-general: 1877] で Sean Hogan さんにより報告されました。
-    </p>
-    <blockquote>
-    [pgpool-general: 1877] current transaction is aborted, commands ignored<br />
-    <a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-July/001905.html">
-    http://www.sraoss.jp/pipermail/pgpool-general/2013-July/001905.html
-    </a>
-    </blockquote>
-</li>
-
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h3>改良</h3>
-
-<ul>
-<li>man ページに -D オプションの記述を追加しました。（Tatsuo Ishii)</li>
-<li>watchdog のプロセスが異常終了した場合に、これが自動で再起動されるよう修正しました。(Yugo Nagata)</li>
-<li>watchdog 有効時に ping コマンドを実行する関数にエラーチェックを追加しました。(Tatsuo Ishii)</li>
-<li>sprintf strncpy などの安全でない関数を、より安全な snprintf, strlcpy に置き換えました。(Yugo Nagata)</li>
-<li>ログ出力、コメント、関数名で使われていた "sticky bit" という用語を
-    "setuid bit" に置き換えました。(Yugo Nagata)
-    <p>この用語は本来とは違う意味で使われており、混乱の元となっていました。</p>
-</li>
-<li>pool_hba.conf.sample の SSL に関する記述を修正しました。(Tatsuo Ishii)</li>
-<li>レプリケーションモードで、明示的なトランザクション内のロードバランスができるようになりました。(Tatsuo Ishii)
-    <p>ロードバランスが行われる条件は以下のとおりです。</p>
-    <ol>
-    <li><a href="#REPLICATE_SELECT">replicate_select</a> が off</li>
-    <li>書き込みを行う関数が使われていない</li>
-    <li>トランザクション分離モードが SERIALIZABLE ではない</li>
-    <li>DML/DDL がトランザクションの中で実行されていない</li>
-    </ol>
-</li>
-<li>中国語マニュアルを最新の情報に更新しました。(Bambo Huang)</li>
-<li>ドキュメントの <a href="#SSL_CA_CERT">ssl_ca_cert</a> と
-    <a href="#SSL_CA_CERT_DIR">ssl_ca_cert_dir</a> の記述を SSL セクションに移動しました。(Yugo Nagata)</li>
-<li>日本語ドキュメントに <a href="#SSL_CA_CERT">ssl_ca_cert</a> と
-    <a href="#SSL_CA_CERT_DIR">ssl_ca_cert_dir</a> の記述を加えました。(Yugo Nagata)</li>
-</ul>
-
-<!-- ================================================================================ -->
-<!-- 3.2                                                                              -->
-<!-- ================================================================================ -->
-<hr><a name="release3.2.x"></a>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.2.12"></a>3.2.12 (namameboshi) 2015/07/24</h2>
-<!-- -------------------------------------------------------------------------------- -->
-
-<h3>概要</h3>
-<p>
-このバージョンは 3.2.11 に対するバグ修正リリースです。
-</p>
-
-<h3>バグ修正</h3>
-<ul>
-
-<li>
-    pgpool-recovery の "cannot find xlog functions" エラーを修正しました。(Muhammad Usama)
-    <p>
-    PostgreSQL 9.4 より、PostgreSQL の pg_xlogfile_name() 関数の引数型はtext からpg_lsn に変更されていますが、pgpool-recovery は依然として古いシグネチャで関数を配置しようとしていました。
-    </p>
-</li>
-
-<li>
-    failover コマンドのパラメータに対して pgpool-II が値を持たない場合は、空文字列を渡すようにしました。(Muhanmmad Usama)
-    <p>
-    あるパラメータに対して pgpool-II が値を持たない場合には、その値を取り除くのではなく、空の文字列を failover コマンドに渡すようになりました。これにより、failover スクリプトが常に期待した個数のパラメータを受け取るようになります。
-    </p>
-</li>
-
-<li>
-    doc: JDBC ドライバ使用時のロードバランス条件について制限事項の内容が古かったので修正しました。(Tatsuo Ishii)
-    <p>
-    autocommit が false であっても、ある条件下ではロードバランスが可能です。
-    </p>
-</li>
-
-<li>
-    インメモリクエリキャッシュが 4GB より大きなメモリサイズを使えるように修正しました。(Tatsuo Ishii)
-    <p>
-    これはインメモリクエリキャッシュ機能が完成した時点で可能にしておくべきでした。
-    </p>
-</li>
-
-<li>
-    拡張問い合わせクエリで、レプリケーションモード以外の場合には、insertlock をチェックするクエリを送信しないようになりました。(Tatsuo Ishii)
-</li>
-
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.2.11"></a>3.2.11 (namameboshi) 2015/04/08</h2>
-<!-- -------------------------------------------------------------------------------- -->
-
-<h3>概要</h3>
-<p>
-このバージョンは 3.2.10 に対するバグ修正リリースです。
-</p>
-
-<h3>バグ修正</h3>
-<ul>
-
-<li>
-    スレッド関数の戻り値を void * 型で受け取るように修正しました。(Yugo Nagata)
-    <p>
-    以前は int 型が使われており、スタックバッファオーバフローの原因となっていました。これにより、仮想IPの起動/停止時に、ping エラーの無限ループが発生することがありました。
-    </p>
-</li>
-
-<li>
-    watchdog プロセスで、SIGCHLD を SIG_IGN ではなく SIG_DFL に設定するよう修正しました。(Yugo Nagata)
-    <p>
-    waitpid 使用時は SIGCHLD を SIG_IGN にする必要はなく、むしろ有害であり、これにより ping コマンドが正常終了した場合でも異常終了したとみなされる場合がありました。
-    </p>
-</li>
-
-<li>
-    不必要な include ディレクティブを取り除きました。(Yugo Nagata)
-</li>
-
-<li>
-    POOLCONFIG_MAXDESCLEN を 80 まで増やしました (Tatsuo Ishii)
-    <p>
-    これは show pool_status コマンドでパラメータの説明文の長さ制限に使われていますが、recovery_timetout ではこれが 64 文字であり、以前のマクロ定義では 1 文字分不足していました。
-    </p>
-</li>
-
-<li>
-    フロントエンド接続の証明書ファイルで SSL 証明書チェーンに対応しました。(Muhammad Usama)
-</li>
-
-<li>
-    pcp_detach_node が graceful にノードを切り離す際の問題を修正しました。(Muhammad Usama)
-    <p>
-    graceful なノード切り離しでは、そのノードの切り離し処理が許されているかの判断を、pcp_detach_node は新しい接続のブロックと既存の接続の切断よりも前に行う必要があります。
-    </p>
-</li>
-
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.2.10"></a>3.2.10 (namameboshi) 2015/02/05</h2>
-<!-- -------------------------------------------------------------------------------- -->
-
-<h3>概要</h3>
-<p>
-このバージョンは 3.2.9 に対するバグ修正リリースです。
-</p>
-
-<h3>バグ修正</h3>
-<ul>
-
-<li>
-    doc: スレーブノードの数は１である必要でないことを明記しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    未初期化の変数があったのを修正しました。(Tatsuo Ishii)
-    <p>
-    Coverity の報告 #1234603 によります。
-    </p>
-</li>
-
-<li>
-    doc: 前回のリリースで抜け落ちていたリリースノートを追記しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    クエリキャッシュで発生しうるセグメンテーションフォルトを修正しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    trigger_failover_command() 関数のノード ID 範囲検査のバグを修正しました。(Tatsuo Ishii)
-    <p>
-    ノード ID は定数 NUM_BACKENDS 未満である必要があります。実際にはNUM_BACKENDS 以上の値はこの関数に渡されていなかったので、おそらく害はありませんでした。
-    </p>
-</li>
-
-<li>
-    if_up_cmd, if_down_cmd でアドレスプレフィックス付きの $_IP_$ を使用できるように修正しました。(Muhammad Usama)
-    <p>
-    以前は "$_IP_$" の直後には空白が来ることが前提となっていたため、アドレスプレフィックスがある場合（例：$_IP_$/24 ）、このプレフィックスは無視されていました。
-    </p>
-    <blockquote>
-    bug #122 の報告によります。<br />
-    <a href="http://www.pgpool.net/mantisbt/view.php?id=122">
-    http://www.pgpool.net/mantisbt/view.php?id=122
-    </a>
-    </blockquote>
-</li>
-
-<li>
-    show pool_nodes が 2 桁以上のノード ID を表示できるように修正しました。(Muhammad Usama)
-    <p>
-    この問題は [pgpool-general: 3374] で報告されました。
-    </p>
-</li>
-
-<li>
-    設定ファイルのリロードにより debug モードを無効にできるよう修正しました。(Yugo Nagata)
-    <blockquote>
-    bug #114 の報告によります。<br />
-    <a href="http://www.pgpool.net/mantisbt/view.php?id=114">
-    http://www.pgpool.net/mantisbt/view.php?id=114
-    </a>
-    </blockquote>
-</li>
-
-
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.2.9"></a>3.2.9 (namameboshi) 2014/09/05</h2>
-<!-- -------------------------------------------------------------------------------- -->
-
-<h3>概要</h3>
-<p>
-このバージョンは 3.2.8 に対するバグ修正リリースです。
-</p>
-
-<h3>バグ修正</h3>
-<ul>
-
-<li>
-    pgpool.spec のタイポを修正しました。(Yugo Nagata)
-</li>
-
-<li>
-    プライマリバックエンドが存在しない場合に、ワーカー子プロセスが終了と再起動を繰り返すバグを修正しました。(Tatsuo Ishii)
-    <p>
-    問題の同定と修正は Junegunn Choi さんの貢献によります。
-    </p>
-    <p>
-    詳しくは、[pgpool-hackers: 471] を参照してください。
-    </p>
-</li>
-
-<li>
-    スマートシャットダウンの実行時には受信用ソケットを閉じるように修正しました。(Tatsuo Ishii)
-    <p>
-    スマートシャットダウンが実行された場合でも、pgpool の子プロセスは受信用のポートを開いており、最終的に失敗するにもかからわずクライアントは接続要求を送信可能です。これは時間の無駄であるだけではなく、pgpool のフロントにいるロードバランサによる pgpool の停止の検出を妨げます。
-    </p>
-    <p>
-    この問題は [pgpool-hackers 474] にて Junegunn Choi によって解析され、パッチが提供されました。これを Tatsuo Ishii が改良し、inet ドメインだけではなく UNIX ドメインのソケットにも対応させました。
-    </p>
-</li>
-
-<li>
-    doc: PostgreSQL の statement_timeout によって、リカバリコマンドが終了させられる可能性を追記しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    dic: 現在は当てはまらない古い制限事項を削除しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    text_to_lsn() 関数の返却値型を修正しました。(Yugo Nagata)
-    <p>
-    コンパイル時の警告の原因となっていました。
-    </p>
-</li>
-
-<li>
-    デーモン化した際にファイル識別子が閉じられていなかったのを修正しました。(Tatsuo Ishii)
-    <p>
-    Coverity の報告 #1111471 によります。
-    </p>
-</li>
-
-<li>
-    メモリリークを修正しました。 (Tatsuo Ishii)
-    <p>
-    Coverity の報告 #1111442 によります。
-    </p>
-</li>
-
-<li>
-    長らく放置されていた pgool.init の stop/restart のバグを修正しました。(Yugo Nagata)
-    <p>
-    以前は pgpool の停止に pgpool.init は killproc を用いていましたが、これにはいくつか問題がありました。これを、"pgpool -m fast stop" を用いるように修正しました。
-    </p>
-    <p>
-    Ryan DeShone により提供されたパッチを Yugo Nagata が修正しました。
-    </p>
-    <p>
-    詳しくは、[pgpool-hackers: 239][pgpool-hackers: 512] を参照してください。
-    </p>
-</li>
-
-<li>
-    不足していたインクルードファイル sys/wait.h を追加しました。(Tatsuo Ishii)
-    <blockquote>
-    bug #104 の報告によります。<br />
-    <a href="http://www.pgpool.net/mantisbt/view.php?id=104">
-    http://www.pgpool.net/mantisbt/view.php?id=104
-    </a>
-    </blockquote>
-</li>
-
-<li>
-    オンラインリカバリの実行時は PostgreSQL の statement_timeout を無効にするようになりました。(Tatsuo Ishii)
-    <p>
-    オンラインリカバリは異常に長い時間を要する可能性がある一方、ユーザは statement_timeout を有効にしている可能性があります。これによりオンラインリカバリがキャンセルされるのを防ぐため、リカバリの最中は statement_timeout を無効にするようになりました。
-    </p>
-    <p>
-    詳しくは [pgpool-general: 2919] を参照してください。
-    </p>
-</li>
-
-<li>
-    不適切にセマフォを削除しないよう不必要な pool_shmem_exit() 呼び出しを取り除きました。(Tatsuo Ishii)
-    <p>
-    exit_handler はプロセスが親プロセスがどうかをチェックしていますが、子プロセスであった場合にも pool_shmem_exit() が呼ばれることがあり、これにより不適切にセマフォが削除されていました。この関数は親プロセス以外に呼ばれてはなりません。
-    </p>
-    <blockquote>
-    bug #102 によります。<br />
-    <a href="http://www.pgpool.net/mantisbt/view.php?id=102">
-    http://www.pgpool.net/mantisbt/view.php?id=102
-    </a>
-    </blockquote>
-</li>
-
-<li>
-    リセット用クエリにより発生するハングを修正しました。(Tatsuo Ishii)
-    <p>
-    DISCARD ALL などのリセットクエリが完了せず、pgpool の子プロセスがバックエンドからの反応を待ったまま固まってしまい、新しいクライアントからの接続が受けられなくなる問題が報告されました。
-    </p>
-    <p>
-    原因はまだ特定されていませんが、クライアントの接続がクエリ処理の最中に突然切断された場合、バックエンドがクエリを処理できない状態となり、リセットクエリを受け付けられなくのかもしれません。
-    </p>
-    <p>
-    これに対処するため、フロントエンドから接続が予期せず切断された場合は、クエリ処理ループを即座に終了し PostgreSQL への接続を切断し、新しい接続要求を待つように修正しました。
-    </p>
-    <p>
-    また client_idle_limit が設定されており、リミットに達した場合にもpgpool はバックエンドへの接続を切断するよう修正されました。
-    </p>
-    <blockquote>
-    bug #107 の報告によります。<br />
-    <a href="http://www.pgpool.net/mantisbt/view.php?id=107">
-    http://www.pgpool.net/mantisbt/view.php?id=107
-    </a>
-    </blockquote>
-</li>
-
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.2.8"></a>3.2.8 (namameboshi) 2014/03/24</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<p>
-このバージョンは 3.2.7 に対するバグ修正リリースです。
-</p>
-
-<h3>バグ修正</h3>
-<ul>
-
-<li>
-    doc: num_init_children の項に「listen キュー」の説明とその「バックログ」を増やす方法について追記しました。
-    (Tatsuo Ishii)
-</li>
-
-<li>
-    指定した上位サーバの内たった１台への ping が失敗した場合にも watchdog
-    ステータスがダウンになってしまうバグを修正しました。(Yugo Nagata)
-</li>
-
-<li>
-    UNLOGGED テーブルを検出する処理のパフォーマンスが悪かったのを修正しました。
-    (Tatsuo Ishii)
-    <p>
-    この問題は <a href="http://www.sraoss.jp/pipermail/pgpool-hackers/2014-January/000435.html">[pgpool-hackers: 435]</a>
-    <a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-December/002354.html">[pgpool-general:2325]</a> で指摘されました。
-    </p>
-</li>
-
-<li>
-    プライマリノードの検出ロジックを修正しました。(Tatsuo Ishii)
-    <p>
-    プライマリノードが検出されないことがありました。例えば、node 0 がプライマリ、node 1
-    がスタンバイのときに、node 0 が落ちたとします。ヘルスチェックがそれを検出しますが、
-    内部のステータスがまだ更新されていない場合 node 0 には問題がないよう見えるため node 0
-    への接続が試みられます。実際にはこの接続は失敗するため、node 1
-    が新プライマリであることを検出する前に処理が終了していました。
-    </p>
-    <p>
-    この問題は <a href="http://www.sraoss.jp/pipermail/pgpool-general/2014-January/002442.html">[pgpool-general: 2409]</a> にて報告されました。
-    </p>
-</li>
-
-<li>
-    raw モードで自動コミットが off で JDBC を使用したときに、DML
-    が失敗するバグを修正しました。(Tatsuo Ishii)
-    <p>
-    この問題は <a href="http://www.pgpool.net/mantisbt/view.php?id=92">bug #92</a> で報告されました。
-    </p>
-</li>
-
-<li>
-    拡張プロトコルにおけるクエリキャッシュのバグを修正しました。(Tatsuo Ishii)
-    <p>
-    明示的なトランザクション内で DML が実行された場合でも、SELECT
-    実行時に古いキャッシュが読み込まれていました。
-    これはインメモリクエリキャッシュが実装された時点から存在していたバグです。
-    </p>
-    <p>
-    <a href="http://www.sraoss.jp/pipermail/pgpool-general-jp/2014-January/001251.html">
-    [pgpool-general-jp: 1252]</a> で報告されました。
-    </p>
-</li>
-
-<li>
-    SHOW pool_status の結果から抜けていた relcashe_size と check_temp_table
-    を追加しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    ストリーミングレプリケーションモードで無関係なノードにはクエリを送信しないように修正しました。
-    (Tatsuo Ishii)
-    <p>
-    pgpool-II は BEGIN, END, SET などのクエリを全ての DB ノードに送っています。
-    しかし、ストリーミングレプリケーションではプライマリノードと高々１台のスタンバイノードにしか送る必要がありません。
-    （もしプライマリノードがロードバランスノードとして選択されている場合には１台だけで充分です。）
-    </p>
-    <p>
-    詳細は <a href="http://www.sraoss.jp/pipermail/pgpool-hackers/2014-February/000464.html">
-    [pgpool-hackers: 464]</a> を参照してください。
-    </p>
-</li>
-
-<li>
-    バッファオーバランとメモリリークの可能性を修正しました。(Tatsuo Ishii)
-    <p>
-    Coverity 1111465, 1111482 の報告によります。
-    </p>
-</li>
-
-<li>
-    バッファオーバランを修正しました。(Tatsuo Ishii)
-    <p>
-    strcpy() を strlcpy() で置き換えました。Coverity 1111478, 1111480 の報告によります。
-    </p>
-</li>
-
-<li>
-    NULL ポインタの解放を修正しました。(Tatsuo Ishii)
-    <p>
-    Coverity 1111384 の報告によります。
-    </p>
-</li>
-
-<li>
-    マテリアライズドビューをキャッシュしないよう修正しました。(Tatsuo Ishii)
-    <p>
-    <a href="http://www.pgpool.net/mantisbt/view.php?id=92">bug #95</a> で報告されました。
-    </p>
-</li>
-
-<li>
-    メモリリークを修正しました。(Tatsuo Ishii)
-    <p>
-    Coverity 1111446 の報告によります。
-    </p>
-</li>
-
-<li>
-    パラレルモードで system_db_hostname
-    が空欄の場合に発生するセグメンテーションフォルトを修正しました。
-    (Yugo Nagata)
-</li>
-
-<li>
-    -d オプションで起動した場合に pgpool.conf
-    の処理中のデバッグメッセージを出力するように修正しました
-    (Yugo Nagata)
-    <p>
-    以前は -d オプション使用時でも出力されていないデバッグメッセージがありました。
-    </p>
-</li>
-
-<li>
-    レプリケーションモードで JDBC 使用時に now()
-    を含む準備文で発生する例外を修正しました。(Yugo Nagata)
-    <p>
-    JDBC で準備文を PrepareThreshold 回以上実行した場合には、文に名前が付けられ Parse
-    の後に Describe メッセージが発行されます。このとき、pgpool は now()
-    をパラメータに書き換えるため、元のクエリには無かった新しいパラメータが追加されます。
-    この場合、フロントエンドに返されるParameterDscription メッセージ（Describe
-    の返答）は、元のクエリが持つパラメータと同じ数の OID を含むべきです。そうしないと、JDBC
-    はArrayIndexoutOfBoundsException 例外を発生させてしまいます。
-    </p>
-    <p>
-    このバグは <a href="http://www.sraoss.jp/pipermail/pgpool-general-jp/2013-September/001191.html">
-    [pgpool-general-jp: 1192]</a> で報告されました。
-    </p>
-</li>
-
-<li>
-    レプリケーションモードにて、デフォルト値が now()
-    のカラムを持つテーブルに対する準備文でエラーが発生するバグを修正しました。
-    (Yugo Nagata)
-    <p>
-    デフォルト値が now() を持つ名前付き準備文を parse する際に、pgpool-II
-    は時刻値をパラメータで置き換えます。そのため、その後の bind
-    メッセージも追加されたパラメータの形式コードを含んでいる必要があります。
-    しかし、元のクエリのパラーメータ形式数が１だった場合、この処理がなされていませんでした。これが
-    "incorrect binary data format in bind parameter 2" のようなエラーの原因となっていました。
-    </p>
-</li>
-
-<li>
-    doc: パラレルモードは PREPARE 文の実行に対応していないことを追記しました。(Yugo Nagata)
-    <p>
-    <a href="http://www.pgpool.net/mantisbt/view.php?id=93">bug #93</a> の指摘によります。
-    </p>
-</li>
-
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.2.7"></a>3.2.7 (namameboshi) 2013/12/06</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<p>
-このバージョンは 3.2.7 に対するバグ修正リリースです。
-</p>
-<h3>バグ修正</h3>
-<ul>
-
-<li>レプリケーションモード稼働時、一部のタイムゾーンでタイムスタンプの書き換えが誤っていました。(Tatsuo Ishii)
-<p>タイムスタンプの書き換え処理では、現在日時を取得するあめに "SELECT now()" を実行します。
-しかし一部のタイムゾーンにおいては、"02:30" のような場合に現在日時のためのバッファの大きさが
-十分ではありませんでした。"0900" のように 30 分刻みでのタイムゾーンでないときは、この問題は発生しません。
-そのため、これまでこの不具合が報告されたことはありませんでした。</p>
-<p>この不具合は <a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-September/002142.html" target="_blank">[pgpool-general: 2113]</a> で報告され、Sean Hogan さんによって修正が提供されました。</p>
-</li>
-
-<li>Makefile: Makefiles 内の pg_config を $(PG_CONFIG) に置き換えました。
-したがって、PostgreSQL のメジャーバージョンが異なる場合には、コンパイル中で上書きされるようになります。(Tatsuo Ishii)
-<p>パッチは Christoph Berg さんから提供されました。（<a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-September/002156.html" target="_blank">[pgpool-general: 2127]</a>）</p>
-</li>
-
-<li>pgpool.conf で <a href="#LOG_STANDBY_DELAY">log_standby_delay</a> を設定してないときに
-segfault していたのを修正しました。(Tatsuo Ishii)
-<p>これは、pool_config.l での log_standby_delay の初期化が誤っていたためです。
-<a href="http://www.pgpool.net/mantisbt/view.php?id=74" target="_blank">bug#74</a> として報告されました。</p>
-</li>
-
-<li>スタンバイノードがダウンしようとしているときに find_primary_node_repeatedly() が
-呼ばれないようにしました。(Tatsuo Ishii)
-<p>これによってフェイルオーバの所要時間が短くなります。
-<a href="http://www.pgpool.net/mantisbt/view.php?id=75" target="_blank">bug#75</a> として報告され、
-パッチを Tatsuo Ishii が編集しました。</p>
-</li>
-
-<li>レプリケーションモードと拡張プロトコルを組み合わせた場合に、
-データ不整合があったのでこれを修正しました。(Tatsuo Ishii)
-<p>JDBC ドライバを使った同時 INSERT で、ノード間でのデータ不整合があるという報告がありました。
-この事象は以下の条件で必ず発生します。
-</p>
-<ol>
-    <li>レプリケーションモードを使用している</li>
-    <li>拡張プロトコルを使用している</li>
-    <li>parse で作成された portal が bind で再利用される</li>
-    <li>autocommit が on である</li>
-    <li>SERIAL（シーケンス）を使用している</li>
-</ol>
-
-<p>pgpool-II の parse 関数は、クライアントが INSERT (+ 5 の状態）を発行すると、対象テーブルをロックされていることを
-認識しています。しかし、bind 関数はそれを認識していませんでした。
-一度 parse / bind / execute が完了すると、pgpool は 4 の理由により parse で獲得したロックを解放します。
-そして JDBC は portal を再利用しようとし、ロックを獲得しないまま bind からのサイクルを開始してしまいます。
-その結果、ロックのない INSERT がノード間でのデータ不整合を引き起こします。
-この解決方法としては、bind でテーブルをロックするようにしました。
-</p>
-<p>この問題は、たいていのユーザは JDBC を autocommit = off で使っているために、
-今まで報告されることがありませんでした。off であれば、ユーザが commit / rollback を発行するまで、
-parse によるロックが残存するためです。</p>
-<p>この不具合は Steve Kuekes さんにより、<a href="http://www.sraoss.jp/pipermail/pgpool-gener" target="_blank">[pgpool-general: 2142]</a> で報告されました。</p>
-</li>
-
-<li>クエリキャッシュにおけるメモリ確保サイズの不具合を修正しました。(Tatsuo Ishii)
-<p>execute() において、メモリ確保サイズが一部の場合において小さすぎました。</p>
-</li>
-
-<li>クエリキャッシュ + 拡張プロトコルの組み合わせで使っている場合に、segfault する可能性があったのを
-修正しました。(Tatsuo Ishii)
-<p>クエリが "cache safe" でないときに、bind_msg-&gt;param_offset が Bind() でセットされていませんでした。
-しかし Execute() では無条件に bind_msg-&gt;param_offset を使おうとしていました。
-</p>
-<p>この不具合は <a href="http://www.pgpool.net/mantisbt/view.php?id=76" target="_blank">bug#76</a> で報告されました。</p>
-</li>
-
-<li>クエリキャッシュの hash index エントリがいっぱいにならないようにしました。(Tatsuo Ishii)
-<p>hash index エントリがいっぱいになると、pgpool-II は hash index の残りが少なくとも 1 つはある前提だったため、
-古いキャッシュエントリを再利用できませんでした。
-これを改善するために、hash index エントリがいっぱいになったら、再利用できるキャッシュブロックを
-探すようにしました。</p>
-<p>この不具合は <a href="http://www.pgpool.net/mantisbt/view.php?id=70" target="_blank">bug#70</a> で報告されました。</p>
-</li>
-
-<li>clock hand の不適切なサイズの共有メモリ確保を修正しました。(Tatsuo Ishii)
-<p>clock hand のメモリは、sizeof(pool_fsmm_clock_hand) 分確保されており、
-この変数が「<code>static int *pool_fsmm_clock_hand</code>」と定義されていることから、8 バイトでした。</p>
-<p>しかしこれは誤りで、実際に必要なのは「<code>sizeof(*pool_fsmm_clock_hand)</code>」での 4 バイトでした。</p>
-<p>これは Coverity "1111476 Wrong sizeof argument" で発見されました。</p>
-</li>
-
-<li>"<a href="#pool_status">show pool_status</a>" で
-<a href="#MEMQCACHE_AUTO_CACHE_INVALIDATION">memqcache_auto_cache_invalidation</a> が常に
-0 と表示されていました。 (Tatsuo Ishii)
-<p>この不具合は <a href="http://www.pgpool.net/mantisbt/view.php?id=80" target="_blank">bug#80</a> で報告されました。</p>
-</li>
-
-<li>read_password_packet() のエラーメッセージを修正しました。(Tatsuo Ishii)</li>
-
-<li>SSL 要求でのメモリリークを修正しました。(Tatsuo Ishii)
-<p>SSL での要求があったとき、pgpool 子プロセスは start up packet の読み込みをリトライしていました。
-しかし子プロセスは、以前の start up packet のメモリを解放していませんでした。</p>
-<p>これは Coverity "1111443 Resource" で発見されました。</p>
-</li>
-
-<li>do_query() がタイムスタンプの書き換えに失敗したとき、メモリリークしていました。(Tatsuo Ishii)
-<p>この修正のために、free_select_result() で NULL 引数を受け取れるようにしました。</p>
-<p>これは Coverity "1111454, 1111455 Resource leak" で発見されました。</p>
-</li>
-
-<li>watchdog: ping 結果を格納する文字列で、終端に NULL 文字を追加しました。（Yugo Nagata)</li>
-
-<li>"<code>DEALLOCATE portal|statement</code>" 実行時の対象ノードの選定ロジックを修正しました。(Tatsuo Ishii)
-<p>"<code>DEALLOCATE portal|statement</code>" 実行時、最後の prepared statement や portal が見つからない場合に、
-対象ノード選定マップがセットされていませんでした。
-おそらく、そうした場合はエラーなので、実際には問題ありません。</p>
-<p>これは Coverity "1111491 Structurally dead code" で発見されました。</p>
-</li>
-
-<li>MAX_NUM_BACKENDS の範囲チェックにおける不具合を修正しました。 (Tatsuo Ishii)
-<p>MAX_NUM_BACKENDS は DB ノードの最大数が限界値でした（現時点では 128）。
-実際には 128 の DB ノードで試す人がいなかったために、発見されなかった不具合のようです。</p>
-<p>これは Coverity "1111429, 1111430 and 1111431 Out-of-bounds write" で発見されました。</p>
-</li>
-
-<li>フロントエンド接続情報を、すでに無効なバックエンドについて set/unset しないようにしました。(Tatsuo Ishii)
-<p>この不具合は <a href="http://www.pgpool.net/mantisbt/view.php?id=82" target="_blank">bug#82</a> で報告されました。</p>
-</li>
-
-<li>pgpool_catalog への public access を許可していませんでした。
-<p>これは、pgpool_catalog がレプリケーションモードで作成されている場合に、
-ユーザテーブルにデータを INSERT すると発生します。</p>
-<p>この不具合は <a href="http://www.sraoss.jp/pipermail/pgpool-general-jp/2013-November/001228.html" target="_blank">[pgpool-general-jp: 1229]</a> で報告されました。</p>
-</li>
-
-<li>doc: <a href="#TRUSTED_SERVERS">trusted_servers</a> に複数のサーバを指定すべきであることを記述しました。
-(Yugo Nagata)</li>
-
-<li>pool_do_auth() のエラーケースで変数を初期化していませんでした。 (Tatsuo Ishii)
-<p>有効なバックエンドがいないとき、pgpool は認証フェーズのフロントエンドにごみの pid を返していました。
-実際に、有効なバックエンドがいないために、フロントエンドは認証後に接続することができません。
-もちろんこれは問題あるものではありません。</p>
-<p>これは Coverity "1127331 Uninitialized scalar variable" で発見されました。</p>
-</li>
-
-<li>ノード ID を使ったエラーメッセージの発行時に、ノード ID の範囲チェックをするようにしました。
-(Tatsuo Ishii)
-<p>これは Coverity "1111433 "Out-of-bounds read" で発見されました。</p>
-</li>
-
-<li>parse_copy_data() でのバッファオーバーランとリソースリークを修正しました。 (Tatsuo Ishii)
-<p>これは Coverity "1111427 Out-of-bounds write"、"1111453 Resource leak" で発見されました。</p>
-</li>
-
-<li>CopyDataRaws() で segfault する可能性があったのを修正しました。(Tatsuo Ishii)
-<p>pool_get_id() がエラーを返した場合に VALID_BACKEND が配列外にアクセスしようとしていました。</p>
-<p>これは Coverity "1111433 Out-of-bounds read" で発見されました。</p>
-</li>
-
-<li>クエリキャッシュ有効 + プロトコルバージョン = 2 の組み合わせでの処理を修正しました。(Tatsuo Ishii)
-<p>プロトコルバージョンが 2 のとき、セッション状態が "idle" である前提でしたが、
-実際にはそうではありませんでした。
-プロトコルバージョンが 2 の場合はクエリキャッシュを使用しないことをおすすめします。</p>
-<p>これは Coverity "1111488 Uninitialized scalar variable" で発見されました。</p>
-</li>
-
-<li>pool_pools() での strftime() の用法を修正しました。(Tatsuo Ishii)
-<p>バッファが第 2 引数で期待する値にたいして十分な大きさではありませんでした。
-実際にはそのような長い値がわたることはなく、問題ないものです。</p>
-<p>これは Coverity "1111426 Out-of-bounds access" で発見されました。</p>
-</li>
-
-<li>make_persistent_db_connection のリソースリークを修正しました。(Tatsuo Ishii)
-<p>この修正のために、新しく free_persisten_db_connection_memory 関数を追加しました。</p>
-<p>これは Coverity #1111468 で発見されました。</p>
-</li>
-
-<li>watchdog: RTT が非常に短いときに <a href="#TRUSTED_SERVERS">trusted servers</a> への
-コネクションチェックに失敗する不具合をを、修正しました。(Yugo Nagata)
-</li>
-
-<li>Coverity で見つかったさまざまな不具合を修正しました。(Tatsuo Ishii)</li>
-
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.2.6"></a>3.2.6 (namameboshi) 2013/09/06</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<p>
-このバージョンは 3.2.5 に対するバグ修正リリースです。
-</p>
-
-<h3>バグ修正</h3>
-<ul>
-
-<li>
-    バックエンドエラー検出時に発生することがあるメインプロセスのセグメンテーション違反を修正しました。
-    (Tatsuo Ishii)
-    <p>
-    この問題はバグトラック #62 で tuomas さんにより報告されました。
-    </p>
-    <blockquote>
-    #62 Slave network outage causes a segmentation fault on main process<br />
-    <a href="http://www.pgpool.net/mantisbt/view.php?id=62">
-    http://www.pgpool.net/mantisbt/view.php?id=62
-    </a>
-    </blockquote>
-</li>
-
-<li>
-    child_life_time 使用時に発生しうるヘルスチェックのバグを修正しました。(Tatsuo Ishii)
-    <p>
-    バックエンドが正しく動作しているにも関わらずフェイルオーバが発生することがありました。この問題は
-    [pgpool-general: 1892] で larisa sabbanさんにより報告されました。
-    </p>
-    <blockquote>
-    [pgpool-general: 1892] Pgpool is unable to connect backend PostgreSQL<br />
-    <a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-July/001920.html">
-    http://www.sraoss.jp/pipermail/pgpool-general/2013-July/001920.html
-    </a>
-    </blockquote>
-</li>
-
-<li>
-    マニュアルの「pgpool-IIの配置について」の項目を改訂しました。(Tatsuo Ishii)
-    <p>
-    watchdog の使用に関する記述を追加しました。
-    </p>
-</li>
-
-<li>
-    doc/basebackup.sh スクリプトの ssh コマンドの間違いを修正しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    レプリケーションモードにおけるプリペアド文のパース処理を修正しました。(Tatsuo Ishii)
-    <p>
-    レプリケーションモードで SELECT 以外のクエリをパースする際には、
-    ノード間の一貫性保持のため自動的にトランザクションが開始されますが、
-    トランザクションを閉じる処理が行われていませんでした。
-    そのため、実際に誤っているクエリだけではなく、その次にパース処理されたクエリもアボートされていました。
-    </p>
-    <p>
-    このバグは [pgpool-general: 1877] で Sean Hogan さんにより報告されました。
-    </p>
-    <blockquote>
-    [pgpool-general: 1877] current transaction is aborted, commands ignored<br />
-    <a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-July/001905.html">
-    http://www.sraoss.jp/pipermail/pgpool-general/2013-July/001905.html
-    </a>
-    </blockquote>
-</li>
-
-<li>
-    インメモリクエリキャッシュ使用時に子プロセスが sig abort で異常終了するバグを修正しました。
-    (Tatsuo Ishii)
-    <p>
-    parse メッセージの後に複数の bind/execute メッセージが来た場合に発生していた、メモリの二重解放がこのバグの原因です。
-    parse メッセージが来ると、クエリコンテキストと共に一時的なキャッシュが作成され、
-    クエリの実行時にこの一時キャッシュを指すポインタが配列に追加されます。そして、続く複数の bind
-    メッセージがこの同じポインタを使用することが、キャッシュ削除の際に二重解放を引き起こす原因となっていました。
-    </p>
-    <p>
-    このバグはバグトラック #68 にて harukat さんにより報告されました。
-    </p>
-    <blockquote>
-    #68: child process termination with sigabort when memory_cache_enabled = on<br />
-    <a href="http://www.pgpool.net/mantisbt/view.php?id=68">
-    http://www.pgpool.net/mantisbt/view.php?id=68
-    </a>
-    </blockquote>
-</li>
-
-<li>
-    日本語ドキュメントの typo を修正しました。 (Yugo Nagata)
-</li>
-
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.2.5"></a>3.2.5 (namameboshi) 2013/07/10</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<p>このバージョンは 3.2.4 に対するバグ修正リリースです。</p>
-
-<h3>バグ修正</h3>
-<ul>
-<li>man ページに -D オプションの記述を追加しました。（Tatsuo Ishii)</li>
-
-<li>オンラインリカバリ時のフェイルバックの完了待機でタイムアウト処理をするようにしました。(Tatsuo Ishii)
-    <p>
-    これによりリカバリが永遠に終わらず pgpool-II が終了できなくなる状況を回避します。
-    この現象は特に <a href="#FOLLOW_MASTER_COMMAND">Wfollow_master_command</a> の実行中に起こり得ました。
-    </p>
-</li>
-
-<li>ストリームレプリケーションモードでの <a href="#FOLLOW_MASTER_COMMAND">follow_master_command</a> 実行時に、
-    %H に新しいプライマリノードが正しく割り当てられないバグを修正しました。(Tatsuo Ishii)
-</li>
-
-<li>watchdog ソケット作成時に、connect() の前に select() を実行していたのを修正しました。(Yugo Nagata)
-    <p>
-    未接続のソケットで select() を実行したときの処理は未定義で、プラットフォームで異なります。
-    Linux では 2 を返し、結果としては無害です。
-    しかし、Solarisでは 0 を返し、これはタイムアウトと区別がつかないため、watchdog が正しく動いていませんでした。
-    </p>
-</li>
-
-<li>pgpool_regclass がインストールされていない場合に生じるエラーを修正しました。(Tatsuo Ishii)
-    <p>
-    pgpool_rgcalss が存在しない場合に、pool_has_pgpool_regcalss() で使われているクエリが失敗していました。
-    詳しくは、[pgpool-general:1722] を参照してください。
-    </p>
-    <blockquote>
-    [pgpool-general: 1722] [PgPool-II 3.2.4] pgpool_regclass now mandatory? <br />
-    <a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-May/001749.html">
-    http://www.sraoss.jp/pipermail/pgpool-general/2013-May/001749.html
-    </a>
-    </blockquote>
-</li>
-
-<li>PostgreSQL がエラーを返したときに do_query() がハングしないよう修正しました。(Tatsuo Ishii)
-    <p>
-    典型的な症状が「pg_stat_activety によると SELECT が実行されたままのように見える」というものです。
-    これを解決するため、pgpool-II は当該プロセスを終了させ、既存のコネクションを捨てるように修正しました。
-    </p>
-</li>
-
-<li>watchdog を有効にしたときに、フェイルオーバの最中に起こりうるデッドロックを修正しました。(Yugo Nagata)
-    <p>
-    このバグは、バグトラッカ #54 にて arshu arora さんによって報告されました。
-    </p>
-    <blockquote>
-    #54 pgpool-II semaphore lock problem<br />
-    <a href="http://www.pgpool.net/mantisbt/view.php?id=54">
-    http://www.pgpool.net/mantisbt/view.php?id=54
-    </a>
-    </blockquote>
-</li>
-
-<li>拡張プロトコルの際に do_query で発生しうるハングアップを修正しました。(Tatsuo Ishii)
-    <p>
-    これは insert_lock が有効で、pgpool_catalog.insert_lock が存在することに起こり得ます。
-    詳しくは [pgpool-general: 1684] を参照してください。
-    </p>
-    <blockquote>
-    [pgpool-general: 1684] insert_lock hangs <br />
-    <a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-May/001711.html">
-    http://www.sraoss.jp/pipermail/pgpool-general/2013-May/001711.html
-    </a>
-    </blockquote>
-</li>
-
-<li>COMMIT 時エラーに不要なバックエンド切り離しを行わないようにしました。(Tatsuo Ishii)
-    <p>
-    マスタースレーブモードで、COMMIT 時にマスターノードでエラーが発生していたとしても、
-    他のスレーブノードが正常な場合にはバックエンドを切り離す必要はありません。
-    これは、遅延トリガーのために "kind mismatch error" が発生しうるからです。
-    </p>
-</li>
-
-<li>トランザクション内の DML で、クエリキャッシュの無効化が失敗する場合があるのを修正しました。(Tatsuo Ishii)
-<pre>
-CREATE TABLE t1(i INTEGER);
-CREATE TABLE t2(i INTEGER);
-SELECT * FROM t1;
-BEGIN;
-DELETE FROM t2 WHERE i = 0;
-INSERT INTO t1(i) VALUES(1);
-COMMIT;
-
-SELECT * FROM t1;
-</pre>
-    <p>
-    上の SQL で、COMMIT 発行時に pgpool は t2 のキャッシュを削除しようとします
-    が、実際には t2 のOID テーブルエントリがないのでこれは失敗します。そのとき
-    に、t1 の OID テーブルの確認までも失敗とみなされ、直前の t1 の SELECT 結果
-    のキャッシュが不正に残っていました。
-    </p>
-    <p>この問題はバグトラッカ #58 で wms さんにより報告されました。</p>
-    <blockquote>
-    #58 query cache invalidation does not fire for multiple DML in transaction<br />
-    <a href="http://www.pgpool.net/mantisbt/view.php?id=58">
-    http://www.pgpool.net/mantisbt/view.php?id=58
-    </a>
-    </blockquote>
-</li>
-
-<li>pgpool_regclass を pg_catalog スキーマに登録するよう修正しました。(Tatsuo Ishii)
-    <p>これは postgres_fdw のような、スキーマ検索パスが pg_catalog に限定されているクライアントに
-    対応するために必要です。
-</p>
-</li>
-
-<li>pg_md5 コマンドで起こりうるクラッシュを修正しました。(Muhammad Usama)</li>
-
-<li>インメモリクエリキャッシュ有効時に発生するセグメンテーション違反が修正されました。(Tatsuo Ishii))
-    <p>
-    これは、拡張クエリモードで実行されたクエリが長い結果を返すときに発生します。
-    このバグはバグトラック #63 にて、harukat さんにより報告、解析され、テストケースが提供されました。
-    </p>
-    <blockquote>
-    #63 Child process was terminated by segmentation fault with memcached<br />
-    <a href="http://www.pgpool.net/mantisbt/view.php?id=63">
-    http://www.pgpool.net/mantisbt/view.php?id=63
-    </a>
-</blockquote>
-</li>
-
-<li>スタートアップパケットに PostgreSQL ユーザ情報が含まれていなかった場合に発生する
-    子プロセスのセグメンテーション違反を修正しました。(Yugo Nagata)
-    <p>このバグは以下を実行することにより再現できます。</p>
-<pre>
-$ psql -p 9999 -U ''
-</pre>
-    <p><a href="#ENABLE_POOL_HBA">enable_pool_hba</a> が有効の場合は
-     子プロセスがセグメンテーション違反で異常終了し、
-    無効の場合には以下のメッセージがログに出力されていました。</p>
-<pre>
-ERROR: pool_discard_cp: cannot get connection pool for user (null) database (null)
-</pre>
-
-    <p>また、両方の場合で psql はフロントエンドに何のメッセージ出力せずに終了していました。
-    修正後は、スタートアップパケットに PostgreSQL ユーザが指定されていない場合には
-    以下のメッセージがログとフロントエンドの両方に出力されます。
-    これは PostgreSQLと同じ振る舞いです。
-    </p>
-<pre>
-FATAL: no PostgreSQL user name specified in startup packet
-</pre>
-</li>
-
-<li>インメモリクエリキャッシュを有効にした時の拡張クエリの処理におけるメモリ割り当てロジックを修正しました。(Tatsuo Ishii)
-    <p>バインドパラメータ付きの拡張クエリで、1024 バイト以上の長いクエリ文字列が渡されたときに、
-    十分なメモリ割り当てができていませんでした。
-    </p>
-    </li>
-
-<li>マニュアルの <a href="#SSL_CA_CERT">ssl_sa_cert</a>, <a href="#SSL_CA_CERT_DIR">ssl_ca_cert_dir</a>
-    オプションの説明を SSL セクションに移動しました。(Yugo Nagata)</li>
-
-<li><a href="#SSL_CA_CERT">ssl_sa_cert</a>, <a href="#SSL_CA_CERT_DIR">ssl_ca_cert_dir</a> オプションの説明を
-    日本語マニュアルに追加しました。(Yugo Nagata)</li>
-
-<li><a href="#pcp_recovery_node">pcp_recovery_node</a> コマンドで、
-    バックエンドノード番号をチェックするように修正しました。(Yugo Nagata)
-    <p>不正な値が使用された場合、リカバリで実行されるスクリプトの引数に空の値が渡されており、
-    誤動作の原因となっていました。
-    特にベースバックアップを行うスクリプトで、rsync が関係のないファイルを削除してしまうことがありました。
-    </p>
-</li>
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.2.4"></a>3.2.4 (namameboshi) 2013/04/26</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<p>このバージョンは 3.2.3 に対するバグ修正リリースです。</p>
-
-<h3>バグ修正</h3>
-<ul>
-<li>connect_inet_domain_socket_by_port() 関数内で select(2) に渡されるタイムアウトパラメータを
-    より適切に修正しました。(Tatuo Ishii)
-    <p>
-    Solaris などいくつかのプラットフォームでは、タイムアウトのマイクロ秒に
-    1000000 以上の大きな値を指定することが許されていません。そのため、タイム
-    アウト値を秒とマイクロ秒に分けて設定するようにしました。
-    </p>
-</li>
-
-<li>connect_inet_domain_socket_by_port() で alarm 割り込み時を受けた時に、
-    エラー処理を行うよう修正しました。(Tatsuo Ishii)
-    <p>
-    この関数が無効なファイルディスクリプタを返すためにヘルスチェックが混乱し、
-    エラー検出に長時間かかる原因となっていました。
-    </p>
-    <blockquote>
-    [pgpool-general: 1458]<br />
-    health check timeout in pgpool-II-3.2.3<br />
-    <a href="http://www.pgpool.net/pipermail/pgpool-general/2013-March/001482.html">
-    http://www.pgpool.net/pipermail/pgpool-general/2013-March/001482.html
-    </a>
-    </blockquote>
-</li>
-
-<li>拡張プロトコルの処理における timestamp の書き換えに関する
-    長い間見過ごされていてたバグを修正しました。(Tatsuo Ishii)
-    <p>
-    Parse() 関数は、parse メッセージの書き換えの際に palloc() を使ってメモリを確保していました。
-    書き換えられたメッセージは pool_create_sent_message()
-    関数などが管理するデータ領域に格納されますが、これが問題となっていました。
-    この関数ではデータが session context memory 中に存在することを想定しているのに対し、
-    palloc() では query context においてメモリの割り当てを行っており、この領域は
-    query context 終了時に解放されます。しかし、他の関数もこのメモリ領域を解放しようとするため、
-    セグメンテーション違反や二重解放を含む様々な問題の原因となっていました。
-    この問題は、書き換えたメッセージを格納するメモリを session context を用いて確保するこで修正されました。
-    これは pgpool-II 3.0 以来ずっと存在していたバグです。
-    </p>
-    <p>この問題は、Naoya Anzai さんによって解析され、パッチが提供されました。</p>
-    <blockquote>
-    [pgpoolgenera-jp: 1146]<br />
-    拡張問い合わせプロトコルでセグメンテーションフォルト<br />
-    <a href="http://www.pgpool.net/pipermail/pgpool-general-jp/2013-March/001145.html">
-    http://www.pgpool.net/pipermail/pgpool-general-jp/2013-March/001145.html
-    </a>
-    </blockquote>
-</li>
-
-<li>md5 認証で長いユーザ名を処理する際のバグを修正しました。(Tatsuo Ishii)
-<p>
-    ユーザ名が 32 バイトより長い場合、md5 認証が動作していませんでした。
-    この問題は [pgpool-general: 1526] で Thomas Martin さんにより報告されました。
-    </p>
-    <blockquote>
-    [pgpool-general: 1526]<br />
-    [pgPool-II 3.2.3] MD5 authentication and username longer than 32 characters.<br />
-    <a href="http://www.pgpool.net/pipermail/pgpool-general/2013-March/001551.html">
-    http://www.pgpool.net/pipermail/pgpool-general/2013-March/001551.html
-    </a>
-    </blockquote>
-</li>
-
-<li>レプリケーション遅延の計算はスタンバイサーバがプライマリサーバより遅れている場合にのみ
-    行うよう修正しました。(Yugo Nagata)
-    <p>
-    タイミングによってスタンバイよりプライマリの方がレプリケーションが遅延しているように見える場合があり、
-    その場合には負値の遅延が計算されていました。
-    この値が符号無し変数に代入されると、実際には遅延が生じていないにも関わらず、
-    ログに遅延が負値で出力され、されに悪いことには、ロードバランス機能により
-    SELECT クエリがプライマリに振り分けられ、その結果プライマリの負荷が高まることがありました。
-    </p>
-    <p>この問題は Saitoh Hidenori さんによって報告、解析されました。</p>
-    <blockquote>
-    [pgpool-genera-jp: 1145]<br />
-    レプリケーション遅延確認の不具合について<br />
-    <a href="http://www.pgpool.net/pipermail/pgpool-general-jp/2013-March/001144.html">
-    http://www.pgpool.net/pipermail/pgpool-general-jp/2013-March/001144.html
-    </a>
-    </blockquote>
-</li>
-
-<li>pgpool-recovery が PostgreSQL 9.3 に対応しました。 (Tatsuo Ishii)
-    <p>パッチは Asif Rehman さんにより提供され、これに Tatsuo Ishii が若干の修正を加えました。</p>
-    <blockquote>
-    [pgpool-hackers: 180] <br />
-    compile error in ppool-recovery<br />
-    <a href="http://www.pgpool.net/pipermail/pgpool-hackers/2013-April/000179.html">
-    http://www.pgpool.net/pipermail/pgpool-hackers/2013-April/000179.html
-    </a>
-    </blockquote>
-</li>
-
-<li>pool_has_pgpool_regclass が pgpool_regclass() の実行権限をチェックするよう修正しました。 (Tatsuo Ishii)
-    <p>
-    pgpool_regclass が存在する場合でも、pgpool がこの関数を実行できない場合に、
-    バックエンドへの接続がハングしていました。この問題は、pgpool_regclass
-    から実行権限を剥奪し、ネイティブレプリケーションモードで INSERT を実行
-    することで再現可能です。
-    </p>
-    <p>この問題は bugtrack #53 で報告されました。</p>
-    <blockquote>
-    #53 pgpool_regclas hangs all connections<br />
-    Date:     2013-04-04 13:35 <br />
-    Reporter: tmandke<br />
-    <a href="http://www.pgpool.net/mantisbt/view.php?id=53">
-    http://www.pgpool.net/mantisbt/view.php?id=53
-    </a>
-    </blockquote>
-</li>
-
-<li>detect_postmaster_down_error() のエラーメッセージを修正しました。(Tatsuo Ishii)
-    <p>
-    例えば、"LOG: detect_stop_postmaster_error: detect_error error" を
-    "LOG: detect_postmaster_down_error: detect_error error" に修正するなどです。
-    </p>
-</li>
-
-<li>watchdog 使用時の root ユーザであるかのチェックを取り除きました。(Tatsuo Ishii)
-    <p>詳しい議論は以下を参照してください。</p>
-    <blockquote>
-    [pgpool-general: 1627]<br />
-    Re: watchdog root requirement.<br />
-    <a href="http://www.pgpool.net/pipermail/pgpool-general/2013-April/001654.html">
-    http://www.pgpool.net/pipermail/pgpool-general/2013-April/001654.html
-    </a>
-    </blockquote>
-</li>
-
-<li>別名を持つ UPDATE/DELETE の処理におけるインメモリクエリキャッシュのバグを修正しました。(Tatsuo Ishii)
-    <p>
-    別名を持つ UPDATE/DELETE 文（例えば、UPDATE t1 AS foo ...）において、
-    "t1 AS foo" がテーブル名と認識されていたため、クエリキャッシュの無効化が
-    うまく働いていませんでした。
-    これは、パースツリーのノードからクエリ文を生成する nodeToString() 関数から呼び出されている
-    _outRangeVar() 関数に原因があります。
-    出力されたクエリ文から "AS foo" の部分を取り除くことで解決しました。
-    </p>
-    <p>この問題はバグトラック #56 で報告されました。</p>
-    <blockquote>
-    #56 UPDATE with alias does not discard cache<br />
-    Date:     2013-04-18 17:33 <br />
-    Reporter: harukat <br />
-    <a href="http://www.pgpool.net/mantisbt/view.php?id=56">
-    http://www.pgpool.net/mantisbt/view.php?id=56
-    </a>
-    </blockquote>
-</li>
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.2.3"></a>3.2.3 (namameboshi) 2013/02/18</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<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><a href="#322_bugfix_connect">3.2.2</a> で入り込んだ connect_inet_domain_socket_by_port() の
-    バグを修正しました。 (Tatsuo Ishii)
-    <p>
-    接続において non blocking の connect() が EINPROGRESS や EALREADY という結果を返したときには、
-    select(2) を呼んで read / write ファイルディスクリプタの準備されるまで待つようにしました。
-    </p>
-    <p>
-    本来は select() が 0 以上を返したときにそうするべきところを、0 を返したときだけになっていました。
-    その結果、connect_inet_domain_socket_by_port() が実際には失敗しているのに
-    成功していたと誤って返していました。
-    </p>
-    <p>
-    またさらに、これによって 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>
-
-<li>設定パラメータの一覧を表示する "<a href="#pool_status">SHOW pool_status</a>" で
-    <a href="#POOL_PASSWD">pool_passwd</a> が表示されていないのを修正しました。(Yugo Nagata)</li>
-
-<li>configure.in にある configure のヘルプの typo を修正しました。 (Yugo Nagata)</li>
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.2.2"></a>3.2.2 (namameboshi) 2013/02/08</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<p>このバージョンは 3.2.1 に対するバグ修正リリースです。</p>
-
-<h3>バグ修正</h3>
-<ul>
-<li>FreeBSD で発生するコンパイルエラーを修正しました。 (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>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>ロードバランスの条件について、より詳しい情報をマニュアルに追記しました。 (Tatso 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="#pcp_attach_node">pcp_attach_node</a>, <a href="#pcp_detach_node">pcp_detach_node</a> を
-    繰り返し実行したときに起こるハングアップを修正しました。 (Tatsuo Ishii)
-    <p>
-    <a href="#pcp_attach_node">pcp_attach_node</a>, <a href="#pcp_detach_node">pcp_detach_node</a> により
-    ノードステータスが変更された時、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>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>通常のテーブルと同名の一時テーブルがあるときに、クエリキャッシュの結果が不正になるバグを
-    修正しました。 (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<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>configure のヘルプメッセージの typo を修正しました。 (Yugo Nagata)</li>
-
-<li><a href="#WD_HOSTNAME">wd_hostname</a> を pool_process_reporting.c に追加しました。 (Yugo Nagata)
-    <p>
-    以前は <a href="#pool_status">SHOW pool_status</a>, <a href="#pcp_pool_status">pcp_pool_status</a>
-    の結果に <a href="#WD_HOSTNAME">wd_hostname</a> が出力されていませんでした。
-    </p>
-</li>
-
-<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>
-
-<li>health_check() が template1 データベースに再接続を試みる前に、ヘルスチェックタイマーを
-    チェックするよう修正しました。 (Tastuo Ishii)
-    <p>
-    修正前は、ヘルスチェックタイマーが既に期限を向かえているために、0 番ノードへのヘルスチェックの
-    再接続が常に失敗していました。
-    </p>
-</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>これは <a href="#DELAY_THRESHOLD">delay_threshold</a> が導入されて以来、ずっと存在していたバグです。</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<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>インメモリクエリキャッシュで、<a href="#BLACK_MEMQCACHE_TABLE_LIST">black_memqcache_table_list</a> に
-    テーブルが指定されている場合に <a href="#WHITE_MEMQCACHE_TABLE_LIST">white_memqcache_table_list</a> に
-    指定されたテーブルのみがキャッシュされていたバグを修正しました。
-    (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><a href="#FAIL_OVER_ON_BACKEND_ERROR">fail_over_on_backend_error</a> が無効のため
-    フェイルオーバが行われなかった場合には、ログメッセージを出力するようにしました。 (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 使用時は <a href="#NUM_INIT_CHILDREN">num_init_children</a> を大きめに設定するよう、
-    マニュアルに注意書きを追記しました。 (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>
-    修正前は、<a href="#pool_status">SHOW pool_status</a>, <a href="#pcp_pool_status">pcp_pool_status</a> の出力に
-    <a href="#POOL_PASSWD">pool_passwd</a> が含まれていませんでした。
-    </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_features">新機能</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>
-    <ul>
-    <li>watchdog を使用するかどうかを指定するパラメータ
-        <a href="#USE_WATCHDOG">use_watchdog</a> 追加しました。(Atsushi Mitani)</li>
-
-    <li>
-    pgpool-II の死活監視に関するパラメータ
-    <a href="#WD_INTERVAL">wd_interval</a>、
-    <a href="#WD_LIFE_POINT">wd_life_point</a>、
-    <a href="#WD_LIFECHECK_QUERY">wd_lifecheck_query</a>
-    を追加しました。(Atsushi Mitani)
-    </li>
-
-    <li>
-    アプリケーションサーバなど上部サーバへの接続に関するパラメータ
-    <a href="#TRUSTED_SERVERS">trusted_servers</a>、
-    <a href="$PING_PATH">ping_path</a> を追加しました。(Atsushi Mitani)
-    </li>
-
-    <li>
-    watchdog の相互死活監視に関するパラメータ
-    <a href="#WD_HOSTNAME">wd_hostname</a>、
-    <a href="#WD_PORT">wd_port</a>、
-    <a href="#OTHER_WD_PORT">other_wd_port</a>、
-    <a href="#OTHER_PGPOOL_HOSTNAME">other_pgpool_hostname</a>、
-    <a href="#OTHER_PGPOOL_PORT">other_pgpool_port</a>
-    を追加しました。 (Atsushi Mitani)
-    </li>
-
-    <li>
-    仮想 IP に関するパラメータ
-    <a href="#DELEGATE_IP">delegate_IP</a>、
-    <a href="#IFCONFIG_PATH">ifconfig_path</a>、
-    <a href="#IF_UP_CMD">if_up_cmd</a>、
-    <a href="#IF_DOWN_CMD">if_down_cmd</a>、
-    <a href="#ARPING_PATH">arping_path</a>、
-    <a href="ARPING_CMD">arping_cmd</a> を追加しました。(Atsushi Mitani)
-    </li>
-
-    </ul>
-    </dd>
-
-</dl>
-
-</li>
-
-<li>チュートリアル</li>
-<p><a href="#memqcache">インメモリクエリキャッシュ</a> と <a href="#watchdog">Watchdog 機能</a>
-   のチュートリアルを作成しました。(Nozomi Anzai)</p>
-
-</ul>
-
-<h3 id="3.2_enhansements">改良</h3>
-<ul>
-<li>HP-UX や AIX のような vsyslog を持たないプラットフォームもサポートするようにしました。(Tatsuo Ishii)</li>
-
-<li>ヘルスチェックで、リトライ回数とリトライ間隔秒数を指定できるようにしました。
-    このために、<a href="#HEALTH_CHECK_MAX_RETRIES">health_check_max_retries</a> と
-    <a href="#HEALTH_CHECK_RETRY_DELAY">health_check_retry_delay</a> というパラメータを新設しています。(Tatsuo Ishii)
-    <p>パッチは Matt Solnit さんが作成しました。</p>
-    <blockquote>
-    Subject: [Pgpool-hackers] Health check retries (patch)<br>
-    From: Matt Solnit<br>
-    Date: Fri, 18 Nov 2011 16:28:44 -0500
-    </blockquote>
-</li>
-
-<li>クエリの解析に失敗したとき、クライアントの IP とポート番号をログに書き出すようにしました。(Tatsuo Ishii)
-    <p>
-    これは、<a href="#LOG_CONNECTIONS">log_connections</a> を有効にしていなくても、
-    問題のあるクエリを発行したのがどのクライアントかを知るのに有用です。
-    特にログ出力の多く忙しい Webシステムで役立ちます。
-    </p>
-</li>
-
-<li>pool_process_query() が無限ループする場合があったのを修正しました。(Tatsuo Ishii)
-    <p>
-    これは、以下がそろったときに起こる可能性がありました。
-    </p>
-    <ul>
-    <li>クエリが実行中でない</li>
-    <li>マスタ以外のノードがデータを保持している</li>
-    </ul>
-
-    <p>以下で報告されました。</p>
-    <blockquote>
-    Subject: <a href="http://www.pgpool.net/pipermail/pgpool-general/2011-December/000042.html">[pgpool-general: 43]</a>
-    Re: [Pgpool-general] seemingly hung pgpool process consuming 100% CPU<br>
-    From: Lonni J Friedman<br>
-    Date: Tue, 6 Dec 2011 16:23:41 -0800
-    </blockquote>
-</li>
-
-<li><a href="#pool_nodes">SHOW pool_nodes</a> に role の列を足しました。
-    この列には Primary か Standbyかが出力されます。(Tatsuo Ishii)</li>
-
-<li>PostgreSQL 9.2 に対応しました。(Tatsuo Ishii)</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> がなかったので追加しました。
-    また、pgpool.conf の順にソートしました。(Nozomi Anzai)
-</li>
-
-<li>pgpool.conf のサンプルファイルで、system db に関するパラメータをコメントアウトしました。(Nozomi Anzai)</li>
-
-<li><a href="#failover">failover/failback/followmaster コマンド</a> に新しいパラメータを追加しました。(Tatsuo Ishii)
-<pre>%r: new master port number
-%R: new master database cluster path
-</pre>
-</li>
-
-<li>md5 認証のパスワードを変更が reload でできるようにしました。(Tatsuo Ishii)
-    <p>
-    これまでは pgpool-II を再起動する必要がありました。
-    このパッチは Gurjeet Singh さんが作成しました。
-    </p>
-</li>
-
-<li>マニュアルの見た目を改善しました。また、パラメータ名などページ内リンクを増やしました。(Nozomi Anzai)</li>
-
-<li>is_set_transaction_serializable() 関数から使用されていない引数 query を削除しました。(Tastuo Ishii)</li>
-
-<li>pgpool.conf の in memory query cache セクションのコメントを他のセクションと同じ様式に修正しました。(Tatsuo Ishii)</li>
-
-<li>pgpool.conf.sample-master-slave, pgpool.conf.sample-replication, pgpool.conf.sample-stream に
-   抜けていたオプション health_check_max_retries, health_check_retry_delay を追加しました。(Tastuo Ishii)</li>
-</ul>
-
-<h3 id="3.2_bugfix">バグ修正</h3>
-
-<ul>
-<li>Raw モードでのメモリリークを修正しました。(Tatsuo Ishii)</li>
-
-<li>Raw モードでのフェイルオーバ・フェイルバックを修正しました。(Tatsuo Ishii)
-    <ul>
-    <li>対象ノードがマスタでないときに、フェイルオーバしませんでした。</li>
-    <li>ノードが接続受付状態でないとき、どのノードをマスタにするか選定できませんでした。</li>
-    </ul>
-</li>
-
-<li>connect() 中にヘルスチェックのリトライができるようにしました。(Tatsuo Ishii)
-    <p>
-    これは、システムがセキュリティ上の理由で接続先に接続できなかったという
-    メッセージを返さないように設定されているときに、sigalarm がブロックされているという報告によります。
-    変更の一部は Stevo Slavic さんが提供しました。
-    </p>
-
-    <blockquote>
-    Subject: <a href="http://www.pgpool.net/pipermail/pgpool-general/2012-January/000131.html">[pgpool-general: 131]</a>
-    Healthcheck timeout not always respected<br>
-    From: From: Stevo Slavic<br>
-    Date: Tue, 10 Jan 2012 21:16:01 +0100
-    </blockquote>
-</li>
-
-<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="#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><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>バックエンドをリセットする <a href="#RESET_QUERY_LIST">reset_query_list</a> のクエリを実行に
-       時間がかかったときに発生する可能性があり、またクラッシュすることがありました。</p>
-</li>
-
-<li>マスタ・スレーブモードでの BEGIN TRANSACTION の扱いを修正しました。(Tatsuo Ishii)
-    <p>
-    これは <a href="http://www.pgpool.net/pipermail/pgpool-general/2012-July/000719.html">[pgpool-general: 714]</a>
-    で報告されました。
-    </p>
-    <p>
-    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/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>SET TRANSACTION ISOLATION LEVELSERIALIZABLE などのクエリはプライマリのみに送るよう
-    send_to_where() を修正しました。(Tatsuo Ishii)
-    <p>
-    マスタ・スレーブモードで、以前はこのクエリはプライマリだけではなくスタンバイにも送られていましたが、
-    もちろんこれはエラーとなります。同じようなクエリとして以下のものがあります。
-    </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>
-
-    <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>
-
-<li>インメモリクエリキャッシュで memcached を利用している場合、
-    memcached サーバが停止していてもエラーを起こさないようにしました。(Tatsuo Ishii)
-    <p>
-    これは主に、memcached_get() が MEMCACHED_NOTFOUND 以外のエラーを返した場合には、
-    pool_fetch_cache() が "cache not found" を装うように修正することで対処しました。
-    また、その場合には後のエラーを防ぐために pool_config-&gt;memory_cache_enabled を 0
-    にセットするようにしました。
-    </p>
-</li>
-
-<li>rerun libtoolize with --copy and --force option を実行しました。(Tatsuo Ishii)
-    <p>
-    これにより環境によって発生するビルドの問題が回避できます。以下のコマンドが実行されました。
-    </p>
-<pre>
-libtoolize --copy --force
-aclocal
-autoheader
-automake -a
-autoconf
-</pre>
-</li>
-
-<li>SSL_read() が不明のエラーを返した場合には EOF の検出とみなし、呼出元の pool_read() には
-    0 を返すよう pool_ssl_read() を修正しました。(Tatsuo Ishii)
-    <p>
-    これは libpq と同じ振る舞いです。また、これにより pool_read() での望ましくないフェイルオーバを回避することが出来ます。
-    これは、pool_read() は下層の I/O 関数（read(2), pool_ssl_read）が -1 を返したときにフェイルオーバを引き起こすからです。
-    </p>
-</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: &lt;SNIP&gt;
-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>
-
-<!-- ================================================================================ -->
-<!-- 3.1                                                                              -->
-<!-- ================================================================================ -->
-<hr><a name="release3.1.x"></a>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.1.15"></a>3.1.15 (hatsuiboshi) 2015/07/24</h2>
-<!-- -------------------------------------------------------------------------------- -->
-
-<h3>概要</h3>
-<p>
-このバージョンは 3.1.14 に対するバグ修正リリースです。
-</p>
-
-<h3>バグ修正</h3>
-<ul>
-
-<li>
-    pgpool-recovery の "cannot find xlog functions" エラーを修正しました。(Muhammad Usama)
-    <p>
-    PostgreSQL 9.4 より、PostgreSQL の pg_xlogfile_name() 関数の引数型はtext からpg_lsn に変更されていますが、pgpool-recovery は依然として古いシグネチャで関数を配置しようとしていました。
-    </p>
-</li>
-
-<li>
-    拡張問い合わせクエリで、レプリケーションモード以外の場合には、insertlock をチェックするクエリを送信しないようになりました。(Tatsuo Ishii)
-</li>
-
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.1.14"></a>3.1.14 (hatsuiboshi) 2015/04/08</h2>
-<!-- -------------------------------------------------------------------------------- -->
-
-<h3>概要</h3>
-<p>
-このバージョンは 3.1.13 に対するバグ修正リリースです。
-</p>
-
-<h3>バグ修正</h3>
-<ul>
-
-<li>
-    POOLCONFIG_MAXDESCLEN を 80 まで増やしました (Tatsuo Ishii)
-    <p>
-    これは show pool_status コマンドでパラメータの説明文の長さ制限に使われていますが、recovery_timetout ではこれが 64 文字であり、以前のマクロ定義では 1 文字分不足していました。
-    </p>
-</li>
-
-<li>
-    フロントエンド接続の証明書ファイルで SSL 証明書チェーンに対応しました。(Muhammad Usama)
-</li>
-
-<li>
-    pcp_detach_node が graceful にノードを切り離す際の問題を修正しました。(Muhammad Usama)
-    <p>
-    graceful なノード切り離しでは、そのノードの切り離し処理が許されているかの判断を、pcp_detach_node は新しい接続のブロックと既存の接続の切断よりも前に行う必要があります。
-    </p>
-</li>
-
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.1.13"></a>3.1.13 (hatsuiboshi) 2015/02/05</h2>
-<!-- -------------------------------------------------------------------------------- -->
-
-<h3>概要</h3>
-<p>
-このバージョンは 3.1.12 に対するバグ修正リリースです。
-</p>
-
-<h3>バグ修正</h3>
-<ul>
-
-<li>
-    doc: スレーブノードの数は１である必要でないことを明記しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    未初期化の変数があったのを修正しました。(Tatsuo Ishii)
-    <p>
-    Coverity の報告 #1234603 によります。
-    </p>
-</li>
-
-<li>
-    doc: 前回のリリースで抜け落ちていたリリースノートを追記しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    trigger_failover_command() 関数のノード ID 範囲検査のバグを修正しました。(Tatsuo Ishii)
-    <p>
-    ノード ID は定数 NUM_BACKENDS 未満である必要があります。実際にはNUM_BACKENDS 以上の値はこの関数に渡されていなかったので、おそらく害はありませんでした。
-    </p>
-</li>
-
-<li>
-    設定ファイルのリロードにより debug モードを無効にできるよう修正しました。(Yugo Nagata)
-    <blockquote>
-    bug #114 の報告によります。<br />
-    <a href="http://www.pgpool.net/mantisbt/view.php?id=114">
-    http://www.pgpool.net/mantisbt/view.php?id=114
-    </a>
-    </blockquote>
-</li>
-
-
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.1.12"></a>3.1.12 (hatsuiboshi) 2014/09/05</h2>
-<!-- -------------------------------------------------------------------------------- -->
-
-<h3>概要</h3>
-<p>
-このバージョンは 3.1.11 に対するバグ修正リリースです。
-</p>
-
-<h3>バグ修正</h3>
-<ul>
-
-<li>
-    pgpool.spec のタイポを修正しました。(Yugo Nagata)
-</li>
-
-<li>
-    プライマリバックエンドが存在しない場合に、ワーカー子プロセスが終了と再起動を繰り返すバグを修正しました。(Tatsuo Ishii)
-    <p>
-    問題の同定と修正は Junegunn Choi さんの貢献によります。
-    </p>
-    <p>
-    詳しくは、[pgpool-hackers: 471] を参照してください。
-    </p>
-</li>
-
-<li>
-    スマートシャットダウンの実行時には受信用ソケットを閉じるように修正しました。(Tatsuo Ishii)
-    <p>
-    スマートシャットダウンが実行された場合でも、pgpool の子プロセスは受信用のポートを開いており、最終的に失敗するにもかからわずクライアントは接続要求を送信可能です。これは時間の無駄であるだけではなく、pgpool のフロントにいるロードバランサによる pgpool の停止の検出を妨げます。
-    </p>
-    <p>
-    この問題は [pgpool-hackers 474] にて Junegunn Choi によって解析され、パッチが提供されました。これを Tatsuo Ishii が改良し、inet ドメインだけではなく UNIX ドメインのソケットにも対応させました。
-    </p>
-</li>
-
-<li>
-    doc: PostgreSQL の statement_timeout によって、リカバリコマンドが終了させられる可能性を追記しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    dic: 現在は当てはまらない古い制限事項を削除しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    text_to_lsn() 関数の返却値型を修正しました。(Yugo Nagata)
-    <p>
-    コンパイル時の警告の原因となっていました。
-    </p>
-</li>
-
-<li>
-    デーモン化した際にファイル識別子が閉じられていなかったのを修正しました。(Tatsuo Ishii)
-    <p>
-    Coverity の報告 #1111471 によります。
-    </p>
-</li>
-
-<li>
-    メモリリークを修正しました。 (Tatsuo Ishii)
-    <p>
-    Coverity の報告 #1111442 によります。
-    </p>
-</li>
-
-<li>
-    長らく放置されていた pgool.init の stop/restart のバグを修正しました。(Yugo Nagata)
-    <p>
-    以前は pgpool の停止に pgpool.init は killproc を用いていましたが、これにはいくつか問題がありました。これを、"pgpool -m fast stop" を用いるように修正しました。
-    </p>
-    <p>
-    Ryan DeShone により提供されたパッチを Yugo Nagata が修正しました。
-    </p>
-    <p>
-    詳しくは、[pgpool-hackers: 239][pgpool-hackers: 512] を参照してください。
-    </p>
-</li>
-
-<li>
-    オンラインリカバリの実行時は PostgreSQL の statement_timeout を無効にするようになりました。(Tatsuo Ishii)
-    <p>
-    オンラインリカバリは異常に長い時間を要する可能性がある一方、ユーザは statement_timeout を有効にしている可能性があります。これによりオンラインリカバリがキャンセルされるのを防ぐため、リカバリの最中は statement_timeout を無効にするようになりました。
-    </p>
-    <p>
-    詳しくは [pgpool-general: 2919] を参照してください。
-    </p>
-</li>
-
-<li>
-    不適切にセマフォを削除しないよう不必要な pool_shmem_exit() 呼び出しを取り除きました。(Tatsuo Ishii)
-    <p>
-    exit_handler はプロセスが親プロセスがどうかをチェックしていますが、子プロセスであった場合にも pool_shmem_exit() が呼ばれることがあり、これにより不適切にセマフォが削除されていました。この関数は親プロセス以外に呼ばれてはなりません。
-    </p>
-    <blockquote>
-    bug #102 によります。<br />
-    <a href="http://www.pgpool.net/mantisbt/view.php?id=102">
-    http://www.pgpool.net/mantisbt/view.php?id=102
-    </a>
-    </blockquote>
-</li>
-
-<li>
-    リセット用クエリにより発生するハングを修正しました。(Tatsuo Ishii)
-    <p>
-    DISCARD ALL などのリセットクエリが完了せず、pgpool の子プロセスがバックエンドからの反応を待ったまま固まってしまい、新しいクライアントからの接続が受けられなくなる問題が報告されました。
-    </p>
-    <p>
-    原因はまだ特定されていませんが、クライアントの接続がクエリ処理の最中に突然切断された場合、バックエンドがクエリを処理できない状態となり、リセットクエリを受け付けられなくのかもしれません。
-    </p>
-    <p>
-    これに対処するため、フロントエンドから接続が予期せず切断された場合は、クエリ処理ループを即座に終了し PostgreSQL への接続を切断し、新しい接続要求を待つように修正しました。
-    </p>
-    <p>
-    また client_idle_limit が設定されており、リミットに達した場合にもpgpool はバックエンドへの接続を切断するよう修正されました。
-    </p>
-    <blockquote>
-    bug #107 の報告によります。<br />
-    <a href="http://www.pgpool.net/mantisbt/view.php?id=107">
-    http://www.pgpool.net/mantisbt/view.php?id=107
-    </a>
-    </blockquote>
-</li>
-
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.1.11"></a>3.1.11 (hatsuiboshi) 2014/03/24</h2>
-<!-- -------------------------------------------------------------------------------- -->
-
-<h3>概要</h3>
-<p>
-このバージョンは 3.1.10 に対するバグ修正リリースです。
-</p>
-
-<h3>バグ修正</h3>
-<ul>
-
-<li>
-    doc: num_init_children の項に「listen キュー」の説明とその「バックログ」を増やす方法について追記しました。
-    (Tatsuo Ishii)
-</li>
-
-<li>
-    UNLOGGED テーブルを検出する処理のパフォーマンスが悪かったのを修正しました。
-    (Tatsuo Ishii)
-    <p>
-    この問題は <a href="http://www.sraoss.jp/pipermail/pgpool-hackers/2014-January/000435.html">[pgpool-hackers: 435]</a>
-    <a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-December/002354.html">[pgpool-general:2325]</a> で指摘されました。
-    </p>
-</li>
-
-<li>
-    プライマリノードの検出ロジックを修正しました。(Tatsuo Ishii)
-    <p>
-    プライマリノードが検出されないことがありました。例えば、node 0 がプライマリ、node 1
-    がスタンバイのときに、node 0 が落ちたとします。ヘルスチェックがそれを検出しますが、
-    内部のステータスがまだ更新されていない場合 node 0 には問題がないよう見えるため node 0
-    への接続が試みられます。実際にはこの接続は失敗するため、node 1
-    が新プライマリであることを検出する前に処理が終了していました。
-    </p>
-    <p>
-    この問題は <a href="http://www.sraoss.jp/pipermail/pgpool-general/2014-January/002442.html">[pgpool-general: 2409]</a> にて報告されました。
-    </p>
-</li>
-
-<li>
-    raw モードで自動コミットが off で JDBC を使用したときに、DML
-    が失敗するバグを修正しました。(Tatsuo Ishii)
-    <p>
-    この問題は <a href="http://www.pgpool.net/mantisbt/view.php?id=92">bug #92</a> で報告されました。
-    </p>
-</li>
-
-<li>
-    ストリーミングレプリケーションモードで無関係なノードにはクエリを送信しないように修正しました。
-    (Tatsuo Ishii)
-    <p>
-    pgpool-II は BEGIN, END, SET などのクエリを全ての DB ノードに送っています。
-    しかし、ストリーミングレプリケーションではプライマリノードと高々１台のスタンバイノードにしか送る必要がありません。
-    （もしプライマリノードがロードバランスノードとして選択されている場合には１台だけで充分です。）
-    </p>
-    <p>
-    詳細は <a href="http://www.sraoss.jp/pipermail/pgpool-hackers/2014-February/000464.html">
-    [pgpool-hackers: 464]</a> を参照してください。
-    </p>
-</li>
-
-<li>
-    バッファオーバランとメモリリークの可能性を修正しました。(Tatsuo Ishii)
-    <p>
-    Coverity 1111465, 1111482 の報告によります。
-    </p>
-</li>
-
-<li>
-    バッファオーバランを修正しました。(Tatsuo Ishii)
-    <p>
-    strcpy() を strlcpy() で置き換えました。Coverity 1111478, 1111480 の報告によります。
-    </p>
-</li>
-
-<li>
-    NULL ポインタの解放を修正しました。(Tatsuo Ishii)
-    <p>
-    Coverity 1111384 の報告によります。
-    </p>
-</li>
-
-<li>
-    メモリリークを修正しました。(Tatsuo Ishii)
-    <p>
-    Coverity 1111446 の報告によります。
-    </p>
-</li>
-
-<li>
-    パラレルモードで system_db_hostname
-    が空欄の場合に発生するセグメンテーションフォルトを修正しました。
-    (Yugo Nagata)
-</li>
-
-<li>
-    -d オプションで起動した場合に pgpool.conf
-    の処理中のデバッグメッセージを出力するように修正しました
-    (Yugo Nagata)
-    <p>
-    以前は -d オプション使用時でも出力されていないデバッグメッセージがありました。
-    </p>
-</li>
-
-<li>
-    レプリケーションモードで JDBC 使用時に now()
-    を含む準備文で発生する例外を修正しました。(Yugo Nagata)
-    <p>
-    JDBC で準備文を PrepareThreshold 回以上実行した場合には、文に名前が付けられ Parse
-    の後に Describe メッセージが発行されます。このとき、pgpool は now()
-    をパラメータに書き換えるため、元のクエリには無かった新しいパラメータが追加されます。
-    この場合、フロントエンドに返されるParameterDscription メッセージ（Describe
-    の返答）は、元のクエリが持つパラメータと同じ数の OID を含むべきです。そうしないと、JDBC
-    はArrayIndexoutOfBoundsException 例外を発生させてしまいます。
-    </p>
-    <p>
-    このバグは <a href="http://www.sraoss.jp/pipermail/pgpool-general-jp/2013-September/001191.html">
-    [pgpool-general-jp: 1192]</a> で報告されました。
-    </p>
-</li>
-
-<li>
-    レプリケーションモードにて、デフォルト値が now()
-    のカラムを持つテーブルに対する準備文でエラーが発生するバグを修正しました。
-    (Yugo Nagata)
-    <p>
-    デフォルト値が now() を持つ名前付き準備文を parse する際に、pgpool-II
-    は時刻値をパラメータで置き換えます。そのため、その後の bind
-    メッセージも追加されたパラメータの形式コードを含んでいる必要があります。
-    しかし、元のクエリのパラーメータ形式数が１だった場合、この処理がなされていませんでした。これが
-    "incorrect binary data format in bind parameter 2" のようなエラーの原因となっていました。
-    </p>
-</li>
-
-<li>
-    doc: パラレルモードは PREPARE 文の実行に対応していないことを追記しました。(Yugo Nagata)
-    <p>
-    <a href="http://www.pgpool.net/mantisbt/view.php?id=93">bug #93</a> の指摘によります。
-    </p>
-</li>
-
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.1.10"></a>3.1.10 (hatsuiboshi) 2013/12/06</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<p>
-このバージョンは 3.1.9 に対するバグ修正リリースです。
-
-<h3>バグ修正</h3>
-<ul>
-
-<li>レプリケーションモード稼働時、一部のタイムゾーンでタイムスタンプの書き換えが誤っていました。(Tatsuo Ishii)
-<p>タイムスタンプの書き換え処理では、現在日時を取得するあめに "SELECT now()" を実行します。
-しかし一部のタイムゾーンにおいては、"02:30" のような場合に現在日時のためのバッファの大きさが
-十分ではありませんでした。"0900" のように 30 分刻みでのタイムゾーンでないときは、この問題は発生しません。
-そのため、これまでこの不具合が報告されたことはありませんでした。</p>
-<p>この不具合は <a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-September/002142.html" target="_blank">[pgpool-general: 2113]</a> で報告され、Sean Hogan さんによって修正が提供されました。</p>
-</li>
-
-<li>Makefile: Makefiles 内の pg_config を $(PG_CONFIG) に置き換えました。
-したがって、PostgreSQL のメジャーバージョンが異なる場合には、コンパイル中で上書きされるようになります。(Tatsuo Ishii)
-<p>パッチは Christoph Berg さんから提供されました。（<a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-September/002156.html" target="_blank">[pgpool-general: 2127]</a>）</p>
-</li>
-
-<li>configure: FreeBSD で問題があったため、-lcompat を削除しました。(Tatsuo Ishii)
-<p><a href="http://www.pgpool.net/mantisbt/view.php?id=15">bug#15</a> で報告されました。</p>
-</li>
-
-<li>pgpool.conf で <a href="#LOG_STANDBY_DELAY">log_standby_delay</a> を設定してないときに
-segfault していたのを修正しました。(Tatsuo Ishii)
-<p>これは、pool_config.l での log_standby_delay の初期化が誤っていたためです。
-<a href="http://www.pgpool.net/mantisbt/view.php?id=74" target="_blank">bug#74</a> として報告されました。</p>
-</li>
-
-<li>doc: パラレルモードの制限事項を追記しました。VALUES 句を使った複数行の INSERT はパラレルモードではサポートされていません。(Yugo Nagata)</li>
-
-<li>スタンバイノードがダウンしようとしているときに find_primary_node_repeatedly() が
-呼ばれないようにしました。(Tatsuo Ishii)
-<p>これによってフェイルオーバの所要時間が短くなります。
-<a href="http://www.pgpool.net/mantisbt/view.php?id=75" target="_blank">bug#75</a> として報告され、
-パッチを Tatsuo Ishii が編集しました。</p>
-</li>
-
-<li>レプリケーションモードと拡張プロトコルを組み合わせた場合に、
-データ不整合があったのでこれを修正しました。(Tatsuo Ishii)
-<p>JDBC ドライバを使った同時 INSERT で、ノード間でのデータ不整合があるという報告がありました。
-この事象は以下の条件で必ず発生します。
-</p>
-<ol>
-    <li>レプリケーションモードを使用している</li>
-    <li>拡張プロトコルを使用している</li>
-    <li>parse で作成された portal が bind で再利用される</li>
-    <li>autocommit が on である</li>
-    <li>SERIAL（シーケンス）を使用している</li>
-</ol>
-
-<p>pgpool-II の parse 関数は、クライアントが INSERT (+ 5 の状態）を発行すると、対象テーブルをロックされていることを
-認識しています。しかし、bind 関数はそれを認識していませんでした。
-一度 parse / bind / execute が完了すると、pgpool は 4 の理由により parse で獲得したロックを解放します。
-そして JDBC は portal を再利用しようとし、ロックを獲得しないまま bind からのサイクルを開始してしまいます。
-その結果、ロックのない INSERT がノード間でのデータ不整合を引き起こします。
-この解決方法としては、bind でテーブルをロックするようにしました。
-</p>
-<p>この問題は、たいていのユーザは JDBC を autocommit = off で使っているために、
-今まで報告されることがありませんでした。off であれば、ユーザが commit / rollback を発行するまで、
-parse によるロックが残存するためです。</p>
-<p>この不具合は Steve Kuekes さんにより、<a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-September/002171.html" target="_blank">[pgpool-general: 2142]</a> で報告されました。</p>
-</li>
-
-<li>read_password_packet() のエラーメッセージを修正しました。(Tatsuo Ishii)</li>
-
-<li>do_query() がタイムスタンプの書き換えに失敗したとき、メモリリークしていました。(Tatsuo Ishii)
-<p>この修正のために、free_select_result() で NULL 引数を受け取れるようにしました。</p>
-<p>これは Coverity "1111454, 1111455 Resource leak" で発見されました。</p>
-</li>
-
-<li>"<code>DEALLOCATE portal|statement</code>" 実行時の対象ノードの選定ロジックを修正しました。(Tatsuo Ishii)
-<p>"<code>DEALLOCATE portal|statement</code>" 実行時、最後の prepared statement や portal が見つからない場合に、
-対象ノード選定マップがセットされていませんでした。
-おそらく、そうした場合はエラーなので、実際には問題ありません。</p>
-<p>これは Coverity "1111491 Structurally dead code" で発見されました。</p>
-</li>
-
-<li>MAX_NUM_BACKENDS の範囲チェックにおける不具合を修正しました。 (Tatsuo Ishii)
-<p>MAX_NUM_BACKENDS は DB ノードの最大数が限界値でした（現時点では 128）。
-実際には 128 の DB ノードで試す人がいなかったために、発見されなかった不具合のようです。</p>
-<p>これは Coverity "1111429, 1111430 and 1111431 Out-of-bounds write" で発見されました。</p>
-</li>
-
-<li>フロントエンド接続情報を、すでに無効なバックエンドについて set/unset しないようにしました。(Tatsuo Ishii)
-<p>この不具合は <a href="http://www.pgpool.net/mantisbt/view.php?id=82" target="_blank">bug#82</a> で報告されました。</p>
-</li>
-
-<li>pgpool_catalog への public access を許可していませんでした。
-<p>これは、pgpool_catalog がレプリケーションモードで作成されている場合に、
-ユーザテーブルにデータを INSERT すると発生します。</p>
-<p>この不具合は <a href="http://www.sraoss.jp/pipermail/pgpool-general-jp/2013-November/001228.html" target="_blank">[pgpool-general-jp: 1229]</a> で報告されました。</p>
-</li>
-
-<li>pool_do_auth() のエラーケースで変数を初期化していませんでした。 (Tatsuo Ishii)
-<p>有効なバックエンドがいないとき、pgpool は認証フェーズのフロントエンドにごみの pid を返していました。
-実際に、有効なバックエンドがいないために、フロントエンドは認証後に接続することができません。
-もちろんこれは問題あるものではありません。</p>
-<p>これは Coverity "1127331 Uninitialized scalar variable" で発見されました。</p>
-</li>
-
-<li>ノード ID を使ったエラーメッセージの発行時に、ノード ID の範囲チェックをするようにしました。
-(Tatsuo Ishii)
-<p>これは Coverity "1111433 "Out-of-bounds read" で発見されました。</p>
-</li>
-
-<li>parse_copy_data() でのバッファオーバーランとリソースリークを修正しました。 (Tatsuo Ishii)
-<p>これは Coverity "1111427 Out-of-bounds write"、"1111453 Resource leak" で発見されました。</p>
-</li>
-
-<li>CopyDataRaws() で segfault する可能性があったのを修正しました。(Tatsuo Ishii)
-<p>pool_get_id() がエラーを返した場合に VALID_BACKEND が配列外にアクセスしようとしていました。</p>
-<p>これは Coverity "1111433 Out-of-bounds read" で発見されました。</p>
-</li>
-
-<li>クエリキャッシュ有効 + プロトコルバージョン = 2 の組み合わせでの処理を修正しました。(Tatsuo Ishii)
-<p>プロトコルバージョンが 2 のとき、セッション状態が "idle" である前提でしたが、
-実際にはそうではありませんでした。
-プロトコルバージョンが 2 の場合はクエリキャッシュを使用しないことをおすすめします。</p>
-<p>これは Coverity "1111488 Uninitialized scalar variable" で発見されました。</p>
-</li>
-
-<li>make_persistent_db_connection のリソースリークを修正しました。(Tatsuo Ishii)
-<p>この修正ののために、新しく free_persisten_db_connection_memory 関数を追加しました。</p>
-<p>これは Coverity #1111468 で発見されました。</p>
-</li>
-
-<li>Coverity で見つかったさまざまな不具合を修正しました。(Tatsuo Ishii)</li>
-
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.1.9"></a>3.1.9 (hatsuiboshi) 2013/09/06</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<p>
-このバージョンは 3.1.8 に対するバグ修正リリースです。
-</p>
-
-<h3>バグ修正</h3>
-<ul>
-
-<li>
-    doc/basebackup.sh スクリプトの ssh コマンドの間違いを修正しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    レプリケーションモードにおけるプリペアド文のパース処理を修正しました。(Tatsuo Ishii)
-    <p>
-    レプリケーションモードで SELECT 以外のクエリをパースする際には、
-    ノード間の一貫性保持のため自動的にトランザクションが開始されますが、
-    トランザクションを閉じる処理が行われていませんでした。
-    そのため、実際に誤っているクエリだけではなく、その次にパース処理されたクエリもアボートされていました。
-    </p>
-    <p>
-    このバグは [pgpool-general: 1877] で Sean Hogan さんにより報告されました。
-    </p>
-    <blockquote>
-    [pgpool-general: 1877] current transaction is aborted, commands ignored<br />
-    <a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-July/001905.html">
-    http://www.sraoss.jp/pipermail/pgpool-general/2013-July/001905.html
-    </a>
-    </blockquote>
-</li>
-
-<li>
-    日本語ドキュメントの typo を修正しました。 (Yugo Nagata)
-</li>
-
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.1.8"></a>3.1.8 (hatsuiboshi) 2013/07/10</h2>
-<!-- -------------------------------------------------------------------------------- -->
-
-<h3>概要</h3>
-<p>
-このバージョンは 3.1.7 に対するバグ修正リリースです。
-</p>
-<h3>バグ修正</h3>
-<ul>
-<li>
-man ページに -D オプションの記述を追加しました。（Tatsuo Ishii)
-</li>
-
-<li>
-オンラインリカバリ時のフェイルバックの完了待機でタイムアウト処理をするようにしました。(Tatsuo Ishii)
-<p>
-これによりリカバリが永遠に終わらず pgpool-II が終了できなくなる状況を回避します。
-この現象は特に follow_master_command の実行中に起こり得ました。
-</p>
-</li>
-
-<li>
-ストリームレプリケーションモードでの follow_master_command 実行時に、%H に新しいプライマリノードが正しく割り当てられないバグを修正しました。
-(Tatsuo Ishii)
-</li>
-
-<li>
-PostgreSQL がエラーを返したときに do_query() がハングしないよう修正しました。
-(Tatsuo Ishii)
-<p>
-典型的な症状が「pg_stat_activety によると SELECT が実行されたままのように見える」というものです。
-これを解決するため、pgpool-II は当該プロセスを終了させ、既存のコネクションを捨てるように修正しました。
-</p>
-</li>
-
-<li>
-拡張プロトコルの際に do_query で発生しうるハングアップを修正しました。
-(Tatsuo Ishii)
-<p>
-これは insert_lock が有効で、pgpool_catalog.insert_lock が存在することに起こり得ます。
-詳しくは [pgpool-general: 1684] を参照してください。
-</p>
-<blockquote>
-  [pgpool-general: 1684] insert_lock hangs <br />
-  <a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-May/001711.html">
-  http://www.sraoss.jp/pipermail/pgpool-general/2013-May/001711.html
-  </a>
-</blockquote>
-</li>
-
-<li>
-COMMIT 時エラーに不要なバックエンド切り離しを行わないようにしました。
-(Tatsuo Ishii)
-<p>
-マスタースレーブモードで、COMMIT 時にマスターノードでエラーが発生していたとしても、他のスレーブノードが正常な場合にはバックエンドを切り離す必要はありません。
-これは、遅延トリガーのために "kind mismatch error" が発生しうるからです。
-</p>
-</li>
-
-<li>
-pgpool_regclass を pg_catalog スキーマに登録するよう修正しました。
-(Tatsuo Ishii)
-<p>
-これは postgres_fdw のような、スキーマ検索パスが pg_catalog に限定されているクライアントに対応するために必要です。
-</p>
-</li>
-
-<li>
-pg_md5 コマンドで起こりうるクラッシュを修正しました。(Muhammad Usama)
-</li>
-
-<li>
-スタートアップパケットに PostgreSQL ユーザ情報が含まれていなかった場合に発生する子プロセスのセグメンテーション違反を修正しました。(Yugo Nagata)
-<p>
-このバグは以下を実行することにより再現できます。
-</p>
-<pre>
-    $ psql -p 9999 -U ''
-</pre>
-<p>
-enable_pool_hba が有効の場合は子プロセスがセグメンテーション違反で異常終了し、無効の場合には以下のメッセージがログに出力されていました。
-</p>
-<pre>
-    ERROR: pool_discard_cp: cannot get connection pool for user (null) database (null)
-</pre>
-
-<p>
-また、両方の場合で psql はフロントエンドに何のメッセージ出力せずに終了していました。
-修正後は、スタートアップパケットに PostgreSQL ユーザが指定されていない場合には以下のメッセージがログとフロントエンドの両方に出力されます。
-これは PostgreSQLと同じ振る舞いです。
-</p>
-<pre>
-    FATAL: no PostgreSQL user name specified in startup packet
-</pre>
-</li>
-
-<li>
-マニュアルの ssl_sa_cert, ssl_ca_cert_dir オプションの説明を SSL セクションに移動しました。(Yugo Nagata)
-</li>
-
-<li>
-ssl_sa_cert, ssl_ca_cert_dir オプションの説明を日本語マニュアルに追加しました。(Yugo Nagata)
-</li>
-
-<li>
-pcp_recovery_node コマンドで、バックエンドノード番号をチェックするように修正しました。(Yugo Nagata)
-<p>
-不正な値が使用された場合、リカバリで実行されるスクリプトの引数に空の値が渡されており、誤動作の原因となっていました。
-特にベースバックアップを行うスクリプトで、rsync が関係のないファイルを削除してしまうことがありました。
-</p>
-</li>
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.1.7"></a>3.1.7 (hatsuiboshi) 2013/04/26</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<p>
-このバージョンは 3.1.6 に対するバグ修正リリースです。
-</p>
-<h3>バグ修正</h3>
-<ul>
-
-<li>
-設定パラメータの一覧を表示する "SHOW pool_status" で pool_passwdが表示されていないのを修正しました。(Yugo Nagata)
-</li>
-
-<li>
-拡張プロトコルの処理における timestamp の書き換えに関する長い間見過ごされていてたバグを修正しました。(Tatsuo Ishii)
-<p>
-  Parse() 関数は、parse メッセージの書き換えの際に palloc() を使ってメモリを確保していました。
-  書き換えられたメッセージは pool_create_sent_message()
-  関数などが管理するデータ領域に格納されますが、これが問題となっていました。
-  この関数ではデータが session context memory 中に存在することを想定しているのに対し、
-  palloc() では query context においてメモリの割り当てを行っており、この領域は
-  query context 終了時に解放されます。しかし、他の関数もこのメモリ領域を解放しようとするため、
-  セグメンテーション違反や二重解放を含む様々な問題の原因となっていました。
-  この問題は、書き換えたメッセージを格納するメモリを session context を用いて確保するこで修正されました。
-  これは pgpool-II 3.0 以来ずっと存在していたバグです。
-</p>
-<p>
-  この問題は、Naoya Anzai さんによって解析され、パッチが提供されました。
-</p>
-<blockquote>
-  [pgpoolgenera-jp: 1146]<br />
-  拡張問い合わせプロトコルでセグメンテーションフォルト<br />
-  <a href="http://www.pgpool.net/pipermail/pgpool-general-jp/2013-March/001145.html">
-  http://www.pgpool.net/pipermail/pgpool-general-jp/2013-March/001145.html
-  </a>
-</blockquote>
-</li>
-
-<li>
-md5認証で長いユーザ名を処理する際のバグを修正しました。(Tatsuo Ishii)
-<p>
-  ユーザ名が 32 バイトより長い場合、md5 認証が動作していませんでした。
-  この問題は [pgpool-general: 1526] で Thomas Martin さんにより報告されました。
-</p>
-<blockquote>
-  [pgpool-general: 1526]<br />
-  [pgPool-II 3.2.3] MD5 authentication and username longer than 32 characters.<br />
-  <a href="http://www.pgpool.net/pipermail/pgpool-general/2013-March/001551.html">
-  http://www.pgpool.net/pipermail/pgpool-general/2013-March/001551.html
-  </a>
-</blockquote>
-</li>
-
-<li>レプリケーション遅延の計算はスタンバイサーバがプライマリサーバより遅れている場合にのみ行うよう修正しました。(Yugo Nagata)
-<p>
-  タイミングによってスタンバイよりプライマリの方がレプリケーションが遅延
-  しているように見える場合があり、その場合には負値の遅延が計算されていました。
-  この値が符号無し変数に代入されると、実際には遅延が生じていないにも関わらず、
-  ログに遅延が負値で出力され、されに悪いことには、ロードバランス機能により
-  SELECT クエリがプライマリに振り分けられ、その結果プライマリの負荷が高まる
-  ことがありました。
-</p>
-<p>
-  この問題は Saitoh Hidenori さんによって報告、解析されました。
-</p>
-<blockquote>
-  [pgpool-genera-jp: 1145]<br />
-  レプリケーション遅延確認の不具合について<br />
-  <a href="http://www.pgpool.net/pipermail/pgpool-general-jp/2013-March/001144.html">
-  http://www.pgpool.net/pipermail/pgpool-general-jp/2013-March/001144.html
-  </a>
-</blockquote>
-</li>
-
-<li>pgpool-recovery が PostgreSQL 9.3 に対応しました。 (Tatsuo Ishii)
-<p>
-  パッチは Asif Rehman さんにより提供され、これに Tatsuo Ishii が若干の修正を
-  加えました。
-</p>
-<blockquote>
-  [pgpool-hackers: 180] <br />
-  compile error in ppool-recovery<br />
-  <a href="http://www.pgpool.net/pipermail/pgpool-hackers/2013-April/000179.html">
-  http://www.pgpool.net/pipermail/pgpool-hackers/2013-April/000179.html
-  </a>
-</blockquote>
-</li>
-
-<li>pool_has_pgpool_regclass が pgpool_regclass() の実行権限をチェックするよう修正しました。 (Tatsuo Ishii)
-<p>
-  pgpool_regclass が存在する場合でも、pgpool がこの関数を実行できない場合に、
-  バックエンドへの接続がハングしていました。この問題は、pgpool_regclass
-  から実行権限を剥奪し、ネイティブレプリケーションモードで INSERT を実行
-  することで再現可能です。
-</p>
-<p>
-  この問題は bugtrack #53 で報告されました。
-</p>
-<blockquote>
-  #53 pgpool_regclas hangs all connections<br />
-  Date:     2013-04-04 13:35 <br />
-  Reporter: tmandke<br />
-  <a href="http://www.pgpool.net/mantisbt/view.php?id=53">
-  http://www.pgpool.net/mantisbt/view.php?id=53
-  </a>
-</blockquote>
-</li>
-
-<li>detect_postmaster_down_error() のエラーメッセージを修正しました。(Tatsuo Ishii)
-<p>
-  例えば、"LOG: detect_stop_postmaster_error: detect_error error" を
-  "LOG: detect_postmaster_down_error: detect_error error" に修正するなどです。
-</p>
-</li>
-
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.1.6"></a>3.1.6 (hatsuiboshi) 2013/02/08</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<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>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>ヘルプメッセージに -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<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>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<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>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>ドキュメント中の、「パラメータ変更に再起動が必要かどうか」の情報を追記・修正しました。(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>マスタ・スレーブモードでの BEGIN TRANSACTION の扱いを修正しました。(Tatsuo Ishii)
-    <p>
-    これは <a href="http://www.pgpool.net/pipermail/pgpool-general/2012-July/000719.html">[pgpool-general: 714]</a>
-    で報告されました。
-    </p>
-    <p>
-    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/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>SET TRANSACTION ISOLATION LEVELSERIALIZABLE などのクエリはプライマリのみに送るよう
-    send_to_where() を修正しました。(Tatsuo Ishii)
-    <p>
-    マスタ・スレーブモードで、以前はこのクエリはプライマリだけではなくスタンバイにも送られていましたが、
-    もちろんこれはエラーとなります。同じようなクエリとして以下のものがあります。
-    </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>
-
-    <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>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.1.3"></a>3.1.3 (hatsuiboshi) 2012/04/23</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<p>
-このバージョンは3.1.2に対するバグ修正リリースです。
-</p>
-<h3>バグ修正</h3>
-<ul>
-<li>m4 ファイルを追加しました。これにより古い OS で起こるコンパイルの問題を回避できます。(Tatsuo Ishii)</li>
-<li>フェイルオーバを適切に処理するよう detect_postmaster_down_error() 関数を修正しました。(Tatsuo Ishii)<br>
-<p>
-以前はバックエンドソケットの読み込みに失敗することがありました。
-</p>
-</li>
-<li>シグナル割り込みによって、セマフォが解放されないままプロセスが終了することがあるバグを
-修正しました。(Tatsuo Ishii)
-</li>
-<li>reset_query 時のメモリリークを修正しました。 (Tatsuo Ishii)</li>
-<li>pool_ssl_read() 関数が大きいサイズのデータを読み込めるよう修正しました。(Tatsuo Ishii)
-<p>
-以下の報告によるものです。<br>
-<a href="http://www.pgpool.net/pipermail/pgpool-general/2012-March/000299.html%22">
-http://www.pgpool.net/pipermail/pgpool-general/2012-March/000299.html</a>
-</p>
-</li>
-<li>syslog を有効にしたときに起こるデッドロックを修正しました。(Tatsuo Ishii)
-<p>
-このバグは以下で報告され、パッチは Gilles Darold さんにより提供頂きました。<br>
-<a href="http://www.pgpool.net/mantisbt/view.php?id=9">
-http://www.pgpool.net/mantisbt/view.php?id=9</a>
-</p>
-</li>
-<li>マスター・スレーブモードで複数の文を扱えるように修正しました。(Tatsuo Ishii)
-<p>
-以前は BEGIN, END 等を用いた複数文からなるクエリはエラーとなっていました。
-</p>
-</li>
-<li>マスタサーバがダウンした際に、子プロセスが NULL ポインタを参照しようとするバグを修正しました。(Tatsuo Ishii)
-<p>
-このバグは以下で報告されました。<br>
-<a href="http://www.pgpool.net/mantisbt/view.php?id=51">
-http://www.pgpool.net/mantisbt/view.php?id=51</a>
-</p>
-</li>
-<li>マスターノードIDの初期値が正しく設定されるように pool_start_query() 関数を修正しました。(Tatsuo Ishii)
-<p>
-このバグのためにセグメントフォルトが発生することがありました。
-</p>
-</li>
-<li>pool_setall_node_to_be_sent() 関数において BACKEND_INFO マクロの代わりに
-private_backend_status 変数を利用するよう修正しました。(Tatsuo Ishii)
-<p>
-これは状況により BACKEND_INFO が利用できなくなる場合があったためです。(Tatsuo Ishii)
-</p>
-</li>
-<li>子プロセスがレプリケーション遅延チェック要求を送り続けることがあるバグを修正しました。(Tatsuo Ishii)
-<p>
-以前はフェイルオーバ時にレプリケーション遅延をチェックする worker プロセスを限定した条件でしか
-起動していませんでしたが、これは間違いで、常に再起動する必要があります。
-</p>
-</li>
-<li>デバッグメッセージにヌル文字が含まれないように修正しました。
-ヌル文字が含まれるログは、バイナリファイルであると認識されることがあります。(Toshihiro Kitagawa)</li>
-<li>以下の場合に parser memory をリストアするよう SimpleQuery() 関数を修正しました。
-<ol>
-<li>組み込み show コマンド使用時</li>
-<li>パラレルクエリモード</li>
-<li>クエリキャッシュ使用時</li>
-</ol>
-さもないと、後で不正な palloc を発生する障害が起きるからです。(Tatsuo Ishii)
-</li>
-<li>PREPARE 文でエラーが起きた際に発生するハングアップを修正しました。(Toshihiro Kitagagwa)
-<p>
-Tominari Katsumata さんの報告に基づきます。
-</p>
-</li>
-<li>doc/pgpool-fr.html を Makefile.am に追加しました。
-これはフランス語のドキュメントを追加した際に、追加し忘れたものです。(Tatsuo Ishii)</li>
-<li>デーモンモードで syslog を有効にしている際に md5 認証で発生するハングアップを修正しました。(Yugo Nagata)</li>
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.1.2"></a>3.1.2 (hatsuiboshi) 2012/01/31</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<p>
-このバージョンは3.1.1に対するバグ修正リリースです。
-</p>
-<h3>バグ修正</h3>
-<ul>
-<li>トランザクション隔離レベルの処理で、READ UNCOMMITTED と REPEATABLE READ が解釈できていませんでしたが、
-これを修正しました。(Tatsuo Ishii)</li>
-<li>以下のスレッドで報告されている無限ループを修正しました。(Tatsuo Ishii)
-<p>
-<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 へのパケットが送られてしまう、
-という可能性が考慮されていませんでした。
-</p>
-    <p>
-    この事象は例えば、postgresql.conf を再読み込みしたときに発生することがありました。
-    </p>
-    <p>
-    この修正では、スタンバイからしか受け取れなかったバッファは無視するようにしました。
-    </p>
-</li>
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.1.1"></a>3.1.1 (hatsuiboshi) 2011/12/06</h2>
-<!-- -------------------------------------------------------------------------------- -->
-
-<h3>概要</h3>
-<p>
-このバージョンは3.1に対するバグ修正リリースです。
-</p>
-
-<h3>バグ修正</h3>
-<ul>
-<li><a href="#BLACK_FUNCTION_LIST">black_functon_list</a> と
-    <a href="#WHITE_FUNCTION_LIST">white_function_list</a> の読み込み処理で
-    メモリ破壊を起こすバグを修正しました(Tatsuo Ishii)。
-</li>
-<li>check_replication_time_lag の誤ったエラーメッセージを修正しました(Tatsuo Ishii)。
-    <p>
-    ストリーミングレプリケーションの遅れのチェックのために PostgreSQL に接続できなかった時に
-    誤ったメッセージを出していました。
-    3.1以降では <a href="#HEALTH_CHECK_USER">health_check_user</a> はこの目的のために使われていないので、
-    これは誤りです。
-    </p>
-</li>
-<li>メモリーリークを修正しました(Toshihiro Kitagawa)。
-    <p>これは、基本的に3.0.5(commit 19a4ea9215da0b61728741fc0da2271958b09238)で行われた修正と同じものです。</p>
-</li>
-<li>strncpy()を使った修正を多数行いました(Tatsuo Ishii)。
-    <p>strncpy()が使われている箇所が複数あり、そこではコピー長とバッファサイズが同じであるケースが
-       考慮されていません。
-       このため、コピー後の文字列がNULL終端されていない可能性があり、多くの問題を後で引き起こすことになります。
-       この問題を修正するために、ほとんどの箇所をstrlcpy()で置き換えました。</p>
-</li>
-<li>可能な場合にはキャッシュされたバックエンドの状態情報を更新するようにしました(Tatsuo Ishii)。
-    <p>
-    これにより、Jeff Frostから以下のメールで報告された問題が解決されました。
-    すなわち、 follow_master_command が正しくバックエンドの状態を読み取れない問題です。
-    </p>
-<pre>Subject: [Pgpool-general] diagnosing BackendError from pcp_recovery_node
-To: pgpool-general@pgfoundry.org
-Date: Wed, 05 Oct 2011 15:15:07 -0700
-</pre>
-</li>
-<li>Windows環境でのみ必要なPGDLLIMPORTIを削除しました。
-    <p>
-    これはgccを使わない環境で問題を引き起こします。
-    パッチはIbrar Ahmedさんが提供しました。
-    </p>
-</li>
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.1"></a>3.1 (hatsuiboshi) 2011/09/08</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<p>
-このバージョンは3.1系列の最初の版で、3.0系からの「メジャーバージョンアップ」にあたります。
-</p>
-
-<h3>互換性のない変更</h3>
-<p>
-</p><ul>
- <li><a href="#INSERT_LOCK">insert_lock</a> のロック方法を変更しました。(Toshihiro Kitagawa)
-     <p>
-     以前のinsert_lockは、シーケンステーブルに対して行ロックを行いましたが、
-     現在は、pgpool_catalog.insert_lockテーブルに対して行ロックを行います。
-     その理由は、シーケンステーブルに対するロックが内部エラーを引き起こすため、
-     PostgreSQLのコア開発者がそれを許可しないことを決定したためです。
-     </p>
-     <p>
-     したがって、pgpool-II経由でアクセスするすべてのデータベースにinsert_lockテーブルを
-     あらかじめ作成しておく必要があります。
-     もし、insert_lockテーブルが存在しない場合は、挿入対象のテーブルに対してロックを行います。
-     これは、pgpool-II 2.2と2.3シリーズのinsert_lockと同じ動作です。
-     </p>
-     <p>
-     また、過去のバージョンと互換性のあるinsert_lockを使用したい場合は、
-     <a href="#install">configureオプション</a>(--enable-sequence-lock,--enable-table-lock)で
-     設定できます。
-     </p>
- </li><li><a href="#BACKEND_SOCKET_DIR">backend_socket_dir</a> パラメータを廃止しました。
-     <p>
-     その代わりに、<a href="#BACKEND_HOSTNAME">backend_hostname</a> が'/'で始まるならば、
-     それをUNIXドメインへのパスとみなします。
-     backend_hostnameが空ならば、デフォルトのUNIXドメインパス(/tmp)が使われます。
-     これは、libpqインタフェースの規約に従います。
-     </p>
-     <p>
-     パッチはJehan-Guillaume (ioguix) de Rorthaisさんから頂きました。
-     </p>
- </li><li>フェイルオーバー時にpgpool_walrecrunning()を使用せず、
-     プライマリノードへの昇格が完了するまで待つようになりました。(Toshihiro Kitagawa)
-     <p>
-     関数を使用しない理由はプライマリノードを確実に見つけることができないためです。
-     しかし、この修正にはプライマリノードが現れないときに <a href="#RECOVERY_TIMEOUT">recovery_timeout</a> の間
-     pgpool-IIが待ってしまう問題がまだ残っています。
-     </p>
- </li><li>PostgreSQL DBノード情報を出力する <a href="#pool_nodes">pool_nodes</a> に
-    「ノードID」を追加しました。(Jean-Paul Argudo)
- </li><li>シーケンス関数(nextval, setval)の扱いを
-    <a href="BLACK_FUNCTION_LIST">black/white_function_list</a>の設定に完全に従うように変更しました。
-    以前、それらは常に書き込み関数として扱われていました。(Toshihiro Kitagawa)
-</li></ul>
-<p></p>
-
-<h3>新機能</h3>
-<p>
-</p><ul>
- <li><a href="#LOG_DESTINATION">syslog</a> に対応しました。
-    パッチはGilles Daroldさんから頂き、Guillaume Lelargeさんがレビューと編集をしました。
- </li><li>PostgreSQL 9.0で導入されたapplication_nameに対応しました。(Tatsuo Ishii)
-    <p>
-    コネクションが再利用されたときに、スタートアップパケットのapplication_nameをバックエンドへ送信し、
-    ラメータステータスをフロントエンドに返します。
-    </p>
- </li><li>pgpool-II内部で使用するシステムカタログキャッシュの有効時間を、
-    秒単位で指定できる設定項目relcache_expireが追加されました。(Tatsuo Ishii)
-    <p>
-    これにより、ALTER TABLEによってテーブル定義が変更された際に、
-    もはや有効でない結果を利用してしまうリスクが軽減されます。
-    </p>
- </li><li><a href="#FOLLOW_MASTER_COMMAND">follow_master_command</a> パラメータを追加しました。
-    <p>
-    このパラメータには、マスタースレーブモードのストリーミングレプリケーション構成において
-    マスタノードがフェイルオーバーした後に実行されるコマンドを指定します。
-    </p>
-    <p>
-    パッチはGilles Daroldさんから頂きました。
-    </p>
- </li><li><a href="#pcp_promote_node">pcp_promote_node</a> コマンドを追加しました。
-    <p>
-    このコマンドはpgpool-IIに対して新しいマスタノードへの昇格を行います。
-    これは、マスタースレーブモードのストリーミングレプリケーション構成のみで使用できます。
-    </p>
-    <p>
-    パッチはGilles Daroldさんから頂きました。
-    </p>
- </li><li><a href="#pcp_pool_status">pcp_pool_status</a> コマンドを追加しました。
-    また、対応するC APIも追加されています。
-    <p>
-    パッチはJehan-Guillaume (ioguix) de Rorthaisさんから頂きました。
-    </p>
- </li><li>バックエンドごとのパラメータ"<a href="#BACKEND_FLAG">backend_flag</a>"を追加しました。(Tatsuo Ishii)
-    <p>
-    これは、バックエンドごとの動作を制御します。
-    今は"ALLOW_TO_FAILOVER"または"DISALLOW_TO_FAILOVER"が指定できます。
-    </p>
- </li><li><a href="#HEALTH_CHECK_PASSWORD">health_check_password</a> パラメータを追加しました(Nicolas Thauvin)
- </li><li><a href="#SR_CHECK_PERIOD">sr_check_period</a>、<a href="#SR_CHECK_USER">sr_check_user</a>、
-     <a href="#SR_CHECK_PASSWORD">sr_check_password</a> パラメータを追加しました。(Tatsuo Ishii)
-     <p>これらは、ストリーミングレプリケーションの遅延チェックとプライマリノードの決定に使用されます。</p>
- </li><li>pg_md5コマンドに--username(または-u)オプションを追加しました。(Nicolas Thauvin)
-    <p>
-    これは、UNIXアカウントを持たないユーザの管理を可能にします。
-    日本語ドキュメントはTatsuo Ishiiさんが修正しました。
-    </p>
- </li><li>pgpool_adm関数をpgpool_adm/に追加しました。(Jehan-Guillaume (ioguix) de Rorthais)
-    <p>これらは、pcpコマンドのように動作するC言語で書かれたユーザ定義関数です。</p>
- </li><li>簡体字中国語版のドキュメントを追加しました(Huang Jian, Sun Peng)
- </li><li>関数をアンインストールするためのSQLファイルをsql/に追加しました(Nicolas Thauvin)
- </li><li>マスタースレーブモードにおいて、unloggedテーブルに対するSELECTは、
-    常にマスター(primary)で実行されるようになりました(Toshihiro Kitagawa)
-</li></ul>
-<p></p>
-
-<h3>バグ修正</h3>
-<p>
-</p><ul>
- <li>スタンバイノードでJDBCドライバのカーソルが使用できないバグを修正しました。(Toshihiro Kitagawa)
-     <p>
-     この修正によって、マスタースレーブモードではトランザクションコマンドが
-     すべてのノードに送られるようになります。
-     </p>
- </li><li>空のクエリの処理に関するバグを修正しました。(Toshihiro Kitagawa)
-    <p>
-    空のクエリはSELECTクエリと同じ扱いになります。
-    この修正は、空のクエリのあとのロードバランスを可能にします
-    </p>
- </li><li>カラム定義が"DEFAULT nextval(('"x_seq"'::text)::regclass)"のようになっていても
-    <a href="#INSERT_LOCK">insert_lock</a> が正しく動作するように修正しました(Toshihiro Kitagawa)
- </li><li>フェイルオーバー中はエラーメッセージを出力するように<a href="#pcp_attach_node">pcp_attach_node</a>
-    コマンドを修正しました(Toshihiro Kitagawa)
- </li><li>拡張問い合わせプロトコルでpgpool-IIがクエリを解析できないときに出力されるログメッセージが
-    クエリを表示するよう修正しました(Toshihiro Kitagawa)
- </li><li>pgpool-IIマニュアルの <a href="#BACKEND_WEIGHT">backend_weight</a> に関する説明を修正しました。
-    それは、pgpool.confの再読み込みで変更できます(Tatsuo Ishii)
- </li><li>英語のチュートリアルドキュメント内の表現の改善と修正を行いました。
-    修正の提案はHuang Jianさんによるものです(Tatsuo Ishii)
- </li><li>rawモードでノードを復帰させたときにノードの状態が更新されないバグを修正しました(Guillaume Lelarge)
- </li><li>ストリーミングレプリケーションモードにおけるレプリケーション遅延の計算が間違っていたのを修正しました(Tatsuo Ishii)
- </li><li>フェイルオーバーのログメッセージにおける誤った関数名
-    "notice_backend_error"を、正しいもの"degenerate_backend_set"に置き換えました(Tatsuo Ishii)
- </li><li>pgpool.conf解析後の不要なログ出力を削除しました(Tatsuo Ishii)
- </li><li>バックエンドを新規追加した後に起こり得るpgpool/worker子プロセスのクラッシュを修正しました。
-    修正はGurjeet Singhさんの提案によるものです(Tatsuo Ishii)
- </li><li>FOR SHARE/UPDATE句のあるサブクエリを含むSELECTがスレーブ(standby)に送られるバグを修正しました(Tatsuo Ishii)
- </li><li>PREPARE文でデフォルト値のタイムスタンプ書き換えに失敗するバグを修正しました。
-    これは以前は動作していましたが、3.0で動作しなくなっていました(Toshihiro Kitagawa)
- </li><li>getopt_long()がない環境でpcpコマンドのコンパイルが失敗するのを修正しました(Tatsuo Ishii)
- </li><li>rawモード、<a href="#ENABLE_POOL_HBA">enable_pool_hba</a>が無効、バックエンドが2台以上の場合に
-     pgpool子プロセスがクラッシュするのを修正しました(Toshihiro Kitagawa)
- </li><li>メモリリークをいくつか修正しました(Toshihiro Kitagawa)
-</li></ul>
-<p></p>
-
-<h3>改良</h3>
-<p>
-</p><ul>
- <li>ストリーミングレプリケーション構成でのオンラインリカバリにおいて、
-    リカバリ終了時に子プロセスを再起動しないようにしました。
-    そのため、既存のセッションはオンラインリカバリ中も継続することができます(Tatsuo Ishii)
-</li><li>ストリーミングレプリケーションモードにおいて、<a href="#pcp_attache_node">pcp_attache_node</a> が
-    既存のセッションを切断しなくなりました。
-    ほかのモードでは依然としてセッションが切断されます(Tatsuo Ishii)。
- </li><li>PostgreSQL 9.0のパーサを移植しました。
-    これによりPostgreSQL 9.0で新しく導入された暗黙のインデックス名を使用した
-    CREATE INDEXが実行できるようになりました。パッチは石田さんから頂きました。
- </li><li><a href="#BLACK_FUNCTION_LIST">black_function_list</a> と
-    <a href="#WHITE_FUNCTION_LIST">white_function_list</a>パラメータに正規表現が使えるようになりました。
-    パッチはGilles Daroldさんから頂き、Guillaume Lelargeさんがレビューしました。
- </li><li>読みやすいようにpgpool.confのサンプルファイルを再構成しました(Gleu)
- </li><li>pgpool-IIマニュアルのすべてのパラメータに‹a name="..."›タグを
-     追加しました(Haruka Takatsuka)
- </li><li>pgpool-IIマニュアルのストリーミングレプリケーションにおけるオンラインリカバリの説明を改善しました(Tatsuo Ishii)
- </li><li>ストリーミングレプリケーションモードにおけるレプリケーション遅延をチェックするための
-     関数を変更しました。(Tatsuo Ishii)
-    <p>
-    現在、pgpoolはpg_last_xlog_receive_location()の代わりにpg_last_xlog_replay_location()を使用します。
-    修正はAnton Yuzhaninovさんの提案によるものです
-    </p>
- </li><li>カラムのデフォルト値に任意の式を指定してもタイムスタンプ書き換えが動作するようにしました。(Tatsuo Ishii)
-    <p>
-    以前は、now()が含まれているものを検知すると、単純にそれをnow()で置き換えてました。
-    これは、デフォルト値の誤った書き換えを引き起こします。
-    例えば、timezone('utc'::text, now())です。
-    </p>
-    <p>
-    しかし、これは簡易プロトコルのみへの適用であることに注意してください。
-    拡張プロトコル(例えばJava, PHP PDO)または、SQLの"PREPARE"にはまだ適用されていません
-    </p>
- </li><li>レプリケーション遅延のチェックに失敗したときに出力されるエラーメッセージを改良しました(Nicolas Thauvin)
- </li><li>エラーメッセージ"do_md5: read_password_packet failed"をデバッグレベルにしました(Toshihiro Kitagawa)
- </li><li>pgpool-regclass()をPostgreSQL 9.1でコンパイルできるようにしました(Tatsuo Ishii)
- </li><li>英語版と日本語版のpgpool-IIマニュアルを更新、同期しました(Tatsuo Ishii)
-</li></ul>
-
-<!-- ================================================================================ -->
-<!-- 3.0                                                                              -->
-<!-- ================================================================================ -->
-<hr><a name="release3.0.x"></a>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.0.19"></a>3.0.19 (umiyameboshi) 2015/07/24</h2>
-<!-- -------------------------------------------------------------------------------- -->
-
-<h3>概要</h3>
-<p>
-このバージョンは 3.0.18 に対するバグ修正リリースです。
-</p>
-
-<h3>バグ修正</h3>
-<ul>
-
-<li>
-    pgpool-recovery の "cannot find xlog functions" エラーを修正しました。(Muhammad Usama)
-    <p>
-    PostgreSQL 9.4 より、PostgreSQL の pg_xlogfile_name() 関数の引数型はtext からpg_lsn に変更されていますが、pgpool-recovery は依然として古いシグネチャで関数を配置しようとしていました。
-    </p>
-</li>
-
-<li>
-    拡張問い合わせクエリで、レプリケーションモード以外の場合には、insertlock をチェックするクエリを送信しないようになりました。(Tatsuo Ishii)
-</li>
-
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.0.18"></a>3.0.18 (umiyameboshi) 2015/04/08</h2>
-<!-- -------------------------------------------------------------------------------- -->
-
-<h3>概要</h3>
-<p>
-このバージョンは 3.0.17 に対するバグ修正リリースです。
-</p>
-
-<h3>バグ修正</h3>
-<ul>
-
-<li>
-    POOLCONFIG_MAXDESCLEN を 80 まで増やしました (Tatsuo Ishii)
-    <p>
-    これは show pool_status コマンドでパラメータの説明文の長さ制限に使われていますが、recovery_timetout ではこれが 64 文字であり、以前のマクロ定義では 1 文字分不足していました。
-    </p>
-</li>
-
-<li>
-    フロントエンド接続の証明書ファイルで SSL 証明書チェーンに対応しました。(Muhammad Usama)
-</li>
-
-<li>
-    pcp_detach_node が graceful にノードを切り離す際の問題を修正しました。(Muhammad Usama)
-    <p>
-    graceful なノード切り離しでは、そのノードの切り離し処理が許されているかの判断を、pcp_detach_node は新しい接続のブロックと既存の接続の切断よりも前に行う必要があります。
-    </p>
-</li>
-
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.0.17"></a>3.0.17 (umiyameboshi) 2015/02/05</h2>
-<!-- -------------------------------------------------------------------------------- -->
-
-<h3>概要</h3>
-<p>
-このバージョンは 3.0.16 に対するバグ修正リリースです。
-</p>
-
-<h3>バグ修正</h3>
-<ul>
-
-<li>
-    doc: スレーブノードの数は１である必要でないことを明記しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    未初期化の変数があったのを修正しました。(Tatsuo Ishii)
-    <p>
-    Coverity の報告 #1234603 によります。
-    </p>
-</li>
-
-<li>
-    doc: 前回のリリースで抜け落ちていたリリースノートを追記しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    trigger_failover_command() 関数のノード ID 範囲検査のバグを修正しました。(Tatsuo Ishii)
-    <p>
-    ノード ID は定数 NUM_BACKENDS 未満である必要があります。実際にはNUM_BACKENDS 以上の値はこの関数に渡されていなかったので、おそらく害はありませんでした。
-    </p>
-</li>
-
-<li>
-    設定ファイルのリロードにより debug モードを無効にできるよう修正しました。(Yugo Nagata)
-    <blockquote>
-    bug #114 の報告によります。<br />
-    <a href="http://www.pgpool.net/mantisbt/view.php?id=114">
-    http://www.pgpool.net/mantisbt/view.php?id=114
-    </a>
-    </blockquote>
-</li>
-
-
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.0.16"></a>3.0.16 (umiyameboshi) 2014/09/05</h2>
-<!-- -------------------------------------------------------------------------------- -->
-
-<h3>概要</h3>
-<p>
-このバージョンは 3.0.15 に対するバグ修正リリースです。
-</p>
-
-<h3>バグ修正</h3>
-<ul>
-
-<li>
-    pgpool.spec のタイポを修正しました。(Yugo Nagata)
-</li>
-
-<li>
-    プライマリバックエンドが存在しない場合に、ワーカー子プロセスが終了と再起動を繰り返すバグを修正しました。(Tatsuo Ishii)
-    <p>
-    問題の同定と修正は Junegunn Choi さんの貢献によります。
-    </p>
-    <p>
-    詳しくは、[pgpool-hackers: 471] を参照してください。
-    </p>
-</li>
-
-<li>
-    スマートシャットダウンの実行時には受信用ソケットを閉じるように修正しました。(Tatsuo Ishii)
-    <p>
-    スマートシャットダウンが実行された場合でも、pgpool の子プロセスは受信用のポートを開いており、最終的に失敗するにもかからわずクライアントは接続要求を送信可能です。これは時間の無駄であるだけではなく、pgpool のフロントにいるロードバランサによる pgpool の停止の検出を妨げます。
-    </p>
-    <p>
-    この問題は [pgpool-hackers 474] にて Junegunn Choi によって解析され、パッチが提供されました。これを Tatsuo Ishii が改良し、inet ドメインだけではなく UNIX ドメインのソケットにも対応させました。
-    </p>
-</li>
-
-<li>
-    doc: PostgreSQL の statement_timeout によって、リカバリコマンドが終了させられる可能性を追記しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    dic: 現在は当てはまらない古い制限事項を削除しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    text_to_lsn() 関数の返却値型を修正しました。(Yugo Nagata)
-    <p>
-    コンパイル時の警告の原因となっていました。
-    </p>
-</li>
-
-<li>
-    デーモン化した際にファイル識別子が閉じられていなかったのを修正しました。(Tatsuo Ishii)
-    <p>
-    Coverity の報告 #1111471 によります。
-    </p>
-</li>
-
-<li>
-    メモリリークを修正しました。 (Tatsuo Ishii)
-    <p>
-    Coverity の報告 #1111442 によります。
-    </p>
-</li>
-
-<li>
-    長らく放置されていた pgool.init の stop/restart のバグを修正しました。(Yugo Nagata)
-    <p>
-    以前は pgpool の停止に pgpool.init は killproc を用いていましたが、これにはいくつか問題がありました。これを、"pgpool -m fast stop" を用いるように修正しました。
-    </p>
-    <p>
-    Ryan DeShone により提供されたパッチを Yugo Nagata が修正しました。
-    </p>
-    <p>
-    詳しくは、[pgpool-hackers: 239][pgpool-hackers: 512] を参照してください。
-    </p>
-</li>
-
-<li>
-    オンラインリカバリの実行時は PostgreSQL の statement_timeout を無効にするようになりました。(Tatsuo Ishii)
-    <p>
-    オンラインリカバリは異常に長い時間を要する可能性がある一方、ユーザは statement_timeout を有効にしている可能性があります。これによりオンラインリカバリがキャンセルされるのを防ぐため、リカバリの最中は statement_timeout を無効にするようになりました。
-    </p>
-    <p>
-    詳しくは [pgpool-general: 2919] を参照してください。
-    </p>
-</li>
-
-<li>
-    不適切にセマフォを削除しないよう不必要な pool_shmem_exit() 呼び出しを取り除きました。(Tatsuo Ishii)
-    <p>
-    exit_handler はプロセスが親プロセスがどうかをチェックしていますが、子プロセスであった場合にも pool_shmem_exit() が呼ばれることがあり、これにより不適切にセマフォが削除されていました。この関数は親プロセス以外に呼ばれてはなりません。
-    </p>
-    <blockquote>
-    bug #102 によります。<br />
-    <a href="http://www.pgpool.net/mantisbt/view.php?id=102">
-    http://www.pgpool.net/mantisbt/view.php?id=102
-    </a>
-    </blockquote>
-</li>
-
-<li>
-    リセット用クエリにより発生するハングを修正しました。(Tatsuo Ishii)
-    <p>
-    DISCARD ALL などのリセットクエリが完了せず、pgpool の子プロセスがバックエンドからの反応を待ったまま固まってしまい、新しいクライアントからの接続が受けられなくなる問題が報告されました。
-    </p>
-    <p>
-    原因はまだ特定されていませんが、クライアントの接続がクエリ処理の最中に突然切断された場合、バックエンドがクエリを処理できない状態となり、リセットクエリを受け付けられなくのかもしれません。
-    </p>
-    <p>
-    これに対処するため、フロントエンドから接続が予期せず切断された場合は、クエリ処理ループを即座に終了し PostgreSQL への接続を切断し、新しい接続要求を待つように修正しました。
-    </p>
-    <p>
-    また client_idle_limit が設定されており、リミットに達した場合にもpgpool はバックエンドへの接続を切断するよう修正されました。
-    </p>
-    <blockquote>
-    bug #107 の報告によります。<br />
-    <a href="http://www.pgpool.net/mantisbt/view.php?id=107">
-    http://www.pgpool.net/mantisbt/view.php?id=107
-    </a>
-    </blockquote>
-</li>
-
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.0.15"></a>3.0.15 (umiyameboshi) 2014/03/24</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<p>
-このバージョンは 3.0.14 に対するバグ修正リリースです。
-</p>
-
-<h3>バグ修正</h3>
-<ul>
-
-<li>
-    doc: num_init_children の項に「listen キュー」の説明とその「バックログ」を増やす方法について追記しました。
-    (Tatsuo Ishii)
-</li>
-
-<li>
-    UNLOGGED テーブルを検出する処理のパフォーマンスが悪かったのを修正しました。
-    (Tatsuo Ishii)
-    <p>
-    この問題は <a href="http://www.sraoss.jp/pipermail/pgpool-hackers/2014-January/000435.html">[pgpool-hackers: 435]</a>
-    <a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-December/002354.html">[pgpool-general:2325]</a> で指摘されました。
-    </p>
-</li>
-
-<li>
-    プライマリノードの検出ロジックを修正しました。(Tatsuo Ishii)
-    <p>
-    プライマリノードが検出されないことがありました。例えば、node 0 がプライマリ、node 1
-    がスタンバイのときに、node 0 が落ちたとします。ヘルスチェックがそれを検出しますが、
-    内部のステータスがまだ更新されていない場合 node 0 には問題がないよう見えるため node 0
-    への接続が試みられます。実際にはこの接続は失敗するため、node 1
-    が新プライマリであることを検出する前に処理が終了していました。
-    </p>
-    <p>
-    この問題は <a href="http://www.sraoss.jp/pipermail/pgpool-general/2014-January/002442.html">[pgpool-general: 2409]</a> にて報告されました。
-    </p>
-</li>
-
-<li>
-    raw モードで自動コミットが off で JDBC を使用したときに、DML
-    が失敗するバグを修正しました。(Tatsuo Ishii)
-    <p>
-    この問題は <a href="http://www.pgpool.net/mantisbt/view.php?id=92">bug #92</a> で報告されました。
-    </p>
-</li>
-
-<li>
-    ストリーミングレプリケーションモードで無関係なノードにはクエリを送信しないように修正しました。
-    (Tatsuo Ishii)
-    <p>
-    pgpool-II は BEGIN, END, SET などのクエリを全ての DB ノードに送っています。
-    しかし、ストリーミングレプリケーションではプライマリノードと高々１台のスタンバイノードにしか送る必要がありません。
-    （もしプライマリノードがロードバランスノードとして選択されている場合には１台だけで充分です。）
-    </p>
-    <p>
-    詳細は <a href="http://www.sraoss.jp/pipermail/pgpool-hackers/2014-February/000464.html">
-    [pgpool-hackers: 464]</a> を参照してください。
-    </p>
-</li>
-
-<li>
-    バッファオーバランとメモリリークの可能性を修正しました。(Tatsuo Ishii)
-    <p>
-    Coverity 1111465, 1111482 の報告によります。
-    </p>
-</li>
-
-<li>
-    NULL ポインタの解放を修正しました。(Tatsuo Ishii)
-    <p>
-    Coverity 1111384 の報告によります。
-    </p>
-</li>
-
-<li>
-    メモリリークを修正しました。(Tatsuo Ishii)
-    <p>
-    Coverity 1111446 の報告によります。
-    </p>
-</li>
-
-<li>
-    パラレルモードで system_db_hostname
-    が空欄の場合に発生するセグメンテーションフォルトを修正しました。
-    (Yugo Nagata)
-</li>
-
-<li>
-    -d オプションで起動した場合に pgpool.conf
-    の処理中のデバッグメッセージを出力するように修正しました
-    (Yugo Nagata)
-    <p>
-    以前は -d オプション使用時でも出力されていないデバッグメッセージがありました。
-    </p>
-</li>
-
-<li>
-    レプリケーションモードで JDBC 使用時に now()
-    を含む準備文で発生する例外を修正しました。(Yugo Nagata)
-    <p>
-    JDBC で準備文を PrepareThreshold 回以上実行した場合には、文に名前が付けられ Parse
-    の後に Describe メッセージが発行されます。このとき、pgpool は now()
-    をパラメータに書き換えるため、元のクエリには無かった新しいパラメータが追加されます。
-    この場合、フロントエンドに返されるParameterDscription メッセージ（Describe
-    の返答）は、元のクエリが持つパラメータと同じ数の OID を含むべきです。そうしないと、JDBC
-    はArrayIndexoutOfBoundsException 例外を発生させてしまいます。
-    </p>
-    <p>
-    このバグは <a href="http://www.sraoss.jp/pipermail/pgpool-general-jp/2013-September/001191.html">
-    [pgpool-general-jp: 1192]</a> で報告されました。
-    </p>
-</li>
-
-<li>
-    レプリケーションモードにて、デフォルト値が now()
-    のカラムを持つテーブルに対する準備文でエラーが発生するバグを修正しました。
-    (Yugo Nagata)
-    <p>
-    デフォルト値が now() を持つ名前付き準備文を parse する際に、pgpool-II
-    は時刻値をパラメータで置き換えます。そのため、その後の bind
-    メッセージも追加されたパラメータの形式コードを含んでいる必要があります。
-    しかし、元のクエリのパラーメータ形式数が１だった場合、この処理がなされていませんでした。これが
-    "incorrect binary data format in bind parameter 2" のようなエラーの原因となっていました。
-    </p>
-</li>
-
-<li>
-    doc: パラレルモードは PREPARE 文の実行に対応していないことを追記しました。(Yugo Nagata)
-    <p>
-    <a href="http://www.pgpool.net/mantisbt/view.php?id=93">bug #93</a> の指摘によります。
-    </p>
-</li>
-
-
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.0.14"></a>3.0.14 (umiyameboshi) 2013/12/06</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<p>
-このバージョンは 3.0.13 に対するバグ修正リリースです。
-</p>
-
-<h3>バグ修正</h3>
-<ul>
-
-<li>レプリケーションモード稼働時、一部のタイムゾーンでタイムスタンプの書き換えが誤っていました。(Tatsuo Ishii)
-<p>タイムスタンプの書き換え処理では、現在日時を取得するあめに "SELECT now()" を実行します。
-しかし一部のタイムゾーンにおいては、"02:30" のような場合に現在日時のためのバッファの大きさが
-十分ではありませんでした。"0900" のように 30 分刻みでのタイムゾーンでないときは、この問題は発生しません。
-そのため、これまでこの不具合が報告されたことはありませんでした。</p>
-<p>この不具合は <a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-September/002142.html" target="_blank">[pgpool-general: 2113]</a> で報告され、Sean Hogan さんによって修正が提供されました。</p>
-</li>
-
-<li>Makefile: Makefiles 内の pg_config を $(PG_CONFIG) に置き換えました。
-したがって、PostgreSQL のメジャーバージョンが異なる場合には、コンパイル中で上書きされるようになります。(Tatsuo Ishii)
-<p>パッチは Christoph Berg さんから提供されました。（<a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-September/002156.html" target="_blank">[pgpool-general: 2127]</a>）</p>
-</li>
-
-<li>configure: FreeBSD で問題があったため、-lcompat を削除しました。(Tatsuo Ishii)
-<p><a href="http://www.pgpool.net/mantisbt/view.php?id=15">bug#15</a> で報告されました。</p>
-</li>
-
-<li>pgpool.conf で <a href="#LOG_STANDBY_DELAY">log_standby_delay</a> を設定してないときに
-segfault していたのを修正しました。(Tatsuo Ishii)
-<p>これは、pool_config.l での log_standby_delay の初期化が誤っていたためです。
-<a href="http://www.pgpool.net/mantisbt/view.php?id=74" target="_blank">bug#74</a> として報告されました。</p>
-</li>
-
-<li>doc: パラレルモードの制限事項を追記しました。VALUES 句を使った複数行の INSERT はパラレルモードではサポートされていません。(Yugo Nagata)</li>
-
-<li>スタンバイノードがダウンしようとしているときに find_primary_node_repeatedly() が
-呼ばれないようにしました。(Tatsuo Ishii)
-<p>これによってフェイルオーバの所要時間が短くなります。
-<a href="http://www.pgpool.net/mantisbt/view.php?id=75" target="_blank">bug#75</a> として報告され、
-パッチを Tatsuo Ishii が編集しました。</p>
-</li>
-
-<li>read_password_packet() のエラーメッセージを修正しました。(Tatsuo Ishii)</li>
-
-<li>SSL 要求でのメモリリークを修正しました。(Tatsuo Ishii)
-<p>SSL での要求があったとき、pgpool 子プロセスは start up packet の読み込みをリトライしていました。
-しかし子プロセスは、以前の start up packet のメモリを解放していませんでした。</p>
-<p>これは Coverity "1111443 Resource" で発見されました。</p>
-</li>
-
-<li>do_query() がタイムスタンプの書き換えに失敗したとき、メモリリークしていました。(Tatsuo Ishii)
-<p>この修正のために、free_select_result() で NULL 引数を受け取れるようにしました。</p>
-<p>これは Coverity "1111454, 1111455 Resource leak" で発見されました。</p>
-</li>
-
-<li>"<code>DEALLOCATE portal|statement</code>" 実行時の対象ノードの選定ロジックを修正しました。(Tatsuo Ishii)
-<p>"<code>DEALLOCATE portal|statement</code>" 実行時、最後の prepared statement や portal が見つからない場合に、
-対象ノード選定マップがセットされていませんでした。
-おそらく、そうした場合はエラーなので、実際には問題ありません。</p>
-<p>これは Coverity "1111491 Structurally dead code" で発見されました。</p>
-</li>
-
-<li>MAX_NUM_BACKENDS の範囲チェックにおける不具合を修正しました。 (Tatsuo Ishii)
-<p>MAX_NUM_BACKENDS は DB ノードの最大数が限界値でした（現時点では 128）。
-実際には 128 の DB ノードで試す人がいなかったために、発見されなかった不具合のようです。</p>
-<p>これは Coverity "1111429, 1111430 and 1111431 Out-of-bounds write" で発見されました。</p>
-</li>
-
-<li>フロントエンド接続情報を、すでに無効なバックエンドについて set/unset しないようにしました。(Tatsuo Ishii)
-<p>この不具合は <a href="http://www.pgpool.net/mantisbt/view.php?id=82" target="_blank">bug#82</a> で報告されました。</p>
-</li>
-
-<li>pgpool_catalog への public access を許可していませんでした。
-<p>これは、pgpool_catalog がレプリケーションモードで作成されている場合に、
-ユーザテーブルにデータを INSERT すると発生します。</p>
-<p>この不具合は <a href="http://www.sraoss.jp/pipermail/pgpool-general-jp/2013-November/001228.html" target="_blank">[pgpool-general-jp: 1229]</a> で報告されました。</p>
-</li>
-
-<li>pool_do_auth() のエラーケースで変数を初期化していませんでした。 (Tatsuo Ishii)
-<p>有効なバックエンドがいないとき、pgpool は認証フェーズのフロントエンドにごみの pid を返していました。
-実際に、有効なバックエンドがいないために、フロントエンドは認証後に接続することができません。
-もちろんこれは問題あるものではありません。</p>
-<p>これは Coverity "1127331 Uninitialized scalar variable" で発見されました。</p>
-</li>
-
-<li>ノード ID を使ったエラーメッセージの発行時に、ノード ID の範囲チェックをするようにしました。
-(Tatsuo Ishii)
-<p>これは Coverity "1111433 "Out-of-bounds read" で発見されました。</p>
-</li>
-
-<li>parse_copy_data() でのバッファオーバーランとリソースリークを修正しました。 (Tatsuo Ishii)
-<p>これは Coverity "1111427 Out-of-bounds write"、"1111453 Resource leak" で発見されました。</p>
-</li>
-
-<li>CopyDataRaws() で segfault する可能性があったのを修正しました。(Tatsuo Ishii)
-<p>pool_get_id() がエラーを返した場合に VALID_BACKEND が配列外にアクセスしようとしていました。</p>
-<p>これは Coverity "1111433 Out-of-bounds read" で発見されました。</p>
-</li>
-
-<li>make_persistent_db_connection のリソースリークを修正しました。(Tatsuo Ishii)
-<p>この修正ののために、新しく free_persisten_db_connection_memory 関数を追加しました。</p>
-<p>これは Coverity #1111468 で発見されました。</p>
-</li>
-
-<li>Coverity で見つかったさまざまな不具合を修正しました。(Tatsuo Ishii)</li>
-
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.0.13"></a>3.0.13 (umiyameboshi) 2013/09/06</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<p>
-このバージョンは 3.0.12 に対するバグ修正リリースです。
-</p>
-
-<h3>バグ修正</h3>
-<ul>
-
-<li>
-    doc/basebackup.sh スクリプトの ssh コマンドの間違いを修正しました。(Tatsuo Ishii)
-</li>
-
-<li>
-    レプリケーションモードにおけるプリペアド文のパース処理を修正しました。(Tatsuo Ishii)
-    <p>
-    レプリケーションモードで SELECT 以外のクエリをパースする際には、
-    ノード間の一貫性保持のため自動的にトランザクションが開始されますが、
-    トランザクションを閉じる処理が行われていませんでした。
-    そのため、実際に誤っているクエリだけではなく、その次にパース処理されたクエリもアボートされていました。
-    </p>
-    <p>
-    このバグは [pgpool-general: 1877] で Sean Hogan さんにより報告されました。
-    </p>
-    <blockquote>
-    [pgpool-general: 1877] current transaction is aborted, commands ignored<br />
-    <a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-July/001905.html">
-    http://www.sraoss.jp/pipermail/pgpool-general/2013-July/001905.html
-    </a>
-    </blockquote>
-</li>
-
-<li>
-    日本語ドキュメントの typo を修正しました。 (Yugo Nagata)
-</li>
-
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.0.12"></a>3.0.12 (umiyameboshi) 2013/07/10</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<p>
-このバージョンは 3.0.11 に対するバグ修正リリースです。
-</p>
-<h3>バグ修正</h3>
-<ul>
-<li>
-man ページに -D オプションの記述を追加しました。（Tatsuo Ishii)
-</li>
-
-<li>
-オンラインリカバリ時のフェイルバックの完了待機でタイムアウト処理をするようにしました。(Tatsuo Ishii)
-<p>
-これによりリカバリが永遠に終わらず pgpool-II が終了できなくなる状況を回避します。
-この現象は特に follow_master_command の実行中に起こり得ました。
-</p>
-</li>
-
-<li>
-PostgreSQL がエラーを返したときに do_query() がハングしないよう修正しました。
-(Tatsuo Ishii)
-<p>
-典型的な症状が「pg_stat_activety によると SELECT が実行されたままのように見える」というものです。
-これを解決するため、pgpool-II は当該プロセスを終了させ、既存のコネクションを捨てるように修正しました。
-</p>
-</li>
-
-<li>
-拡張プロトコルの際に do_query で発生しうるハングアップを修正しました。
-(Tatsuo Ishii)
-<p>
-これは insert_lock が有効で、pgpool_catalog.insert_lock が存在することに起こり得ます。
-詳しくは [pgpool-general: 1684] を参照してください。
-</p>
-<blockquote>
-  [pgpool-general: 1684] insert_lock hangs <br />
-  <a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-May/001711.html">
-  http://www.sraoss.jp/pipermail/pgpool-general/2013-May/001711.html
-  </a>
-</blockquote>
-</li>
-
-<li>
-COMMIT 時エラーに不要なバックエンド切り離しを行わないようにしました。
-(Tatsuo Ishii)
-<p>
-マスタースレーブモードで、COMMIT 時にマスターノードでエラーが発生していたとしても、他のスレーブノードが正常な場合にはバックエンドを切り離す必要はありません。
-これは、遅延トリガーのために "kind mismatch error" が発生しうるからです。
-</p>
-</li>
-
-<li>
-pgpool_regclass を pg_catalog スキーマに登録するよう修正しました。
-(Tatsuo Ishii)
-<p>
-これは postgres_fdw のような、スキーマ検索パスが pg_catalog に限定されているクライアントに対応するために必要です。
-</p>
-</li>
-
-<li>
-pg_md5 コマンドで起こりうるクラッシュを修正しました。(Muhammad Usama)
-</li>
-
-<li>
-スタートアップパケットに PostgreSQL ユーザ情報が含まれていなかった場合に発生する子プロセスのセグメンテーション違反を修正しました。(Yugo Nagata)
-<p>
-このバグは以下を実行することにより再現できます。
-</p>
-<pre>
-    $ psql -p 9999 -U ''
-</pre>
-<p>
-enable_pool_hba が有効の場合は子プロセスがセグメンテーション違反で異常終了し、無効の場合には以下のメッセージがログに出力されていました。
-</p>
-<pre>
-    ERROR: pool_discard_cp: cannot get connection pool for user (null) database (null)
-</pre>
-
-<p>
-また、両方の場合で psql はフロントエンドに何のメッセージ出力せずに終了していました。
-修正後は、スタートアップパケットに PostgreSQL ユーザが指定されていない場合には以下のメッセージがログとフロントエンドの両方に出力されます。
-これは PostgreSQLと同じ振る舞いです。
-</p>
-<pre>
-    FATAL: no PostgreSQL user name specified in startup packet
-</pre>
-</li>
-
-<li>
-マニュアルの ssl_sa_cert, ssl_ca_cert_dir オプションの説明を SSL セクションに移動しました。(Yugo Nagata)
-</li>
-
-<li>
-ssl_sa_cert, ssl_ca_cert_dir オプションの説明を日本語マニュアルに追加しました。(Yugo Nagata)
-</li>
-
-<li>
-pcp_recovery_node コマンドで、バックエンドノード番号をチェックするように修正しました。(Yugo Nagata)
-<p>
-不正な値が使用された場合、リカバリで実行されるスクリプトの引数に空の値が渡されており、誤動作の原因となっていました。
-特にベースバックアップを行うスクリプトで、rsync が関係のないファイルを削除してしまうことがありました。
-</p>
-</li>
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.0.11"></a>3.0.11 (umiyameboshi) 2013/04/26</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<p>
-このバージョンでは、3.0.10における様々なバグが修正されています。
-</p>
-<h3>バグ修正</h3>
-<ul>
-
-<li>
-設定パラメータの一覧を表示する "SHOW pool_status" で pool_passwdが表示されていないのを修正しました。(Yugo Nagata)
-</li>
-
-<li>
-拡張プロトコルの処理における timestamp の書き換えに関する長い間見過ごされていてたバグを修正しました。(Tatsuo Ishii)
-<p>
-  Parse() 関数は、parse メッセージの書き換えの際に palloc() を使ってメモリを確保していました。
-  書き換えられたメッセージは pool_create_sent_message()
-  関数などが管理するデータ領域に格納されますが、これが問題となっていました。
-  この関数ではデータが session context memory 中に存在することを想定しているのに対し、
-  palloc() では query context においてメモリの割り当てを行っており、この領域は
-  query context 終了時に解放されます。しかし、他の関数もこのメモリ領域を解放しようとするため、
-  セグメンテーション違反や二重解放を含む様々な問題の原因となっていました。
-  この問題は、書き換えたメッセージを格納するメモリを session context を用いて確保するこで修正されました。
-  これは pgpool-II 3.0 以来ずっと存在していたバグです。
-</p>
-<p>
-  この問題は、Naoya Anzai さんによって解析され、パッチが提供されました。
-</p>
-<blockquote>
-  [pgpoolgenera-jp: 1146]<br />
-  拡張問い合わせプロトコルでセグメンテーションフォルト<br />
-  <a href="http://www.pgpool.net/pipermail/pgpool-general-jp/2013-March/001145.html">
-  http://www.pgpool.net/pipermail/pgpool-general-jp/2013-March/001145.html
-  </a>
-</blockquote>
-</li>
-
-<li>
-md5認証で長いユーザ名を処理する際のバグを修正しました。(Tatsuo Ishii)
-<p>
-  ユーザ名が 32 バイトより長い場合、md5 認証が動作していませんでした。
-  この問題は [pgpool-general: 1526] で Thomas Martin さんにより報告されました。
-</p>
-<blockquote>
-  [pgpool-general: 1526]<br />
-  [pgPool-II 3.2.3] MD5 authentication and username longer than 32 characters.<br />
-  <a href="http://www.pgpool.net/pipermail/pgpool-general/2013-March/001551.html">
-  http://www.pgpool.net/pipermail/pgpool-general/2013-March/001551.html
-  </a>
-</blockquote>
-</li>
-
-<li>レプリケーション遅延の計算はスタンバイサーバがプライマリサーバより遅れている場合にのみ行うよう修正しました。(Yugo Nagata)
-<p>
-  タイミングによってスタンバイよりプライマリの方がレプリケーションが遅延
-  しているように見える場合があり、その場合には負値の遅延が計算されていました。
-  この値が符号無し変数に代入されると、実際には遅延が生じていないにも関わらず、
-  ログに遅延が負値で出力され、されに悪いことには、ロードバランス機能により
-  SELECT クエリがプライマリに振り分けられ、その結果プライマリの負荷が高まる
-  ことがありました。
-</p>
-<p>
-  この問題は Saitoh Hidenori さんによって報告、解析されました。
-</p>
-<blockquote>
-  [pgpool-genera-jp: 1145]<br />
-  レプリケーション遅延確認の不具合について<br />
-  <a href="http://www.pgpool.net/pipermail/pgpool-general-jp/2013-March/001144.html">
-  http://www.pgpool.net/pipermail/pgpool-general-jp/2013-March/001144.html
-  </a>
-</blockquote>
-</li>
-
-<li>pgpool-recovery が PostgreSQL 9.3 に対応しました。 (Tatsuo Ishii)
-<p>
-  パッチは Asif Rehman さんにより提供され、これに Tatsuo Ishii が若干の修正を
-  加えました。
-</p>
-<blockquote>
-  [pgpool-hackers: 180] <br />
-  compile error in ppool-recovery<br />
-  <a href="http://www.pgpool.net/pipermail/pgpool-hackers/2013-April/000179.html">
-  http://www.pgpool.net/pipermail/pgpool-hackers/2013-April/000179.html
-  </a>
-</blockquote>
-</li>
-
-<li>pool_has_pgpool_regclass が pgpool_regclass() の実行権限をチェックするよう修正しました。 (Tatsuo Ishii)
-<p>
-  pgpool_regclass が存在する場合でも、pgpool がこの関数を実行できない場合に、
-  バックエンドへの接続がハングしていました。この問題は、pgpool_regclass
-  から実行権限を剥奪し、ネイティブレプリケーションモードで INSERT を実行
-  することで再現可能です。
-</p>
-<p>
-  この問題は bugtrack #53 で報告されました。
-</p>
-<blockquote>
-  #53 pgpool_regclas hangs all connections<br />
-  Date:     2013-04-04 13:35 <br />
-  Reporter: tmandke<br />
-  <a href="http://www.pgpool.net/mantisbt/view.php?id=53">
-  http://www.pgpool.net/mantisbt/view.php?id=53
-  </a>
-</blockquote>
-</li>
-
-<li>detect_postmaster_down_error() のエラーメッセージを修正しました。(Tatsuo Ishii)
-<p>
-  例えば、"LOG: detect_stop_postmaster_error: detect_error error" を
-  "LOG: detect_postmaster_down_error: detect_error error" に修正するなどです。
-</p>
-</li>
-
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2>3.0.10 (umiyameboshi) 2013/02/08</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>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>コネクションプールが存在しない場合には、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>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<p>
-このバージョンでは、3.0.7における様々なバグが修正されています。
-</p>
-
-<h3>バグ修正</h3>
-<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>
-<p>
-このバージョンでは、3.0.3における様々なバグが修正されています。
-</p>
-
-<h3>互換性のない変更</h3>
-<p>
-</p><ul>
- <li>ストリーミングレプリケーションにおいて、<a href="#DELAY_THRESHOLD">delay_threshold</a> が
-    0またはヘルスチェックが無効ならば、遅延チェックは実施されません。
-    これはpgpool-IIマニュアルとおりの動作ですが、これまではヘルスチェックが無効の場合も
-    遅延チェックが実施されていました(Guillaume Lelarge)
-</li></ul>
-<p></p>
-
-<h3>バグ修正</h3>
-<p>
-</p><ul>
- <li>pgpool-regclass()をPostgreSQL 8.0以降でコンパイルできるように修正しました。7.4はまだエラーが出ます(Tatsuo Ishii)
- </li><li>ストリーミングレプリケーション構成で/*NO LOAD BALANCE*/コメントを使用したときに
-    ハングアップする可能性を修正しました(Toshihiro Kitagawa)
- </li><li>Flush(H)メッセージやCloseComplete(C)メッセージを受信したときのハングアップを修正しました(Toshihiro Kitagawa)
- </li><li>pgpool-IIがバックエンドに接続後、RedyForQuery(Z)メッセージを受信するタイミングによって起こり得る
-    ハングアップを修正しました(Toshihiro Kitagawa)
- </li><li><a href="#RECOVERY_1ST_STAGE_COMMAND">recovery_1st_stage_command</a> と
-     <a href="#RECOVERY_2ND_STAGE_COMMAND">recovery_2nd_stage_command</a> パラメータの説明を追加しました(Tatsuo Ishii)
- </li><li>pgpool-II内部で使用するシステムカタログキャッシュのサイズを32から128に増やしました。
-    これは"unnamed prepared statement does not exist"エラーを軽減する効果があります。(Tatsuo Ishii, Toshihiro Kitagawa)
- </li><li>pcp_connect()関数で二重free()を行うバグを修正しました。
-     パッチはJehan-Guillaume (ioguix) de Rorthaisさんから頂きました(Tatsuo Ishii)
- </li><li>PQfinish()関数を誤って使用しているstart_recoery()のバグを修正しました(Tatsuo Ishii)
- </li><li>クライアントのアイドル時間が <a href="#CLIENT_IDLE_LIMIT">client_idle_limit</a> に達したときに、
-    フロントエンドに送信される正しくないエラーメッセージを修正しました(Tatsuo Ishii)
- </li><li>pool_statusの「backend status」変数の名前を正しく修正しました。
-    スペースを'_'に置き換えました(Guillaume Lelarge)
- </li><li>md5認証方式を採用してデーモンとして実行したときのハングアップを修正しました。
-    パッチは、Nicolas Thauvinさんから頂きました(Tatsuo Ishii)
- </li><li>拡張問い合わせプロトコルでSQL文が出力されるように、
-    <a href="#LOG_PER_NODE_STATEMENT">log_per_node_statement</a>を修正しました。
-    これは以前は動作していましたが、3.0で動作しなくなっていました(Toshihiro Kitagawa)
-</li></ul>
-<p></p>
-
-<h3>改良</h3>
-<p>
-</p><ul>
- <li>サンプルの設定ファイルの <a href="#BLACK_FUNCTION_LIST">black_function_list</a> に
-    currval()とlastval()を追加しました。
-    もしそれらがロードバランスされると、nextval()やsetval()の結果がスレーブに反映される前に
-    currval()またはlastval()が呼ばれることがあります(Tatsuo Ishii)
-</li></ul>
-<p></p>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.0.3"></a>3.0.3 (umiyameboshi) 2011/02/23</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<p>
-このバージョンでは、3.0.1における様々なバグが修正されています
-(pgpool-II 3.0.2のリリースはパッケージングの問題でキャンセルされました)。
-</p>
-
-<h3>互換性のない変更</h3>
-<p>
-</p><ul>
- <li>ストリーミングレプリケーションモードを使用する場合に、PostgreSQLサーバに
-    C関数「pgpool_walrecrunning()」をインストールすることが推奨されます(後述)。
-    この場合、新しい変数「%P」がオンラインリカバリのスクリプトで利用できるようになります。
-    この関数をインストールしない場合は、従来と同じ動作になります(Tatsuo Ishii)
- </li><li>rawモードでDBノードがひとつだけの場合、DBノードに問題が発生するとダウン状態になりますが、
-    DBノードが復旧したらpgpoolの再起動なしにDBノードを使用できるようにしました。
-    この変更は3.0に含まれていましたが、動作していませんでした(Tatsuo Ishii, Toshihiro Kitagawa)
-</li></ul>
-<p></p>
-
-<h3>バグ修正</h3>
-<p>
-</p><ul>
- <li>パスワード認証における移植性を損なうコードを修正しました。
-    これはFreeBSDユーザからのバグ報告に基づきます(Tatsuo Ishii)
- </li><li><a href="#INSERT_LOCK">insert_lock</a> がユーザテーブルの全行をロックするバグを
-    修正しました(Tatsuo Ishii, Toshihiro Kitagawa)
- </li><li>ユーザ名の長さが32バイトのときにpgpool子プロセスがクラッシュする
-    パスワード認証のバグを修正しました(Tatsuo Ishii)
- </li><li>rawモードまたはバックエンドノード数が1のときに、pgpool子プロセスがクラッシュする
-    md5認証のバグを修正しました。パッチはRob Shepherdさんから頂きました(Tatsuo Ishii)
- </li><li>以前からあった配列と複合型に対するタイムスタンプ書き換えのバグを修正しました。
-    パッチはAkio Ishidaさんから頂きました(Tatsuo Ishii)
- </li><li><a href="#DEBUG_LEVEL">debug_level</a> パラメータが動作しないバグを修正しました。
-    パッチはGilles Daroldさんから頂きました(Tatsuo Ishii)
- </li><li>フェイルオーバー中に起こりうるpgpool子プロセスのクラッシュを修正しました(Toshihiro Kitagawa)
- </li><li>ユーザがスキーマ名の付いた関数を呼んだときに <a href="#WHITE_FUNCTION_LIST">white/black_function_list</a> が
-    正しく動作するように修正しました(Tatsuo Ishii)
- </li><li>コネクションキャッシュによってDROP DATABASEが失敗するバグを修正しました(Toshihiro Kitagawa)
- </li><li>rawモードでフェイルオーバが失敗するバグを修正しました(Toshihiro Kitagawa)
- </li><li>1セッションで簡易問い合わせプロトコルと拡張問い合わせプロトコルの両方が使われたときに起こりうる
-    pgpool子プロセスの終了を修正しました(Toshihiro Kitagawa)
- </li><li>拡張問い合わせプロトコルを使用中にエラーが発生すると起こりうるハングアップを修正しました(Toshihiro Kitagawa)
- </li><li>PG_TRY/CATCHを使用しないようにpgpool-regclass()を修正しました。(Tatsuo Ishii)
-    <p>
-    PG_TRY/CATCHは、時々バックエンドが「PANIC:  ERRORDATA_STACK_SIZE exceeded.」というメッセージとともに
-    終了するので安全でないように見えます。
-    </p>
- </li><li>JDBCドライバがマスタノードに何度もBEGINを発行するロードバランスのバグを修正しました(Toshihiro Kitagawa)
- </li><li><a href="#FAILBACK_COMMAND">failback_command</a> と
-     <a href="#FAIL_OVER_ON_BACKEND_ERROR">fail_over_on_backend_error</a> が
-     正しい値を表示するように <a href="#pool_status">pool_status</a> を修正しました(Toshihiro Kitagawa)
- </li><li><a href="#pool_status">pool_status</a> から <a href="#RECOVERY_PASSWORD">recovery_password</a> と
-    <a href="#SYSTEM_DB_PASSWORD">system_db_password</a> を削除しました(Toshihiro Kitagawa)
- </li><li>ストリーミングレプリケーションモードでフェイルオーバを実行中に、
-    バックエンドのログに「unexpected EOF on client connection」が出ないように修正しました(Tatsuo Ishii)
- </li><li>バックエンドがすべてダウンした場合に発生するpgpoolのクラッシュを修正しました(Tatsuo Ishii)
- </li><li>レプリケーション遅延チェックがバックエンドとの永続的な接続を行わないように修正しました。(Tatsuo Ishii)
-    <p>
-    これは、レプリケーション遅延チェックの間でDBノードのダウンとアップが起きた場合に永続的な接続が
-    不正になる可能性があるためです。
-    </p>
- </li><li>英語ドキュメントを書き直してレビューしました(Marc Cousin, Gleu)
- </li><li>以下の条件を満たすとき SELECT クエリがマスタノードに送信されないバグを修正しました(Toshihiro Kitagawa)
- <ul>
-  <li>マスタースレーブモードである
-  </li><li>拡張問い合わせプロトコルを使用している
-  </li><li>明示的にトランザクションを開始している
-  </li><li>更新クエリを実行した後である
- </li></ul>
- </li><li>ストリーミングレプリケーションモード利用時のオンラインリカバリにおいて、
-    以下のシナリオがうまく動作しない問題を修正しました。
-    以下のシナリオでは、ノード0を最初のプライマリサーバ、ノード1を最初のスタンバイサーバとします。
-      <ol>
-       <li>ノード0プライマリサーバがダウンし、ノード1スタンバイサーバが新しいプライマリサーバになる
-       </li><li>ノード0の旧プライマリサーバは、オンラインリカバリで新スタンバイサーバになる
-       </li><li>このときpgpool-IIは、ノード0の新スタンバイサーバを、プライマリサーバとみなしてしまう
-      </li></ol>
-    これは、生きているノード番号の一番若いサーバをプライマリサーバと見なしていたためです。
-    pgpool-II 3.0.3では、pgpool_walrecrunning()を使って、実際にそのノードがプライマリサーバかどうか
-    判定するため、このような問題は起きません。
-    この機能をうまく使うために、オンラインリカバリのスクリプトで
-    %P(古いプライマリノード番号)が利用できるようになっています。
-    なお、pgpool_walrecrunning()がインストールされていない場合は、上の問題は解消されず、
-    3.0.1と同様の動作になります。
-</li></ul>
-<p></p>
-
-<h3>改良</h3>
-<p>
-</p><ul>
- <li>ステータスファイルを読んでいるときに、特定のバックエンドがダウン状態ならば
-     ログを出力するようにしました(Tatsuo Ishii)
- </li><li>pgpoolが実行したクエリでエラーが発生した場合に、エラーメッセージを出力するようにしました(Tatsuo Ishii)
- </li><li>sqlディレクトリに主要なMakefileを追加しました(Tatsuo Ishii)
-</li></ul>
-<p></p>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.0.2"></a>3.0.2(umiyameboshi) 2011/02/17</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<p>
-このバージョンは問題があったために、リリースが取り消されました。
-</p>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.0.1"></a>3.0.1 (umiyameboshi) 2010/10/19</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<p>
-このバージョンでは、3.0における様々なバグが修正されています。
-</p>
-
-<h3>バグ修正</h3>
-<p>
-</p><ul>
- <li>認証されるサーバが複数ある場合にクラッシュするmd5認証のバグを修正しました(Tatsuo Ishii)
- </li><li>拡張問い合わせプロトコルにおいて、構文エラーのクエリを実行したときに
-     子プロセスがクラッシュするバグを修正しました(Toshihiro Kitagawa)
- </li><li>ポータル情報のハンドリングにおける子プロセスが終了するバグを修正しました(Toshihiro Kitagawa)
- </li><li>拡張問い合わせプロトコルにおいて、ひとつのノードに送信されたクエリがエラーを起こしたときに
-    ハングアップするバグを修正しました(Toshihiro Kitagawa)
- </li><li>英語ドキュメントの誤植を修正しました。Asaf Ohaionさんのパッチを取り込みました(Tatsuo Ishii)
-</li></ul>
-<p></p>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release3.0"></a>3.0 (umiyameboshi) 2010/09/10</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<p>
-このバージョンは3.0系列の最初の版で、2.2系や2.3系からの「メジャーバージョンアップ」にあたります。
-PostgreSQL 9.0の新機能であるStreaming Replication/Hot Standby構成に対応するなど、
-多くの機能が追加されると共に、内部構造が整理されて見通しが良くなって保守性が向上しています。
-</p>
-<p>
-マスタースレーブモード全般で多くの改善がなされています。
-</p><ul>
- <li>明示的なトランザクション内のSELECTが負荷分散できるようになりました
- </li><li>不必要なDBノードにparse/bindメッセージが送られなくなりロック競合が減りました
- </li><li>不必要な内部トランザクションの起動がなくなり、オーバヘッドが軽減しています
- </li><li>一時テーブルを意識せずに安全に使えるようになりました
- </li><li>書き込みを伴う関数呼び出しを行なうSELECTをマスター(primay)でのみ実行するように制御できるようになりました
-</li></ul>
-<p></p>
-<p>
-レプリケーションモードにおいても、書き込みを伴う関数呼び出しを行なうSELECTを負荷分散するかどうかの制御できるようになるなどの改良が加えられています。
-</p>
-
-<h3>新機能</h3>
-<p>
-</p><ul>
- <li>PostgreSQL 9.0の新機能であるStreaming Replication/Hot Standby(SR+HS)構成に対応しました(Tatsuo Ishii, Toshihiro Kitagawa)。
-     <p>
-     pgpool-IIは基本的にはmaster/slave modeとして動作しますが、その際に
-     "<a href="#MASTER_SLAVE_SUB_MODE">master_slave_sub_mode</a>" という
-     新しい設定項目に"stream"を設定することにより、SR+HS構成に最適な動作をします。
-     たとえば、更新クエリはPrimaryサーバにのみ送信し、SELECTはPrimaryとStandbyサーバに負荷分散することが可能です。
-     </p>
-     <p>
-     そのほか、Standbyサーバをオンラインリカバリで復旧したり、PrimaryとStandbyのレプリケーション同期を監視し、
-     遅れが大きいようならPrimaryにのみSELECTを送信させるようにすることも可能です。
-     </p>
-     <p>
-    詳細は<a href="#stream">Streaming Replicationへの対応"</a>をご覧下さい。
-    </p>
-
-<ul>
- <li>オンラインリカバリがStreaming Replication対応で動作しているmaster/slaveモードに対応しました(Tatsuo Ishii)
-
- </li><li>Streaming Replicationモード用の新しい設定項目 "<a href="#DELAY_THRESHOLD">delay_threshold</a>" が追加され、
-    レプリケーションの遅れが監視できるようになりました。
-    遅延が多い場合には、負荷分散しないようにすることができます(Tatsuo Ishii)
-
- </li><li><a href="#pool_status">show pool_status</a> で、Streaming Replicationにおける
-    レプリケーションの遅延が確認できるようになりました(Tatsuo Ishii)
-
- </li><li>Streaming Replicationにおけるレプリケーションの遅延のログを制御する新しい設定項目
-    "<a href="#LOG_STANDBY_DELAY">log_standby_delay</a>" が追加されました(Tatsuo Ishii)
-
-</li></ul>
-
- </li><li><a href="#INSERT_LOCK">insert_lock</a> が有効で、テーブルにシリアル型が含まれている場合、
-    テーブルロックではなく、該当シーケンスを行ロックするようにしました。(Tatsuo Ishii)
-    <p>
-    以前はテーブルロックをしていましたが、auto vacuumとロックが衝突したりして
-    性能が低下する問題がありました。
-    </p>
-
- </li><li>新しい"SHOW"コマンドが追加されました。すなわち、<a href="#pool_nodes">pool_nodes</a>,
-     <a href="#pool_processes">pool_processes</a>, <a href="#pool_pools">pool_pools</a>,
-     <a href="#pool_version">pool_version</a> です(Guillaume Lelarge)
-
- </li><li><a href="#pcp_proc_info">pcp_proc_info</a> コマンドの出力結果に、
-     PostgreSQLバックエンドプロセスのプロセスIDとフロントエンドからの接続があるかどうかが追加されました(Tatsuo Ishii)
-
- </li><li>関数呼び出しを伴うSELECTを制御する設定項目 <a href="#WHITE_FUNCTION_LIST">white_function_list</a> と
-     <a href="#BLACK_FUNCTION_LIST">back_function_list</a> が追加されました(Tatsuo Ishii)
-
- </li><li>マスタースレーブモードにおいて、システムカタログを検索するSELECTは、整合性を保つために
-    常にマスター(primary)で実行されるようになりました(Tatsuo Ishii)
-
- </li><li>マスタースレーブモードにおいて、一時テーブルを検索するSELECTは、整合性を保つために
-    常にマスター(primary)で実行されるようになりました(Tatsuo Ishii)
-
- </li><li>マスタスレーブモードで、明示的なトランザクション内で実行されない更新クエリにおいて、
-    自動的にトランザクションを開始することを止めました。(Tatsuo Ishii)
-    <p>
-    これは不必要でした。これによって、パフォーマンスが向上しています。
-    </p>
-
- </li><li>マスタスレーブモードで、明示的なトランザクション内で実行されるSELECTコマンドが
-     負荷分散できるようになりました(Tatsuo Ishii, Toshihiro Kitagawa)
-
- </li><li>マスタスレーブモードで、必要なDBノードにのみコマンドが送られるようになりました。
-     (Tatsuo Ishii, Toshihiro Kitagawa)
-     <p>
-     これにより、たとえばパースコマンドが不必要なDBノードにおいても
-     ロックを取ってしまうようなことがなくなりました。
-     </p>
-
- </li><li>pgpoolの起動時に、ステータスファイルを無視するオプションが追加されました(Tatsuo Ishii)
-
- </li><li>PostgreSQL 9.0のVACUUMの新しい書式をpgpool-IIのパーサがサポートしました(Tatsuo Ishii)
-
- </li><li>フェイルオーバ/フェイルバックコマンドで、"%H"という特殊変数が利用できるようになりました。
-    これは、新しいマスターノードのホスト名を表します(Tatsuo Ishii)
-
- </li><li><a href="#FAILOVER_IF_AFFECTED_TUPLES_MISMATCH">failover_if_affected_tuples_mismatch</a> という設
-     定項目が追加されました(Tatsuo Ishii)
-     <p>
-     従来、レプリケーションモードでINSERT/UPDATE/DELETEの結果行数が異なると、
-     トランザクションをアボートしてセッションを強制切断していました。
-     failover_if_affected_tuples_mismatch を trueに設定すると、この現象が起きたときに、
-     不一致のあったDBノードを切り放して縮退運転に入るようになります。
-     </p>
-
- </li><li>レプリケーションモードでDBノード間でINSERT/UPDATE/DELETEの結果行数の不一致が検出された際に、
-     DBノードにおける結果行数がログに記録されるようになりました(Tatsuo Ishii)
-
- </li><li>レプリケーションモードとマスタスレーブモードで、md5認証がサポートされました(Tatsuo Ishii)
-
- </li><li>オンラインリカバリで、強制的にフロントエンドへの接続を切断して
-    直ちにセカンドステージに入ることができるようになりました。(Tatsuo Ishii)
-    <p>
-    そのためには、<a href="#CLIENT_IDLE_LIMIT_IN_RECOVERY">client_idle_limit_in_recovery</a> に
-    -1 を設定します。
-    </p>
-
- </li><li>RAWモードにおいて、DBノードが1個だけしか存在しない状態でDBがエラーを起したために
-    DBノードを切り放したあとでDBノードが回復した場合に、pgpool-IIを再起動することになしに
-    DBノードを利用できるようになりました(Tatsuo Ishii)
-
- </li><li>pcpコマンドにおいて、ロングオプションがサポートされました(Guillaume Lelarge)
-
- </li><li><a href="#DEBUG_LEVEL">debug_level</a> という設定項目が追加され、
-     pgpool.confの再読み込みによってデバッグメッセージの出力をオン／オフできるようになりました(Tatsuo Ishii)
-
- </li><li>pgpool.confで、postgresql.confと同じ真偽値表現が利用できるようになりました。
-     従来は、true/false, 1/0しか使えませんでした(Toshihiro Kitagawa)
-
- </li><li>オンラインリカバリのセカンドステージをより安全に実行するために、
-     C言語関数 <a href="#recovery_pitr">pgpool_switch_xlog</a> を追加しました(Toshihiro Kitagawa)
-
- </li><li>異なるスキーマに同じ名前のテーブルが存在する場合に起きる不具合を回避するために、
-     C言語関数pgpool_regclassを追加しました(Tatsuo Ishii)
-
-</li></ul>
-<p></p>
-
-<h3>互換性のない変更</h3>
-<p>
-</p><ul>
-<li><a href="#REPLICATE_SELECT">replicate_select</a> と <a href="#LOAD_BALANCE_MODE">load_balance_mode</a> を
-    共にtrueに設定した場合、トランザクションブロックの外側で実行されるSELECT文は、
-    replicate_selectに従うようになりました。
-    以前は、load_balance_modeに従うようになっていました。
-    <p>
-    もしクライアントがこの動作を利用している場合は、replicate_selectをfalseにして
-    <a href="#BLACK_FUNCTION_LIST">back_function_list</a> を設定することで同じ動作を実現できます。
-    </p>
-    </li>
-</ul>
-<p></p>
-
-<p>
-</p><h3>バグ修正</h3>
-<p></p>
-<p>
-</p><ul>
-
- <li>型が時刻データ以外の列の場合、デフォルト値にnow()が含まれていても書き換えを行なわないようにしました。(Tatsuo Ishii)
-     <p>
-     今までは無条件に書き換えを行なっていたため、書き換えの結果、INSERT文などがエラーになっていました。
-     </p>
-
- </li><li>タイムスタンプの書き換え処理対象となるテーブルのスキーマが無視されないようにしました。(Tatsuo Ishii)
-    <p>
-    ただし、この機能を有効にするためには、付属のユーザ定義関数"pgpool_regclass"のインストールが必要です。
-    この関数がインストールされていない場合は、依然としてスキーマが無視されてしまいます。
-    </p>
-
- </li><li>pcpコマンドのタイムアウトの扱いにおけるバグが修正されました(Tatsuo Ishii)
-
- </li><li>SSLが有効な状態で、大量のデータ通信が起るとハングする問題が修正されました(Tatsuo Ishii)
-
- </li><li>DBノードが1個だけしか存在しない状態でDBがエラーを起したた際に、
-    間違ったDBノードがフェイルオーバするバグを修正しました(Tatsuo Ishii)
-
- </li><li>オンラインリカバリ時のpostmasterの起動チェックにおけるバグを修正しました。(Tatsuo Ishii)
-     <p>
-    今まではpostmasterへの最初の接続が失敗すると、接続を無限に繰り返すようになっていました
-     </p>
-
-</li></ul>
-<p></p>
-
-<!-- ================================================================================ -->
-<!-- 2.3                                                                              -->
-<!-- ================================================================================ -->
-<hr><a name="release2.3.x"></a>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release2.3.4"></a>2.3.4 (tomiteboshi) 2012/08/06</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<p>このバージョンでは、2.3.3 以前の色々なバグが修正されています。</p>
-
-<h3>バグ修正</h3>
-
-<ul>
-<li>
-do_error_execute_command() が ErrorResponse を受け取るまでバックエンドからの
-結果を見ないように修正しました。 (Toshihiro Kitagawa)
-<p>
-ReadyForQuery のようなエラーでない結果をとっておき、pool_unread() で呼び出す必要があるためです。
-これは PHP PDO を使っているときに起こる可能性がありました。
-</p>
-</li>
-
-<li>
-SimpleForwardToFrontend() が、SELECT 実行中に bind エラーになったとき、
-select_in_transaction フラグと execute_select フラグををリセットするように修正しました。
-(Toshihiro Kitagawa)
-</li>
-
-<li>
-バックエンドからたくさんの結果を読み込んでいる間に、SSL 接続がハングすることが
-あるのを修正しました。Tatsuo Ishii)
-<p>詳細は、[Pgpool-general] Fwd: PGPOOL II 2.3.3 hang in ssl mode のスレッドを参照してください。</p>
-</li>
-
-<li>
-pcp_check_fd() のタイムアウト処理のバグを修正しました。 (Tatsuo Ishii)
-  <p>これは以下で報告されました。 </p>
-  <blockquote>
-  Subject: [Pgpool-general] question about pcp_check_fd
-  Date: Sun, 23 May 2010 18:21:41 -0500
-  To: pgpool <pgpool-general@pgfoundry.org>
-  </blockquote>
-</li>
-
-<li>
-master/slave モードで稼働中、DEALLOCATE をレプリケーションしないようにしました。(Toshihiro Kitagawa)
-<p>これは、以下で Jan Kantert から報告されました。</p>
-<blockquote>
-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
-</blockquote>
-</li>
-
-<li>タイムスタンプの書き換えで、スキーマを認識するようにしました。(Tatsuo Ishii)</li>
-
-<li>
-now() などデフォルト値にもつがデータ型が timestamp 型でないようなカラムへの
-アクセスがあるステートメントを、書き換えないようにしました。(Tatsuo Ishii)
-
-<p>そうしていなかったために、DML でエラーになっていました。</p>
-<blockquote>
-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)
-</blockquote>
-</li>
-
-<li>insert_lock がスキーマを認識するようになりました。(Tatsuo Ishii)</li>
-
-<li>
-配列型や複合型のカラムのタイムスタンプ書き換えにおける、古くからあるバグを
-修正しました。(Tatsuo Ishii)
-<p>例えば、以下の場合に失敗していました。</p>
-<pre>
-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;
-</pre>
-
-<p>パッチは Akio Ishida から提供されました。</p>
-</li>
-
-<li>pcp パスワードが 32 文字以上のときに、バッファオーバーランするのを修正しました。(Tatsuo Ishii)</li>
-
-<li>
-wait_for_query_response() が、frontend がないときには何もしないように修正しました。(Tatsuo Ishii)
-<p>
-バックエンドをリセットする reset_query_list のクエリを実行に 時間がかかったときに発生する可能性があり、
-またクラッシュすることがありました。
-</p>
-</li>
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release2.3.3"></a>2.3.3 (tomiteboshi) 2010/04/23</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<p>このバージョンでは、2.3.2.2 以前の色々なバグが修正されています。</p>
-
-<h3>互換性のない変更</h3>
-<ul>
-<li>このバージョンから、pgpool が以前より多くの共有メモリを使うようになったので注意してください。
-    <p>
-    これによる問題が pgpool の起動時に発生した場合は、pgpool のログを見てください。
-    "could not create shared memory segment: Cannot allocate memory" といったメッセージがあれば、
-    システムの共有メモリを増やしてください。
-    </p>
-    </li>
-    <li>パラレルモードが、レプリケーションモードかロードバランスモードが有効でないと
-        使えないようになりました。(Toshihiro Kitagawa)
-        <p>
-        pgpool-II ではずっと、レプリケーションモードかロードバランスモードが有効でないとき
-        パラレルモードは正しく動作していませんでした。
-        </p>
-</li>
-<li><a href="#INSERT_LOCK">insert_lock</a> のデフォルト値を false に変更しました。(Tatsuo Ishii)
-    <p>
-    これは、マスタ・スレーブモードでは true にしても無意味なためです。
-    Fujii Masao さんの指摘により修正しました。
-    </p>
-    </li>
-</ul>
-
-<h3>新しく追加したドキュメント</h3>
-<ul>
-<li>README.online-recovery を追加しました。このドキュメントには、オンラインリカバリの内部的なことが書いてあります。</li>
-</ul>
-
-<h3>バグ修正</h3>
-<ul>
-<li>子プロセスが segfault を起こす pgpool-II 1.0 から長い間存在したバグを修正しました。
-    これは、親プロセスが shmem サイズの計算を間違えていたことに起因します。
-    バグ解析(Toshihiro Kitagawa)、パッチ作成(Tatsuo Ishii)</li>
-
-<li>ドキュメントにパラレルモード用の以下の制約を追記しました。(Toshihiro Kitagawa)
-  <ul>
-  <li>- NATURAL JOIN は使えません。</li>
-  <li>- USING 句が、クエリ書き換え処理によって ON 句に変換されます。</li>
-  </ul>
-</li>
-
-<li>パラレルモードのとき、USING 句を含む JOIN 構文の書き換えで発生する可能性があった
-    クラッシュを修正しました。(Toshihiro Kitagawa)<br>
-    <p>
-    この修正により、以下のような JOIN 構文が使えるようになります。<br>
-    例：
-    </p><pre>SELECT * FROM a JOIN b USING (aid) JOIN c USING (cid);
-SELECT * FROM a JOIN b USING (aid) JOIN c USING (cid) JOIN d USING</pre>
-</li>
-
-<li>パラレルクエリで、分散キー列の前に current_time を含む INSERT 文のパースができるように修正しました。</li>
-
-<li>SimpleForwardToBackend() を修正しました。(Toshihiro Kitagawa)
-    <p>
-    これにより、拡張プロトコルを使ったクライアントが bind エラーのようなエラーを発生させたときに、
-    pgpool がバックエンドの応答を待ち続けなくなります。
-    このバグは、マスタ・スレーブモード、raw モード、コネクションプールモードで発生していました。
-    </p>
-    <p>
-    これを修正したことによって、コマンドがエラーになったあと、エラーを回復させるために
-    SYNC メッセージを送るようになります。
-    </p>
-</li>
-
-<li>select() を実行中の pgpool 子プロセスが、SIGINT/SIGQUIT シグナルを無視するように修正しました。
-シグナルが送られても pgpool は select() を再実行しようとするので、結果的にシグナルが無視されます。(Tatsuo Ishii)</li>
-
-<li>connect_inet_domain_socket_by_port/connect_unix_domain_socket_by_port が
-    SIGTERM/SIGINT/SIGQUIT シグナルを受け取っていないかチェックするように修正しました。
-    Daniel Codina さんからのバグ報告に基づきます。(Tatsuo Ishii)</li>
-
-<li>"kind mismatch" というエラーメッセージを生成する際にクラッシュする可能性があったので、これを修正しました。
-    以前は問題なかったのですが、2.3.2でエンバグしました。(Tatsuo Ishii)</li>
-
-<li>ヘルスチェックにおけるバグを修正しました。(Tatsuo Ishii)
-    <p>
-    コードが抜けたなどでネットワーク障害が発生したときに、connect() を呼んでいる間は
-    ヘルスチェックが行なわれていませんでした。
-    これは、connect() が ALARM シグナルによって割り込まれた際に、
-    connect_unix_domain_socket() / connect_inet_domain_socket() が再試行していたためです。
-    この修正では、上記の関数に対して再試行をコントロールするような引数を追加しています。
-    </p>
-    <p>
-    これは、Daniel Codina さんのバグ報告と分析に基づく修正です。
-    </p>
-</li>
-
-<li>2.3.2.2 で、SimpleForwardToBackend でのタイムスタンプの書き換えにおいてエンバグしていたので、
-    これを修正しました。(Tatsuo Ishii)
-    <p>
-    これは、バグトラック #1010771 にある Peter Pramberge さんらの報告に基づきます。
-    </p>
-</li>
-
-<li>パラレルクエリにおける "*" の書き換えを修正しました。
-    sho さんから提供いただいたパッチを取り込みました。(Toshihiro Kitagawa)</li>
-
-<li>connect_inet_domain_socket_by_port() でエラーメッセージを出力する際に、
-    strerror() ではなく hstrerror() を使うように修正しました。 (Tatsuo Ishii)</li>
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release2.3.2.2"></a>2.3.2.2 (tomiteboshi) 2010/02/22</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<p>
-このバージョンでは、2.3.xにおける様々なバグを修正しています。
-とくにタイムスタンプの書き換え時のクラッシュを含む致命的なバグが修正されているので、
-すべての2.3ユーザは早急にアップグレードすることをお勧めします。
-</p>
-
-<h3>バグ修正</h3>
-<p>
-</p><ul>
- <li>タイムスタンプデータを含む拡張プロトコル問い合わせで、
-    "message: invalid string in message"のエラーを出してトランザクションが終了してしまう
-    バグを修正しました(Tatsuo Ishii)
- </li><li>タイムスタンプデータを含む拡張プロトコル問い合わせで、bind時にNULLを含むパラメータが存在すると
-     pgpoolがクラッシュするバグを修正しました(Tatsuo Ishii)
- </li><li>pgpool_status上ですべてのノードがダウンのときにはこれを無効とし、
-    「all node down症候群」が起きないようにしました(Tatsuo Ishii)
-</li></ul>
-<p></p>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release2.3.2.1"></a>2.3.2.1 (tomiteboshi) 2010/02/11</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<p>
-このバージョンでは、2.3.xにおいて、エラーとなるようなSQLを実行すると
-pgpoolへのセッションが切断されるバグを修正しています(Akio Ishida)。
-</p>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release2.3.2"></a>2.3.2 (tomiteboshi) 2010/02/07</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<p>
-このバージョンでは、2.3.1の色々なバグが修正されています。
-特に、タイムスタンプの書き換え機能のバグが修正されているので、2.3, 2.3.1ユーザはなるべく早く
-2.3.2にアップグレードすることをお勧めします。
-</p>
-<p>
-また、2.3.2ではSSLサポート、ラージオブジェクトのレプリケーション機能が追加されています。
-</p>
-
-<h3>改良点</h3>
-<p>
-</p><ul>
- <li>フロントエンドとpgpool-II、pgpool-IIとPostgreSQLの間のSSL通信がサポートされました(Sean Finney)
- </li><li>ラージオブジェクトのレプリケーションがサポートされました(Tatsuo Ishii)
- </li><li>ヘルスチェックとオンラインリカバリの際に可能であればpostgresデータベースを使うようにしました。(Tatsuo Ishii)
-     <p>
-      postgresデータベースが存在しない場合はtemplate1が使われます(以前の動作と同じ)。
-      これにより、DROP DATABASEなどのコマンドがオンラインリカバリ中でも使えるようになりました。
-     </p>
- </li><li>問い合わせのパース処理でエラーが起きたときに、SQL文をログに出力するようにしました。(Tatsuo Ishii)
-     <p>
-     エンコーディングエラーなどが発生した際にはPostgreSQLのログにもSQL文が記録されないため、これは有効です。
-     </p>
- </li><li>kind mismatchエラーが発生し、その原因がDEALLOCATEコマンドだった場合にDEALLOCATEが削除しようとした
-     PREPARED文の元になったSQL文をログに出力するようにしました(Tatsuo Ishii)
-</li></ul>
-<p></p>
-
-<h3>バグ修正</h3>
-<p>
-</p><ul>
- <li>たまにタイムスタンプを書き換えた問い合わせがマスタ以外のDBノードに
-    不正なパケットを送ってしまう問題を修正しました(Tatsuo Ishii)
- </li><li>V2プロトコルでタイムスタンプの書き換え処理がエラーになるのを修正しました(Toshihiro Kitagawa)
- </li><li>master/slaveモード、かつトランザクション内で発行されるBind、Describe、Closeメッセージは
-     マスタだけに送るようにしました(Tatsuo Ishii)
- </li><li>2.3でsmart shutdownによりすぐに停止しなくなったバグを修正しました(Toshihiro Kitagawa)
- </li><li>フロントエンドからの不正なコマンドを受け付けないようにしました(Xavier Noguer)
- </li><li>移植性を高めるために、fprintfの引数に%dzを使用するようにしました(Tatsuo Ishii)
- </li><li>コンパイラワーニングを修正しました(Tatsuo Ishii)
- </li><li>master/slaveモードの際に、DEALLOCATEをすべてのノードに送らないようにして、
-     kind mismatchエラーを防ぐようにしました(Tatsuo Ishii)
-</li></ul>
-<p></p>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release2.3.1"></a>2.3.1 (tomiteboshi) 2009/12/18</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<p>
-このバージョンでは、2.3の色々なバグが修正されています。
-特に、ある条件でDBに不正な数値が書き込まれるバグが修正されており、
-以下の示す条件に合致する使い方をしている2.3ユーザは至急バージョンアップすることをお勧めします。
-</p>
-
-<h3>バグ修正と改良点</h3>
-<p>
-</p><ul>
- <li>以下のすべての条件に合致する場合、DBに不正な値が書き込まれるバグを修正しました(Tatsuo Ishii)
-      <p>
-      </p><ol>
-       <li>レプリケーションモードで動作
-       </li><li>64bit OS
-       </li><li>INSERTまたはUPDATEにおいて、now(), CURRENT_TIMESTAMP, CURRENT_DATE, CURRENT_TIMEを直接含むか、
-           テーブルのデフォルト値に含んでいる
-       </li><li>更にそのSQL内に32bit(10進で-2147483648から2147483647)の範囲を超える整数定数が含まれている
-      </li></ol>
-      以上を満たすSQLの例:
-<pre>INSERT INTO t1(id, regdate) VALUES(98887776655, NOW());
-</pre>
-      この例では、98887776655が32bit値にカットされて書き込まれます。
-      <p></p>
-
-  </li><li>18以上のDBノードを使用している場合に、show pool_statusでクラッシュするバグを修正しました。
-      このバグはshow pool_statusが実装されてからずっと存在していたものです。
-
-  </li><li>"kind mismatch"メッセージが出た際に、kindがERRORまたはNOTICEならば、
-      そのメッセージを表示するようにしました。(Tatsuo Ishii)
-      <p>
-      これにより、PostgreSQLのログを見なくてもkind mismatchエラーの原因を容易に調べることが
-      できるようになりました。
-      </p>
- </li></ul>
-<p></p>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2><a name="release2.3"></a>2.3 (tomiteboshi) 2009/12/07</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<p>このバージョンでは、レプリケーション機能に改良が加えられ、
-時刻データ(CURRENT_TIMESTAMP, CURRENT_DATE, now()など)を正しく扱うことができるようになりました。</p>
-<p>
-</p><p>また、同時接続数が1(num_init_childrenが1)のときのレプリケーション性能向上しています。</p>
-<p>また、pgpool-II再起動時に前回のDBノードのダウン状態を記録し、不用意に復旧ノードにデータを書き込んで
-データの不整合が起きることを防ぐことができるようになりました。</p>
-<p>そのほか、クエリログが改良されてDBノード単位の状況が把握しやすくなり、
-またフェイルオーバの挙動が細かく制御できるようになりました。</p>
-<p>なお、pgpool-II 2.3には、pgpool-II 2.2.1から2.2.6までのすべてのバグ修正、改良が含まれています。</p>
-<p></p>
-
-<h3>pgpool-II 2.2.からの非互換性</h3>
-<ul>
-<li>[logdir]の下にpgpool_statusというファイルが作られるので、pgpoolの実行ユーザが読み書きできる権限を
-    与えておいてください。
-</li></ul>
-
-<h3>改良点</h3>
-<ul>
-<li>レプリケーションにおいて、時刻データ(CURRENT_TIMESTAMP, CURRENT_DATE, now()など)を
-    正しく扱うことができるようになりました。(Akio Ishida)
-    <p>
-    特にアプリケーションに変更を加えることなく、INSERT/UPDATE文、テーブルのデフォルト値に
-    これらの時刻関数を含むケースでも正しくレプリケーションできます(いくつか制限事項があります。
-    詳細は<a href="#restriction">制限事項</a>を参照してください)。
-    </p>
-</li><li>SQLパーサをPostgreSQL 8.4のものにバージョンアップしました(Akio Ishida)
-</li><li>同時接続数が1（<a href="#NUM_INIT_CHILDREN">num_init_children</a> が1）のときの
-    レプリケーション性能が20%から100%向上しました(Tatsuo Ishii)
-</li><li>新しいディレクティブ <a href="#LOG_PER_NODE_STATEMENT">log_per_node_statement</a> が追加されました(Tatsuo Ishii)
-    <p>
-    <a href="#LOG_STATEMENT">log_statement</a> と似ていますが、DBノード単位でログが出力されるので、
-    レプリケーションや負荷分散の確認が容易です。
-    また、バックエンドのプロセスIDも表示されるので、バックエンドのログと併せての解析が容易になっています。
-    </p>
-</li><li>新しいディレクティブ <a href="#FAIL_OVER_ON_BACKEND_ERROR">fail_over_on_backend_error</a> が追加され、
-    フェイルオーバの挙動がより細かく制御できるようになりました(Tatsuo Ishii)
-</li><li>pgpool-II停止時にダウンしたDBノードの情報をステータスファイルに記録し、
-    pgpool-IIを起動したときにその情報をリストアできるようにしました(Tatsuo Ishii)
-ステータスファイルは [logdir]/pgpoo_status というファイルに書かれます。
-</li><li>EXPLAINと、問い合わせがSELECTのときのEXPLAIN ANALYZEが負荷分散されるようになりました。(Tatsuo Ishii)
-    <p>これによって、DBノードの間で大幅に問い合わせプランが異るために、
-    kind mismatchエラーが起きるのを防ぐことができます。</p>
-</li><li>日本語ドキュメントの体裁を改良しました(Tatsuo Ishii)
-</li><li>レプリケーションモード、マスタースレーブモード用のデフォルトpgpoo.conf.sampleが別途追加されました(Tatsuo Ishii)
-</li><li>時刻データのテストが追加されました(Akio Ishida)
-</li></ul>
-
-<!-- ================================================================================ -->
-<!-- 2.2                                                                              -->
-<!-- ================================================================================ -->
-<hr><a name="release2.2.x"></a>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2>2.2.8 (urukiboshi) 2012/08/06</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<p>このバージョンでは、2.2.7 のバグが修正されています。</p>
-
-<h3>バグ修正</h3>
-<ul>
-<li>
-do_error_execute_command() が ErrorResponse を受け取るまでバックエンドからの結果を
-見ないように修正しました。 (Toshihiro Kitagawa)
-<p>
-ReadyForQuery のようなエラーでない結果をとっておき、pool_unread() で呼び出す
-必要があるためです。
-これは PHP PDO を使っているときに起こる可能性がありました。
-</p>
-</li>
-
-<li>
-SimpleForwardToFrontend() が、SELECT 実行中に bind エラーになったとき、
-select_in_transaction フラグと execute_select フラグををリセットするように修正しました。
-(Toshihiro Kitagawa)
-</li>
-
-<li>
-pcp_check_fd() のタイムアウト処理のバグを修正しました。 (Tatsuo Ishii)
-<p>これは以下で報告されました。</p>
-<blockquote>
-Subject: [Pgpool-general] question about pcp_check_fd<br>
-Date: Sun, 23 May 2010 18:21:41 -0500<br>
-To: pgpool <pgpool-general@pgfoundry.org>
-</blockquote>
-</li>
-
-<li>pcp パスワードが 32 文字以上のときに、バッファオーバーランするのを修正しました。(Tatsuo Ishii)</li>
-
-<li>
-wait_for_query_response() が、frontend がないときには何もしないように修正しました。(Tatsuo Ishii)
-<p>
-バックエンドをリセットする reset_query_list のクエリを実行に 時間がかかったときに
-発生する可能性があり、またクラッシュすることがありました。
-</p>
-</li>
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2>2.2.7 (urukiboshi) 2010/04/15</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<p>
-このバージョンでは、kind mismatchエラーが起きた際のエラーメッセージが改善されています。
-また、2.2.6以前の色々なバグが修正されています。
-</p>
-<h3>バグ修正</h3>
-<ul>
-<li>マスター／スレーブモード、rawモード、またはコネクションプールモードにおいて、拡張プロトコルを使用している際に時々ハングアップするバグを修正しました。これは、2.3系からのバックパッチです(Kitagawa)
-<li>pgpool子プロセスがsegfaultを起こすpgpool-II 1.0から長い間存在したバグを修正しました。
-これは、親プロセスがshmemサイズの計算を間違えていたことに起因します。バグ解析(Kitagawa)、パッチ作成(Tatsuo)
-<li>マスター／スレーブモードにおいて、明示的なトランザクションで操作した場合は、Parse、Bind、Describe、そしてCloseメッセージをマスターノードのみに送るようにしました(Tatsuo)
-<li>postmasterが終了する際に、ログを出力するようにしました(Tatsuo)
-<li>make_persistent_db_connection関数のメモリリークを修正しました(Xavier Noguer)
-<li>マスター／スレーブモードでは、DEALLOCATEの強制的なレプリケーションをしないようにしました。
-pgpoolはParseをすべてのノードで実行しないため、これは無意味で問題(DEALLOCATE実行時のkind mismatch)を引き起こしていました(Tatsuo)
-<li>18より多いDBノードでshow pool_statusを実行したときにクラッシュするバグを修正しました(Tatsuo)
-<li>kind mismatchメッセージを改善しました。kindがERROR、またはNOTICEの場合は、何が起きているかユーザーがわかりやすいようにERROR/NOTICEメッセージを出力します(Tatsuo)
-</ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2>2.2.6 (urukiboshi) 2009/12/01</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<p>
-このバージョンでは、ロードバランスの重みパラメータweightの扱いが改善され、
-また一時テーブルがマスター／スレーブモードで利用できるようになりました。
-もちろんいつものように2.2.5以前の色々なバグが修正されています。
-</p>
-<h3>バグ修正</h3>
-<ul>
-<li>DECLARE, CLOSE, FETCH, MOVEがロードバランスの対象にならなくなりました。(Tatsuo Ishii)
-    <p>
-    もしデータが更新され、トランザクションがコミットされた後にCLOSEが発行されるとデータの一貫性がなくなるからです
-    (つまり、holdできるカーソルの場合のことを言っています)
-    </p>
-</li><li>マスター／スレーブモードにおいて、拡張プロトコルのParseをマスター上でのみ実行するようにしました。(Tatsuo Ishii)
-    <p>以前はすべてのノードでParseが実行されていたのですが、これだと
-    不必要なロックがスレーブでも取られてしまいます</p>
-</li><li>uninstallの前にすべてのランレベルからinitスクリプトを削除するようにしました(Devrim)
-</li><li>認証に失敗したときに適切なエラーメッセージを出すようにしました(Glyn Astill)
-</li><li>ソケットへの書き込みに失敗したときにフロントエンド用なのかバックエンド用なのかわかるようにしました(Tatsuo Ishii)
-</li><li>フロントエンド用のソケットに書き込み失敗したときにいちいちエラーを出さないようにしました(Tatsuo Ishii)
-</li><li>マスター／スレーブモードで一時テーブルが使えるようになりました。(Tatsuo Ishii)
-    <p>
-    INSERT/UPDATE/DELETEは自動的にマスタのみに送られます。SELECTに関しては明示的にクエリの前に
-    /*NO LOAD BALANCE*/というコメントを付けなければなりません。
-    </p>
-</li></ul>
-<p></p>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2>2.2.5 (urukiboshi) 2009/10/4</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<p>
-このバージョンでは、2.2.4以前の色々なバグが修正されています。
-</p>
-<h3>バグ修正</h3>
-<ul>
-<li>コネクション数のカウントのミスにより、オンラインリカバリが終わらなくなるバグを修正しました(Tatsuo Ishii)
-</li><li>内部的にロックを発行する際にもフロントエンドが異常終了したことを検出して
-    SQLコマンドをキャンセルするようにしました(Tatsuo Ishii)
-</li><li>接続の終了処理で無限ループに陥ることがあるバグを修正しました(Xavier Noguer, Tatsuo Ishii)
-</li><li>拡張プロトコルのパース処理でkind mismatch errorが起きた際に正しいSQL文を表示するようにしました(Tatsuo Ishii)
-</li><li>ドキュメントを改善しました(Tatsuo Ishii)
-</li></ul>
-<p></p>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2>2.2.4 (urukiboshi) 2009/8/24</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<p>
-このバージョンでは、2.2.3以前の色々なバグが修正されています。
-</p>
-<h3>バグ修正</h3>
-<ul>
- <li>pgpool-II 2.2.2で入ってしまったバグを修正しました。(Tatsuo Ishii)
-    <p>フロントエンドがアボートするタイミングによっては、以後内部状態がリセットされず、
-    次のセッションでDMLやDDLがマスターノードのみ送られ、
-    ノード間でデータの不一致が生じることがありました。</p>
- </li><li>pgpool-II 2.2.3でバージョン2プロトコルのクライアントが動かなくなってしまっていたのを修正しました。(Tatsuo Ishii)
-     <p>
-     また、時間のかかるクエリを待っている間にフロントエンドが異常終了したことを検知する間隔を
-     1秒から30秒に変更しました。このチェックは、2.2.4ではプロトコルバージョンが3のときのみ有効です。
-     </p>
- </li><li>子プロセスを起動する前にシグナルのブロックやハンドラの設定を行なうようにしました。(Tatsuo Ishii)
-    <p>これは、pgpool-IIを起動した直後にフェイルオーバなどの事象が発生して
-    子プロセスから親プロセスにシグナルが送られると、pgpool-IIの親プロセスが死んでしまうことがあるからです。</p>
-</li></ul>
-<p></p>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2>2.2.3 (urukiboshi) 2009/8/11</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<p>
-このバージョンでは、2.2.2以前の色々なバグが修正されています。
-</p>
-<h3>バグ修正</h3>
-<ul>
- <li>バックエンドに新しいコネクションを張る際に、バックエンドの一つが障害を起しているケースで、
-    後処理の中でpgpool-IIの子プロセスが落ちることがあるバグを修正しました(Tatsuo Ishii)
- </li><li>パラレルクエリのバグを修正しました(Yoshiharu Mori)
- </li><li>拡張プロトコルの場合にもエラーメッセージの中で最後に使用したクエリが
-     表示できるようになりました(Akio Ishida)
- </li><li>kind mismatch errorメッセージの作成で、メッセージ内容が壊れることがあるバグを修正しました(Tatsuo Ishii, Akio Ishida)
- </li><li>バックエンドへの接続記述子の参照タイミングによってはpgpool-IIの子プロセスが
-     落ちることがあるバグを修正しました(Tatsuo Ishii)。
- </li><li>pool_errorやpool_logの引数が間違っていた個所を修正しました(Akio Ishida)。
- </li><li>statement_timeoutのタイムアウトによるエラー処理を改良しました。(Tatsuo Ishii)
-     <p>
-     実際にはタイムアウトまでにstatement_timeoutで設定した時間の倍かかっていたのを直しました。
-     また、masterだけがstatement_timeoutを返した場合にも対応できるようにしました。
-     以前はkind mismatchエラーになっていました
-    (master以外がstatement_timeoutを返さないケースではkind mismatchエラーになります)。
-    </p>
-
- </li><li>health checkをより強化し、postmasterがSIGSTOPで止ってしまっている場合も障害検知できるようにしました。
-
- </li><li>バックエンドにSQLを投げ、その応答を待っている間にクライアントがpgpoolに対するコネクションを
-     切断したことが検出できるようになりました。(Tatsuo Ishii)
-    <p>たとえば、WebアプリケーションではDBに対してリクエストを投げて、
-    応答がないとキャンセルするようなことが頻繁に起ります。
-    この場合、今まではpgpoolやPostgreSQLのプロセスが残ってしまい、同時接続数が枯渇したり、
-    ロックを取ったままのトランザクションが残るなどしてシステム全体に影響を与えることがありました。</p>
-    <p>今回の修正により、こうした状況が検出できるようになっただけでなく、
-    SQLの応答待ちの間にクライアントがコネクションを切断した際には、
-    SQLコマンドのキャンセルをpgpoolが行なって、ロック待ちなどのバックエンドプロセスが残るのを
-    防ぐことができるようになりました。</p>
-
-</li><li>引数なしのCLUSTERコマンドはトランザクションの中では実行できないので、
-    自動トランザクションをスタートしないようにしました(Tatsuo Ishii)。
-
-</li><li>複数のプリペアドステートメントを使っている際に、セッションの終りで
-    その一部だけが解放されるバグを修正しました(Akio Ishida)。
-
-</li><li>sql/pgpool-recovery/pgpool-recovery.cがPostgreSQL 8.4でコンパイルできるようにしました(Tatsuo Ishii)。
-
-</li><li>拡張プロトコルを使っている場合に、クライアントとpgpoolの間でお互いに
-    待ち状態になってしまうことがあるバグを修正しました(Gavin Sherry)。
-
-</li><li>COPY FROMを実行中にクライアントが処理を中断した場合に、バックエンドプロセスが
-    残ってしまうバグを修正しました(Tatsuo Ishii)。
-
-</li></ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2>2.2.2 (urukiboshi) 2009/5/5</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<p>
-このバージョンでは、2.2.1以前の色々なバグが修正されています。
-とりわけ、pgpoolがクライアントとの間でデータのやり取りをしている最中に、
-pgpoolのクライアントが終了(X)パケットをpgpoolに送信せずに終了した場合に起る可能性があります。
-このバグは過去のすべてのpgpoolに存在しています。
-</p>
-<h3>バグ修正</h3>
-<ul>
-  <li>フロントエンドにpgpoolがデータを送信する際のエラーを無視するようにしました。(Tatsuo Ishii)
-      <p>これによって、バックエンドとの間で必要な処理が中断されないようになり、
-      バックエンドの間でデータの一貫性がなくなる問題が回避されるようになりました。</p>
-
-  </li><li>マスタースレーブモードに関する2.2.1の修正の際に生じたバグを修正しました。
-      プリペアドステートメントを使い回すとハングアップする可能性がありました(Toshihiro Kitagawa)。
-
-  </li><li>SQLコマンドのPREPAREとプロトコルレベルのEXECUTEが混在するとバックエンドがクラッシュする
-      バグを修正しました。このバグが、2.2で持ち込まれたものです(Tatsuo Ishii)。
-
-  </li><li>コネクションのリセット用の問合わせを実行中にエラーが起きた場合に、
-      PostgreSQLのログに"unexpected EOF on client connection"が記録される問題を修正しました(Tatsuo Ishii)。
-</li></ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2>2.2.1 (urukiboshi) 2009/4/25</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<p>
-このバージョンでは、2.2の色々なバグが修正されています。
-</p>
-<h3>バグ修正</h3>
-<ul>
-  <li>master/slaveモードで、DEALLOCATEが失敗することがある問題を修正しました。
-     これは、最初のPREPAREがslaveで実行されないことによるものです(Toshihiro Kitagawa)
-
-  </li><li>pgpool.specなどを2.2対応にしました(Devrim)
-
-  </li><li>Version 2プロトコルではinsert_lockが無視されるようにしました(Tatsuo Ishii)
-
-  </li><li>パラメータ変更メッセージがバックエンドから届く度にログが出力されるのを止めました(Tatsuo Ishii)
-
-  </li><li>ドキュメントで追加し忘れたファイルを登録しました(Tatsuo Ishii)
-</li></ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2>2.2 (urukiboshi) 2009/2/28</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>概要</h3>
-<p>
-このバージョンでは、SERIALデータの扱いとオンラインリカバリに改良が行なわれています。
-また、トランザクション分離レベルがシリアライザブルの場合に、DBノード間でデータの一貫性がなくなる可能性がある問題、
-クエリのキャンセルができない問題が修正されました。
-</p>
-
-<h3>新機能</h3>
-<p>
-</p><ul>
-<li><a href="#INSERT_LOCK">insert_lock</a> が有効な場合、SERIAL型を持つテーブルだけが
-    ロックされるようになりました(Tatsuo Ishii)。
-</li><li>設定項目 <a href="#CLIENT_IDLE_LIMIT_IN_RECOVERY">client_idle_limit_in_recovery</a>  が追加されました。(Tatsuo Ishii)
-    <p>
-    オンラインリカバリの第2ステージでクライアントがアイドルのまま居座ることによって、
-    オンラインリカバリが進行しなくなることを防ぐことができます。
-    </p>
-</li><li>設定項目 <a href="#PID_FILE_NAME">pid_file_name</a> が追加されました。(Tatsuo Ishii)
-    <p>
-    これは、pgpool-IIのpidファイルを指定します。
-    これにより、<a href="#LOGDIR">logdir</a> は使用されなくなりました。
-    </p>
-</li><li>DECLARE, FETCH, CLOSEで負荷分散されるようになりました(Tatsuo Ishii)。
-</li><li>pcpコマンドにデバッグオプション(-d)が追加されました(Jun Kuriyama)。
-</li><li>"kind mismatch"エラーの際に、原因となったクエリを表示するようにしました(Tatsuo Ishii)。
-</li></ul>
-<p></p>
-
-<h3>互換性</h3>
-<ul>
-  <li>フェイルオーバ時に必ずpgpoolの子プロセスを再起動するようにしました。(Tatsuo Ishii)
-      <p>
-       この結果、フェイルオーバ時には必ずpgpoolへのセッションが一端切れることになります。
-       こうしないと、ネットワークケーブル抜けなどの際に、
-       TCP/IPのレイヤで再送が行なわれ、長い時間そのままになってしまうことが
-       あるからです。
-      </p>
-  </li><li>設定項目 <a href="#LOGDIR">logdir</a> は使われなくなりました。
-      代りに、<a href="#PID_FILE_NAME">pid_file_name</a> を使ってください(Tatsuo Ishii)。
-
-  </li><li><a href="#INSERT_LOCK">insert_lock</a> のデフォルト値がtrueになりました(Tatsuo Ishii)。
-</li></ul>
-
-<h3>バグ修正</h3>
-<ul>
-  <li> pgpoolがデーモンモードで起動される際に、すべてのファイルディスクリプタを
-       閉じるようにしました。こうしないと、pgpoolAdminから起動された際に
-       apacheのソケットファイルを引き継いでしまい、80番ポートが
-       専有されてしまいます(Akio Ishida)。
-  </li><li> トランザクションをシリアライズできないエラーが発生したときに、
-       すべてのDBノードのトランザクションをアボートするようにしました。
-       こうしないと、DBノードの間でデータの不整合が起きることがあります(Tatsuo Ishii)。
-       例を示します(Mはマスタ、Sはスレーブを示します)。
-<pre>M:S1:BEGIN;
-M:S2:BEGIN;
-S:S1:BEGIN;
-S:S2:BEGIN;
-M:S1:SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
-M:S2:SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
-S:S1:SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
-S:S2:SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
-M:S1:UPDATE t1 SET i = i + 1;
-S:S1:UPDATE t1 SET i = i + 1;
-M:S2:UPDATE t1 SET i = i + 1; &lt;-- blocked
-S:S1:COMMIT;
-M:S1:COMMIT;
-M:S2:ERROR:  could not serialize access due to concurrent update
-S:S2:UPDATE t1 SET i = i + 1; &lt;-- success in UPDATE and data becomes inconsistent!
-</pre>
-
- </li><li> rawモードでMD5認証が使えるようにしました。ドキュメント上では使えるはずでした(Tatsuo Ishii)。
-
- </li><li> "SET TRANSACTION ISOLATION LEVEL must be called before any query"の
-       エラーが発生した場合に"kind mimatch"エラーになることを防ぐようにしました(Tatsuo Ishii)。
-       以下のシナリオで問題が発生します。
-<pre>M:S1:BEGIN;
-S:S1:BEGIN;
-M:S1:SELECT 1; &lt;-- only sent to MASTER
-M:S1:SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
-S:S1:SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
-M: &lt;-- error
-S: &lt;-- ok since no previous SELECT is sent. kind mismatch error occurs!
-</pre>
-
-</li><li>FreeBSDにおいて、psでのprocess statusの表示で余計なスペースが含まれてしまうのを修正しました(Jun Kuriyama)
-
-</li><li>BEGIN;を2度続けるとkind mismatch errorが発生するのを修正しました(Tatsuo Ishii)
-
-</li><li>PostgreSQLがたくさんのDEBUGメッセージを出力する場合に、誤ってエラーと見なすバグを修正しました(Tatsuo Ishii)
-
-</li><li>クエリのキャンセルが動くようになりました(Tatsuo Ishii)
-
-</li><li>オンラインリカバリの後クライアントからの接続を受け付けるタイミングが早すぎるバグを修正しました。
-このバグにより、ノードデータの貫性が保たれない可能性がありました(Tatsuo Ishii)
-
-</li><li>SELECT, INSERT, UPDATE, DELETE以外のコマンドでも
-    必要ならばトランザクションブロックの内側で実行するようにしました。
-    これにより、エラー発生の際にロールバックしてノードの整合性を保つことができます(Tatsuo Ishii)
-
-</li><li>オンラインリカバリ後、pgpool-IIの子プロセスがクラッシュすることがあるバグを修正しました。(Tatsuo Ishii)
-    <p>これは、オンラインリカバリの後、新しくアタッチされたノードに接続がないのに、
-    そのノードに子プロセスが終了時に終了メッセージをバックエンドに送信しようとして起っていました。</p>
-
-</li><li>PostgreSQLがpostgresql.confを再読み込みした際にpgpoolがエラーを検出してしまうバグを修正しました。(Tatsuo Ishii)
-    <p>これは、PostgreSQLが（たぶん）ドキュメントに書かれていないタイミングで
-    「パラメータ変更」パケットを送信してくるために起り、修正はそのことに対応したものです。</p>
-
-</li></ul>
-
-<!-- ================================================================================ -->
-<!-- 2.1                                                                              -->
-<!-- ================================================================================ -->
-<hr><a name="release2.1.x"></a>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2>2.1 (inamiboshi) 2008/7/25</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>新機能</h3>
-<ul>
-  <li><a href="#FAILOVER_COMMAND">failover_command</a> と
-      <a href="#FAILBACK_COMMAND">failback_command</a> に、新しいマスタノード ID
-      を表す '%m' をサポートしました。(Yoshiyuki Asaba)
-  </li><li><a href="#FAILOVER_COMMAND">failover_command</a> と
-      <a href="#FAILBACK_COMMAND">failback_command</a> に、古いマスタノード ID を
-      表す '%M' をサポートしました。(Yoshiyuki Asaba)
-  </li><li>リカバリのタイムアウト時間を指定する <a href="#RECOVERY_TIMEOUT">recovery_timeout</a>
-      パラメータを追加しました。(Taiki Yamaguchi)
-  </li><li> pg_md5 コマンドに -p オプションを追加しました。(Volkan Yazici,
-  Taiki Yanaguchi)
-  </li><li> pgpool -v を実行するとバージョン番号を表示し、終了するようにし
-  ました。(Yoshiyuki Asaba)
-</li></ul>
-
-<h3>互換性</h3>
-<ul>
-  <li><a href="#pgpool_recovery">pgpool_recovery</a> と
-      <a href="#pgpool_remote_start">pgpool_remote_start</a> 関数はスーパーユーザのみ
-      実行できるように権限チェックを強化しました。(Yoshiyuki Asaba)
-  </li><li> raw モードでスタンバイノードにはコネクションプールを作成しないようにしました。(Yoshiyuki Asaba)
-  </li><li> replication_timeout パラメータを削除しました。(Yoshiyuki Asaba)
-  </li><li> PCP クライアントコマンドのタイムアウトを無効にしました。(Taiki Yamaguchi)
-  </li><li> replicate_select = false の場合に、COPY TO STDOUT をレプリケー
-  ションさせないようにしました。(Yoshiyuki Asaba)
-</li></ul>
-
-<h3>修正</h3>
-<h4> 全般 </h4>
-<ul>
-  <li> CloseComplete メッセージを受けとるとクラッシュする不具合を修正
-  しました。(Yoshiyuki Asaba)
-  </li><li> メッセージ転送処理を効率よくしました。(Yoshiyuki Asaba)
-  </li><li> Solaris 10 でコンパイルできるようにしました。(Yoshiyuki Asaba)
-  </li><li> ヘルスチェックとリカバリのログ出力を改良しました。(Tatsuo Ishii)
-  </li><li> 様々なメモリリークを修正しました。(Yoshiyuki Asaba)
-  </li><li> "failed to read kind from frontend" というエラーメッセージを
-  ERRORレベルから LOG レベルに下げました。(Yoshiyuki Asaba)
-  </li><li> raw モードでフェイルオーバに失敗する不具合を修正しました。
-  (Taiki Yamaguchi)
-  </li><li> 不正なノードを追加・切り離しを行うとゾンビプロセスが発生する不
-  具合を修正しました。(Yoshiyuki Asaba)
-  </li><li> <a href="#HEALTH_CHECK_TIMEOUT">health_check_timeout</a> が正しく動作しない不具合を修正しました。
-  (Kenichi Sawada)
-  </li><li> FreeBSD で ps コマンドの出力が正しくない不具合を修正しました。
-  (ISHIDA Akio)
-  </li><li> Unix domain ソケットが残っている場合のエラーメッセージを強化し
-  ました。(Jun Kuriyama)
-  </li><li> 認証に失敗した場合のエラーメッセージを強化しました。(Tatsuo Ishii)
-</li></ul>
-
-<h4>レプリケーション</h4>
-<ul>
-  <li> <a href="#REPLICATE_SELECT">replicate_select</a> を設定しても、常に false の挙動になる不具合を
-  修正しました。(Tatsuo Ishii)
-  </li><li> 拡張問い合わせプロトコルを使っていると、トランザクションを誤ってロー
-  ルバックしてしまう不具合を修正しました。(Yoshiyuki Asaba)
-  </li><li> 非同期クエリを使っていると pgpool が不安定になる不具合を修正し
-  ました。(Yoshiyuki Asaba)
-  </li><li> 拡張問合せプロトコルを使うと /* REPLICATION */などのヒント句が消えて
-  しまう不具合を修正しました。(Yoshiyuki Asaba)
-  </li><li> DEALLOCATE ALL を実行するとクラッシュする不具合を修正しました。
-  (Yoshiyuki Asaba)
-  </li><li> immediate shutdown するとハングアップする不具合を修正しました。
-  (Yoshiyuki Asaba)
-  </li><li> 高負荷時にオンラインリカバリを実施すると、リカバリプロセスがハ
-  ングアップする可能性のある不具合を修正しました。(Yoshiyuki Asaba)
-  </li><li> 拡張問合せプロトコルを使って SELECT を実行した際に、トランザク
-  ションブロック内でクエリがエラーになると、pgpool がハングアップする
-  可能性のある不具合を修正しました。(Yoshiyuki Asaba)
-</li></ul>
-
-<h4>マスタースレーブ</h4>
-<ul>
-  <li> トランザクションブロック内で、SET, PREPARE, DEALLOCATE を実行す
-  ると、プロセスがダウンする不具合を修正しました。(Yoshiyuki Asaba)
-  </li><li> マスタースレーブモードでロードバランスが正しく動作していない不
-  具合を修正しました。(Yoshiyuki Asaba)
-</li></ul>
-
-<h4>パラレルクエリ</h4>
-<ul>
-  <li> INSERT に失敗する不具合を修正しました。(Yoshiharu Mori)
-  </li><li> FROM 句に AS が含まれると構文エラーになる不具合を修正しました。(sho)
-  </li><li> クエリを複数回実行するとハングアップする不具合を修正しました。(Yoshiharu Mori)
-  </li><li> JOIN に失敗する不具合を修正しました。(Yoshiharu Mori)
-  </li><li> DISTINCT構文 の解析に失敗する不具合を修正しました。(Yoshiharu Mori)
-</li></ul>
-
-<!-- ================================================================================ -->
-<!-- 2.0                                                                              -->
-<!-- ================================================================================ -->
-<hr><a name="release2.0.x"></a>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2>2.0.1 (hikitsuboshi) 2007/11/21</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<ul>
-  <li> UPDATE もしくは DELETE を実行するとプロセスがダウンする不具合を
-       修正しました。(Yoshiyuki Asaba)
-  </li><li> <a href="#MASTER_SLAVE_MODE">master_slave</a> を true に設定している場合に、SQL 構文エラーを検知
-       した時にマスタにのみそのクエリを送信するようにしました。(Yoshiyuki Asaba)
-</li></ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2>2.0 (hikitsuboshi) 2007/11/16</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<h3>互換性</h3>
-<ul>
-  <li> <a href="#IGNORE_LEADING_WHITE_SPACE">ignore_leading_white_space</a> のデフォルト値を true にしました。
-  (Yoshiyuki Asaba)
-  </li><li> replicate_strict を廃止しました。常に replicate_strict が true
-  の挙動になります。(Yoshiyuki Asaba)
-</li></ul>
-
-<h3>全般</h3>
-<ul>
-  <li> pgpool.conf をリロードできるようにしました。リロード時に分散ルールも同時にリロードします。(Yoshiyuki Asaba)
-  </li><li> SQL パーサを PostgreSQL 8.3 に対応しました。(Yoshiyuki Asaba)
-  </li><li> ノードを切り離した際にユーザが設定したコマンドを実行できるよう
-  に、pgpool.conf に <a href="#FAILOVER_COMMAND">failover_command</a> というパラメータを追加しました。
-  (Yoshiyuki Asaba)
-  </li><li> ノードを復帰した際にユーザが設定したコマンドを実行できるように、
-  pgpool.conf に <a href="#FAILBACK_COMMAND">failback_command</a> というパラメータを追加しました。
-  (Yoshiyuki Asaba)
-  </li><li> pgpool.conf に <a href="#CLIENT_IDLE_LIMIT">client_idle_limit</a> というパラメータを追加しました。
-  このパラメータではクライアントからのクエリの最大待ち時間を設定することができます。(Tatsuo Ishii)
-</li></ul>
-
-<h3>レプリケーション</h3>
-<ul>
-  <li> トランザクションブロックに囲まれていないクエリをレプリケーションさせる場合、
-      内部的にトランザクションを開始させるようにしました。(Yoshiyuki Asaba)
-  </li><li> レプリケーションを高速化させるようにしました。(Yoshiyuki Asaba)
-  </li><li> ノードを再同期させて復帰させる、オンラインリカバリ機能を実装し
-  ました。(Yoshiyuki Asaba)
-  </li><li> INSERT, UPDATE, DELETE した行数がすべて一致しなかった場合に、
-      トランザクションをアボートさせるようにしました。(Yoshiyuki Asaba)
-<pre>x=# update t set a = a + 1;
-ERROR:  pgpool detected difference of the number of update tuples
-HINT:  check data consistency between master and other db node
-</pre>
-  </li><li> 複数のバックエンドから異なる結果が返ってきた場合に、同じ結果が
-      多数返ってきた結果を信頼する多数決方式を実装しました。(Yoshiyuki Asaba)
-  </li><li> V2 問合せプロトコルでロードバランスできるようにしました。(Yoshiyuki Asaba)
-</li></ul>
-
-<h3>パラレルクエリ</h3>
-<ul>
-  <li> パラレルモードで部分レプリケーションをサポートしました。(Yoshiharu Mori)
-</li></ul>
-
-<!-- ================================================================================ -->
-<!-- 1.3                                                                              -->
-<!-- ================================================================================ -->
-<hr><a name="release1.3.x"></a>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2>1.3 (sohiboshi) 2007/10/23</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<ul>
-  <li> 新しく <a href="AUTHENTICATION_TIMEOUT">authentication_timeout</a> という
-       パラメータを追加しました。(Yoshiyuki Asaba)
-    <ul>
-     <li>このパラメータでは認証時間のタイムアウトを設定します。
-     </li><li>デフォルト値は 60 (1 分)です。
-   </li></ul>
-  </li><li> スタートアップパケットの長さが 10000 バイト越えている場合には、接続を切断するようにしました。(Yoshiyuki Asaba)
-  </li><li> DEALLOCATE を実行するとまれに不正なメモリアクセスが発生する不具
-       合を修正しました。(Yoshiyuki Asaba)
-  </li><li> トランザクション内で SELECT を実行した後に SELECT を正しくロードバラ
-       ンスできない不具合を修正しました。(Yoshiyuki Asaba)
-       <ul>
-    <li> この不具合は 1.2 で混入した不具合です。
-       </li></ul>
-  </li><li> 64bit 環境でクエリキャッシュ機能を有効にすると、クラッシュする可能性のある不具合を修正しました(Yoshiyuki Asaba)
-</li></ul>
-
-<!-- ================================================================================ -->
-<!-- 1.2                                                                              -->
-<!-- ================================================================================ -->
-<hr><a name="release1.2.x"></a>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2>1.2.1 (tomoboshi) 2007/09/28</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<ul>
-  <li> 拡張問合せプロトコルの Parse メッセージの処理でデッドロックが発
-  生する可能性がある不具合を修正しました。(Yoshiyuki Asaba)
-
-  </li><li> Prepared statement を管理する領域がメモリリークしている不具合を
-  修正しました。(Yoshiyuki Asaba)
-
-  </li><li> 一部の OS でコンパイルエラーになる不具合を修正しました。(Yoshiyuki Asaba)
-
-  </li><li>master/slave モード内で SET, PREPARE, DEALLOCATE 文をレプリケーションさせるようにしました。(Yoshiyuki Asaba)
-</li></ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2>1.2 (tomoboshi) 2007/08/01</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<ul>
-  <li> pgpool.conf に <a href="#REPLICATE_SELECT">replicate_select</a> という新規パラメータを追加しま
-  した。デフォルト値は false です。(Yoshiyuki Asaba)
-  <ul>
-    <li> true に設定した場合は、ロードバランスされない SELECT 文をレプリケーションします
-        (pgpool-II 1.0 の挙動)。false の場合はマスタにのみ SELECT を送信します。
-  </li></ul>
-
-  </li><li> シグナル処理を安全に行うようにしました。(Yoshiyuki Asaba)
-  <ul>
-    <li>まれにゾンビプロセスが残ってしまったり、不安定になることがありました。
-  </li></ul>
-
-  </li><li> トランザクション中に SELECT 文がエラーになると、ハングアップしてしまう不具合を修正しました。(Yoshiyuki Asaba)
-  <ul>
-    <li> この不具合は 1.1 に入った不具合です。
-  </li></ul>
-
-  </li><li> PREPARE/EXECUTE が master/slave モードで正しく動作しない不具合
-  を修正しました。(Yoshiyuki Asaba)
-
-  </li><li> デッドロックを検知すると、kind mismatch error が発生する不具合
-  を修正しました。(Yoshiyuki Asaba)
-
-  </li><li> 拡張問い合わせプロトコルを使ったドライバを使用した場合に、
-       構文解析時に警告が発生する SQL 文を実行するとハングアップもしくは
-       プロセスがクラッシュする不具合を修正しました。(Yoshiyuki Asaba)
-
-  </li><li> コネクションキャッシュが一杯になるとメモリリークが発生する不具合を修正しました。(Yoshiyuki Asaba)
-
-  </li><li> セッションが残った状態で PostgreSQL を fast shutdown もしくは
-  immediate shutdown すると、残ったセッションがハングアップする不具合
-  を修正しました。(Yoshiyuki Asaba)
-
-  </li><li> ロードバランス先を接続開始時に決定し、同じセッション内ではすべ
-  て同じノードにクエリを送信するようにしました。(Yoshiyuki Asaba)
-
-  </li><li> <a href="#CONNECTION_LIFE_TIME">connection_life_time</a> を設定している場合に
-      バッファオーバランが発生する可能性がある不具合を修正しました。(Yoshiyuki Asaba)
-
-</li></ul>
-
-<!-- ================================================================================ -->
-<!-- 1.1                                                                              -->
-<!-- ================================================================================ -->
-<hr><a name="release1.1.x"></a>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2>1.1.1 (amiboshi) 2007/06/15</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<ul>
-  <li> <a href="#LOAD_BALANCE_MODE">load_balance_mode</a> を有効にしていると、"kind mismatch" エラーが
-  発生してしまう不具合を修正しました。これは 1.1 で入った不具合です。
-  (Yoshiyuki Asaba)
-  </li><li> プロトコルバージョン 2 を使ったドライバでレプリケーション使用す
-  ると、pgpool がハングアップする不具合を修正しました(Yoshiyuki Asaba)
-  </li><li> 拡張問合せプロトコルを使用すると、まれにデッドロックが発生する
-  不具合を修正しました(Yoshiyuki Asaba)
-</li></ul>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2>1.1 (amiboshi) 2007/05/25</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<ul>
-  <li> HBA 認証をサポートしました(Taiki Yamaguchi)
-  </li><li> <a href="#LOG_CONNECTIONS">log_connections</a> をサポートしました(Taiki Yamaguchi)
-  </li><li> <a href="#LOG_HOSTNAME">log_hostname</a> をサポートしました(Taiki Yamaguchi)
-  </li><li> ps コマンドで pgpool の状態がわかるようにしました(Taiki Yamaguchi)
-  </li><li> MacOS X でコンパイルエラーになる不具合を修正しました(Yoshiyuki Asaba)
-  </li><li> 拡張問い合わせプロトコルを使ったクエリをロードバランスできるようにしました(Yoshiyuki Asaba)
-  </li><li> レプリケーション設定時、SELECT は master にのみ送信するようにしました(Yoshiyuki Asaba)
-    <ul>
-      <li> もし SELECT をレプリケーションさせる場合は /*REPLICATION*/ のように
-          SELECT の前にコメントを付ける必要があります
-    </li></ul>
-  </li><li> レプリケーション設定時、SELECT nextval() および SELECT setval()
-      を自動的にレプリケーションさせるようにしました(Yoshiyuki Asaba)
-  </li><li> バックエンドへ接続中にシグナルに割り込まれると、フェイルオーバしてしまう不具合を修正しました(Yoshiyuki Asaba)
-  </li><li> PAM 認証のサンプルファイル pgpool.pam を $PREFIX/share/pgpool-II/ にインストールするようにしました(Taiki Yamaguchi)
-  </li><li> 巨大な SQL を実行しようとした場合に pgpool が無限ループに入る不具合を修正しました(Yoshiyuki Asaba)
-</li></ul>
-
-<!-- ================================================================================ -->
-<!-- 1.0                                                                              -->
-<!-- ================================================================================ -->
-<hr><a name="release1.0.x"></a>
-
-<!-- -------------------------------------------------------------------------------- -->
-<h2>1.0.2 (suboshi) 2007/02/13</h2>
-<!-- -------------------------------------------------------------------------------- -->
-<ul>
-  <li> 巨大な SQL を実行しようとした場合に pgpool が無限ループに入る不具合を修正しました(Yoshiyuki Asaba)
-  </li><li> 拡張問合せプロトコルを使った場合にまれに pgpool が止まってしまう不具合を修正しました(Yoshiyuki Asaba)
-  </li><li> フェイルオーバ、フェイルバック時のログ出力を改善しました(Tatsuo Ishii)
-  </li><li> <a href="#pool_status">SHOW pool_status</a> の結果にバックエンドステータス情報を追加しました(Tatsuo Ishii)
-  </li><li> レプリケーション時に UPDATE/DELETE の件数が実際の件数とは異なった結果を返す不具合を修正しました(Tatsuo Ishii)
-  </li><li> 古い gcc を使うと libpq のリンクに失敗する不具合を修正しました (Yoshiyuki Asaba)
-  </li><li> PHP:PDO や DBD-Pg を使った場合に、自動 DEALLOCATE が失敗してしまう不具合を修正しました(Yoshiyuki Asaba)
-  </li><li> SELECT FOR UPDATE, SELECT INTO をロードバランスさせないようにしました。
-      また、SELECT の前にコメントがある場合もロードバランスさせないようにしました。
-      これは pgpool-I との互換性のためです。(Yoshiyuki Asaba)
-  </li><li> configure 時の libpq のデフォルトパスを pg_config コマンドを使って取得するようにしました。
-      なお、--with-pgsql 関連のオプションは次のバージョンでは廃止予定です(Yoshiyuki Asaba)
-  </li><li> コネクションプール再利用時に、ソケットが壊れている場合は再接続するようにしました(Yoshiyuki Asaba)
-  </li><li> PostgreSQL 7.4.x の libpq を使ってビルドしようとすると、
-      configure スクリプトでエラーとなってしまう不具合を修正しました(Yoshiyuki Asaba)
-      <dl>
-      <dt>hoge</dt><dd>HOGE</dd>
-      <dt>hoge</dt><dd>HOGE</dd>
-      </dl>
-</li></ul>
-
-<!-- ================================================================================ -->
-
-</div>
-
-<div class="copyright" style="clear: both">
-<hr>
-<copyright>
-Copyright &copy; 2003 &ndash; 2015 pgpool Global Development Group
-</copyright>
-</div>
-
-</body>
-</html>
diff --git a/doc/pgpool-zh_cn.html b/doc/pgpool-zh_cn.html
deleted file mode 100755
index 17d378b64..000000000
--- a/doc/pgpool-zh_cn.html
+++ /dev/null
@@ -1,5256 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<html>
-<head>
-<meta http-equiv="content-type" content="text/html; charset=UTF-8">
-<link rel="stylesheet" href="./pgpool.css" type="text/css">
-<title>pgpool-II 用户手册</title>
-</head>
-
-<!-- hhmts start -->
-Last modified: Wed Jun 29 09:50:01 JST 2011
-<!-- hhmts end -->
-
-<body bgcolor="#ffffff">
-<div id="top" class="header_text">欢迎使用 pgpool-II 手册</div>
-
-<div id="menu">
-    <div id="navcontainer">
-      <ul id="navlist">
-        <li id="active"><a href="#Whatis" id="current">什么是 pgpool</a></li>
-        <li><a href="#license">许可协议</a></li>
-        <li><a href="#platform">支持的平台</a></li>
-        <li><a href="#install">pgpool-II 的安装</a></li>
-        <li><a href="#config">配置 pgpool-II</a></li>
-        <li><a href="#common">配置通用部分</a></li>
-        <li><a href="#connection_pool_mode">连接池模式</a></li>
-        <li><a href="#replication_mode">复制模式</a></li>
-        <li><a href="#master_slave_mode">主备模式</a></li>
-        <li><a href="#stream">流复制</a></li>
-        <li><a href="#hba">客户端认证</a></li>
-        <li><a href="#query_cache">设置查询缓存方法</a></li>
-        <li><a href="#memqcache">基于内存的查询缓存</a></li>
-        <li><a href="#start">启动/停止 pgpool-II</a></li>
-        <li><a href="#reload">重新加载 pgpool-II 配置文件</a></li>
-        <li><a href="#show-commands">显示命令</a></li>
-        <li><a href="#online-recovery">在线恢复</a></li>
-        <li><a href="#backup">备份</a></li>
-        <li><a href="#deploy">部署 pgpool-II</a></li>
-        <li><a href="#watchdog">看门狗</a></li>
-        <li><a href="#pcp_command">PCP 命令</a></li>
-        <li><a href="#pgpool_adm">pgpool_adm</a></li>
-        <li><a href="#troubleshooting">故障排除</a></li>
-        <li><a href="#restriction">限制</a></li>
-      </ul>
-    </div>
-     <br />
-
-    <div class="header_small" align="center">
-    [<a href="pgpool-en.html">英文页面</a>]
-    </div>
-</div>
-
-
-<div id="manual">
-
-<!-- ================================================================================ -->
-
-<h1 style="margin-top: 20px">什么是 pgpool-II?<a name="whatis"></a></h1>
-
-<p> pgpool-II 是一个位于 PostgreSQL 服务器和 PostgreSQL
-数据库客户端之间的中间件，它提供以下功能：</p>
-
-<p>
-<ul>
-
-<li>连接池</li>
-    <p>pgpool-II 保持已经连接到 PostgreSQL 服务器的连接，
-        并在使用相同参数（例如：用户名，数据库，协议版本）
-        连接进来时重用它们。
-        它减少了连接开销，并增加了系统的总体吞吐量。</p>
-
-<li>复制</li>
-    <p>pgpool-II 可以管理多个 PostgreSQL 服务器。
-        激活复制功能并使在2台或者更多 PostgreSQL
-        节点中建立一个实时备份成为可能，
-        这样，如果其中一台节点失效，服务可以不被中断继续运行。</p>
-
-<li>负载均衡</li>
-    <p>如果数据库进行了复制（可能运行在复制模式或者主备模式下），
-        则在任何一台服务器中执行一个 SELECT 查询将返回相同的结果。
-        pgpool-II 利用了复制的功能以降低每台 PostgreSQL 服务器的负载。
-        它通过分发 SELECT 查询到所有可用的服务器中，增强了系统的整体吞吐量。
-        在理想的情况下，读性能应该和 PostgreSQL 服务器的数量成正比。
-        负载均很功能在有大量用户同时执行很多只读查询的场景中工作的效果最好。</p>
-
-<li>限制超过限度的连接</li>
-    <p>PostgreSQL 会限制当前的最大连接数，当到达这个数量时，新的连接将被拒绝。
-        增加这个最大连接数会增加资源消耗并且对系统的全局性能有一定的负面影响。
-        pgpoo-II 也支持限制最大连接数，但它的做法是将连接放入队列，而不是立即返回一个错误。</p>
-
-</ul>
-</p>
-
-<p>pgpool-II 使用 PostgreSQL 的前后台程序之间的协议，并且在前后台之间传递消息。
-    因此，一个（前端的）数据库应用程序认为 pgpool-II 就是实际的 PostgreSQL 数据库，
-    而后端的服务进程则认为 pgpool-II 是它的一个客户端。
-    因为 pgpool-II 对于服务器和客户端来说是透明的，
-    现有的数据库应用程序基本上可以不需要修改就可以使用 pgpool-II 了。</p>
-
-<p>
-<strong>通过 pgpool-II 使用 SQL 有一些限制条件。参考 <a href="#restriction">限制</a> 获得详细信息。</strong>
-</p>
-
-<p class="top_link"><a href="#Top">返回顶部</a></p>
-
-<!-- ================================================================================ -->
-
-<h1>许可协议<a name="license"></a></h1>
-
-<p>版权所有 (c) 2003-2015 PgPool 全球开发小组</p>
-<p><br></p>
-<p>
-授权出于任何目的任意使用、拷贝、修改和分发本软件以及文档，
-但必须在所有软件拷贝的支持文档中提供以上的版权信息，包括版权通知和许可，
-并且在没有事先明确的书面授权前，作者的名字不能用于发布软件的广告和宣传。
-作者不对本软件的任何用途负责。
-本软件以“现状”来提供，不提供任何明文或暗示的保证。
-</p>
-
-<p class="top_link"><a href="#Top">返回顶部</a></p>
-
-<!-- ================================================================================ -->
-
-<h1>支持的平台<a name="platform"></a></h1>
-
-<p>pgpool-II 可以运行在 Linux，Solaris，FreeBSD 以及基本上所有的类 UNIX 架构的平台上。
-    不支持 Windows。支持 6.4 以上版本的 PostgreSQL 服务器。</p>
-
-<p>如果你在使用 7.3 或者更老版本的 PostgreSQL，一些 pgpool-II 的功能将无法使用。
-    但无论如何你不应该还在用这么老的版本了。</p>
-
-<p>你还要确保你所有的 PostgreSQL 服务器运行相同主版本号的 PostgreSQL 程序。另外，如果你想要使用在线恢复，硬件架构和操作系统必须一致。
-    另外，我们不推荐在使用不同编译参数编译的 PostgreSQL：包括是否支持 SSL，是否使用了 --disable-integer-datetimes 参数或者不同的块大小。
-    这些可能对 pgpool-II 的部分功能有影响。
-    通常情况下，小版本号不同没有什么影响。但是我们没有针对小版本的区别做全面测试，因此我们建议还是使用相同的版本的 PostgreSQL。</p>
-
-<p class="top_link"><a href="#Top">返回顶部</a></p>
-
-<!-- ================================================================================ -->
-
-<h1>pgpool-II 的安装<a name="install"></a></h1>
-
-<p>
-pgpool-II 可以在 <a href="http://pgpool.net/">pgpool 开发页面</a>下载到。
-而且也提供包括 CentOS，RedHat Enterprise Linux，Fedora 和 Debian 在内的大量平台的二进制包。
-请检查相关的软件库。
-</p>
-
-<p>
-可以在以下位置下载 pgpool-II 的源码：
-<a href="http://pgpool.net/mediawiki/index.php/Downloads">pgpool 开发页面</a>。
-</p>
-
-<p>从源码安装 pgpool-II 需要 2.9 甚至或更高版本的 gcc，以及 GNU make。
-    而且，pgpool-II 需要链接到 libpq 库，所以在构建 pgpool-II 的机器上必须安装 libpq 库和它的开发头文件。
-    另外，还需要 OpenSSL 库和它的头文件以便在 pgpool-II 中提供 OpenSSL 支持。</p>
-
-<h2 id="install_pgpool">Installing pgpool-II</h2>
-<dl>
-<dt>configure</dt>
-    <dd>
-    <p>在解压源码包后，执行以下配置脚本。</p>
-<pre>
-./configure
-</pre>
-
-    <p>如果你需要非默认的值，有以下选项可以设置：</p>
-    <table border>
-      <tr><th class="nodec"><code>--prefix=path</code></th>
-      <td>pgpool-II 的二进制程序和文档将被安装到这个目录。默认值为 <code>/usr/local</code></td></tr>
-      <tr><th class="nodec"><code>--with-pgsql=path</code></th>
-      <td>PostgreSQL 的客户端库安装的顶层目录。默认值由 <code>pg_config</code> 提供</td></tr>
-      <tr><th class="nodec"><code>--with-openssl</code></th>
-      <td>pgpool-II 程序将提供 OpenSSL 支持。默认是禁用 OpenSSL 支持的。<span class="version">V2.3 -</span></td></tr>
-      <tr><th class="nodec"><code>--enable-sequence-lock</code></th>
-      <td>在 pgpool-II 3.0 系列中使用 insert_lock 兼容。pgpool-II 针对序列表中的一行进行加锁。PostgreSQL 8.2 或2011年六月以后发布的版本无法使用这种加锁方法。
-          <span class="version">V3.1 -</span></td></tr>
-      <tr><th class="nodec"><code>--enable-table-lock</code></th>
-      <td>在 pgpool-II 2.2 和 2.3 系列中使用 insert_lock 兼容。pgpool-II 针对被插入的表进行加锁。这种锁因为和 VACUUM 冲突，已被废弃。<span class="version">V3.1 -</span></td></tr>
-      <tr><th class="nodec"><code>--with-memcached=path</code></th>
-      <td>pgpool-II 的二进制程序将使用 <a href="#memcached_params">memcached</a> 作为 <a href="#memqcache">基于内存的查询缓存</a>。你必须先安装 <a href="http://libmemcached.org/libMemcached.html">libmemcached</a>。
-          <span class="version">V3.2 -</span></td>
-      </tr>
-      </table>
-    </dd>
-
-<dt>make</dt>
-    <dd>
-<pre>
-make
-make install
-</pre>
-    <p>
-    这将安装 install pgpool-II. （如果你使用的是 Solaris 或 FreeBSD，需要用 gmake 替换 make ）
-    </p>
-    </dd>
-</dl>
-
-<h2 id="install_functions">安装必须的函数</h2>
-
-<h3>安装 pgpool_regclass （推荐）<span class="version">V3.0 -</span></h3>
-<p>
-如果你在使用 PostgreSQL 8.0 或之后的版本，强烈推荐在需要访问的 PostgreSQL
-中安装 pgpool_regclass 函数，因为它被 pgpool-II 内部使用。
-如果不这样做，在不同的 schema 中处理相同的表名会出现问题（临时表不会出问题）。
-</p>
-
-<pre>
-$ cd pgpool-II-x.x.x/sql/pgpool-regclass
-$ make
-$ make install
-</pre>
-
-<p>在这之后：<p>
-<pre>
-$ psql -f pgpool-regclass.sql template1
-</pre>
-
-<p>或者<p>
-
-<pre>
-$ psql template1
-=# CREATE EXTENSION pgpool_regclass;
-</pre>
-</p>
-<p>
-应在每台通过 pgpool-II 访问的数据库中执行 pgpool-regclass.sql 或者 CREATE EXTENSION。
-你不需要在你执行“psql -f pgpool-regclass.sql template1” 或者 CREATE EXTENSION 后建立的数据库中这么做，
-因为这个模板数据库将被克隆成新建的数据库。
-</p>
-
-<h3>建立 insert_lock 表<span class="version">V3.0 -</span></h3>
-<p>
-如果你在复制模式中使用了 insert_lock ，强烈推荐建立 pgpool_catalog.insert_lock 表，用于互斥。
-到现在为止，insert_lock 还能够工作。但是，在这种情况下，pgpool-II 需要锁定插入的目标表。
-这种行为和 pgpool-II 2.2 和 2.3 系列类似。由于表锁与 VACUUM 冲突，所以 INSERT 操作可能因而等待很长时间。
-</p>
-
-<pre>
-$ cd pgpool-II-x.x.x/sql
-$ psql -f insert_lock.sql template1
-</pre>
-
-<p>
-应在在每台通过 pgpool-II 访问的数据库中执行 insert_lock.sql。
-你不需要在你执行“<code>psql -f insert_lock.sql template1</code>”后建立的数据库中这么做，
-因为这个模板数据库将被克隆成新建的数据库。
-</p>
-
-<h3>安装 pgpool_recovery</h3>
-
-<p>如果你使用 <a href="#online_recovery_in_stream_mode">在线回复</a>，需要以下一些函数：
-pgpool_recovery, pgpool_remote_start, pgpool_switch_xlog。</p>
-<p>另外，附带工具pgpoolAdmin 控制 pgpool-II 启停和重新连接后端的 PostgreSQL 节点，
-它需要函数 pgpool_pgctl。</p>
-<p>
-而且 pgpoolAdmin 需要函数 pgpool_pgctl 来对 PostgreSQL 进行停止/重启/重新加载参数操作。
-</p>
-<p>
-可以使用和安装 pgpool_regclass 一样的方法安装着四个函数。
-不过和 pgpool_regclass 不同的是，你只需要在 template1 数据库中安装这些函数。
-</p>
-
-<p>以下是安装这些函数的方法</p>
-<p>
-<pre>
-$ cd pgpool-II-x.x.x/sql/pgpool-recovery
-$ make
-$ make install
-</pre>
-
-<p>After this:<p>
-<pre>
-$ psql -f pgpool-recovery.sql template1
-</pre>
-
-<p>or<p>
-
-<pre>
-$ psql template1
-=# CREATE EXTENSION pgpool_recovery;
-</pre>
-</p>
-
-<h4>配置 pgpool.pg_ctl <span class="version">V3.3 -</span></h4>
-
-<p>函数 pgpool_pgctl 执行 postgresql.conf 中 "pgpool.pg_ctl" 指定的命令。
-要使用这个函数，你必须指定这个参数。</p>
-<pre>
-ex)
-$ cat &gt;&gt; /usr/local/pgsql/postgresql.conf
-pgpool.pg_ctl = '/usr/local/pgsql/bin/pg_ctl'
-
-$ pg_ctl reload -D /usr/local/pgsql/data
-</pre>
-
-<p class="top_link"><a href="#Top">返回顶部</a></p>
-
-<!-- ================================================================================ -->
-
-<h1>配置 pgpool-II<a name="config"></a></h1>
-
-<p>pgpool-II 的默认配置文件为
-<code>/usr/local/etc/pgpool.conf</code> 和
-<code>/usr/local/etc/pcp.conf</code>。
-pgpool-II 中有很多操作模式。
-每种模式都有相关的可被开启或者禁用的功能，而且有相关的配置项用于控制它们的行为。</p>
-
-<table border>
-
-  <tr class="header">
-    <th>功能/模式</th>
-    <th>原始模式 (*2)</th>
-    <th>复制模式</th>
-    <th>主/备模式</th>
-  </tr>
-
-  <tr>
-    <th>连接池</th>
-    <td align="center">O</td>
-    <td align="center">O</td>
-    <td align="center">O</td>
-  </tr>
-
-  <tr>
-    <th>复制</th>
-    <td align="center">X</td>
-    <td align="center">O</td>
-    <td align="center">X</td>
-  </tr>
-
-  <tr>
-    <th>负载均衡</th>
-    <td align="center">X</td>
-    <td align="center">O</td>
-    <td align="center">O</td>
-  </tr>
-
-  <tr>
-    <th>故障恢复</th>
-    <td align="center">O</td>
-    <td align="center">O</td>
-    <td align="center">O</td>
-  </tr>
-
-  <tr>
-    <th>在线恢复</th>
-    <td align="center">X</td>
-    <td align="center">O</td>
-    <td align="center">(*1)</td>
-  </tr>
-
-  <tr>
-    <th>需要的服务器数</th>
-    <td align="center">1 或更多</td>
-    <td align="center">2 或更多</td>
-    <td align="center">2 或更多</td>
-  </tr>
-
-</table>
-
-<ul>
-    <li> O 意味着“可用”， X 意味着“不可用
-    <li>(*1) 在线恢复可以和流复制同时使用。
-    <li>(*2) 客户端仅仅是通过 pgpool-II 连接到 PostgreSQL 服务器。
-        这种模式仅仅用于限制到服务器的连接数，或者在多台机器上启用故障恢复。
-</ul>
-
-<h2 id="pcp_conf">配置 <code>pcp.conf</code></h2>
-
-<p>pgpool-II 有一个控制接口，管理员可以通过它远程收集 pgpool-II 的状态信息或者终止 pgpool-II 进程。
-<code>pcp.conf</code> 是用于这个接口认证的用户/密码文件。
-所有的模式都需要先设置 <code>pcp.conf</code> 文件。
-一个 <code>$prefix/etc/pcp.conf.sample</code> 文件在 pgpool-II 安装时已经被创建。
-重命名这个文件为 <code>pcp.conf</code> 并添加你要的用户名和密码到其中。
-</p>
-
-<pre>
-cp $prefix/etc/pcp.conf.sample $prefix/etc/pcp.conf
-</pre>
-<p>空行或者以“<code>#</code>”开始的行将被认为是注释，会被忽略掉。一个用户名和对应的密码必须以以下的方式写成一行。</p>
-<pre>
-username:[password encrypted in md5]
-</pre>
-<p>
-<code>[password encrypted in md5]</code> 可以通过
-<code>$prefix/bin/pg_md5</code> 命令生成。
-</p>
-
-<pre>
-pg_md5 -p
-password: &lt;your password&gt;
-</pre>
-<p>
-或者
-</p>
-<pre>
-./pg_md5 foo
-acbd18db4cc2f85cedef654fccc4a4d8
-</pre>
-<p>
-<code>pcp.conf</code> 对于运行 pgpool-II 的用户必须可读。</p>
-
-<h2 id="pgpool_conf">配置 <code>pgpool.conf</code></h2>
-
-<p>就像之前说的，每种操作模式在 <code>pgpool.conf</code> 文件中有它对应的配置项。
-一个 <code>$prefix/etc/pgpool.conf.sample</code> 文件在 pgpool-II 安装时已经被创建。
-重命名这个文件为 <code>pgpool.conf</code> 并修改它的内容。
-</p>
-
-<pre>
-cp $prefix/etc/pgpool.conf.sample $prefix/etc/pgpool.conf
-</pre>
-
-<p>
-针对每种不同的模式，提供了附加的示例 pgpool.conf。<span class="version">V2.3 -</span>
-</p>
-<p>
-<table border>
-<tr class="header">
-<th>模式</th>
-<th>示例文件</th>
-</tr>
-
-<tr>
-<td>复制模式</td>
-<td>pgpool.conf.sample-replication</td>
-</tr>
-
-<tr>
-<td>主/备模式（Slony-I）</td>
-<td>pgpool.conf.sample-master-slave</td>
-</tr>
-
-<tr>
-<td>主/备模式（流复制）</td>
-<td>pgpool.conf.sample-stream</td>
-</tr>
-</table>
-
-<p>
-空行或者以“<code>#</code>”开始的行将被认为是注释，会被忽略掉。</p>
-</p>
-
-<h3>连接</h3>
-
-<dl>
-<dt><a name="LISTEN_ADDRESS"></a>listen_addresses</dt>
-    <dd>
-    <p>指定 pgpool-II 将接受 TCP/IP 连接的主机名或者IP地址。
-    <code>'*'</code> 将接受所有的连接。<code>''</code> 将禁用 TCP/IP 连接。
-    默认为 <code>'localhost'</code>。总是支持接受通过 UNIX 域套接字发起的连接。
-    </p>
-    <p>
-    需要重启 pgpool-II 以使改动生效。
-    </p>
-  </dd>
-
-<dt><a name="PORT"></a>port</dt>
-    <dd>
-    <p>pgpool-II 监听 TCP/IP 连接的端口号。默认为 9999。
-    </p>
-    <p>
-    需要重启 pgpool-II 以使改动生效。
-    </p>
-    </dd>
-
-<dt><a name="SOCKET_DIR"></a>socket_dir</dt>
-    <dd>
-    <p>pgpool-II 建立用于建立接受 UNIX 域套接字连接的目录。
-    默认为 <code>'/tmp'</code>。注意，这个套接字可能被 cron 任务删除。
-    我们建议设置这个值为 <code>'/var/run'</code> 或类似目录。
-    </p>
-    <p>
-    需要重启 pgpool-II 以使改动生效。
-    </p>
-    </dd>
-
-<dt><a name="PCP_LISTEN_ADDRESS"></a>pcp_listen_addresses</dt>
-    <dd>
-    <p>指定 pcp 进程接收 TCP/IP 连接的主机名或IP地址。
-        <code>'*'</code> 接收所有的连接。<code>''</code> 禁用 TCP/IP 连接。
-        默认为 <code>'*'</code>。总是允许使用 UNIX 域套接字进行连接。
-    </p>
-    <p>
-    本参数必须在服务启动前设置。
-    </p>
-    </dd>
-
-<dt><a name="PCP_PORT"></a>pcp_port</dt>
-    <dd>
-    <p>PCP 进程接受连接的端口号。默认为 9898。
-    </p>
-    <p>本参数必须在服务启动前设置。
-    </p>
-    </dd>
-
-<dt><a name="PCP_SOCKET_DIR"></a>pcp_socket_dir</dt>
-    <dd>
-    <p>PCP 进程用于建立接受 UNIX 域套接字连接的目录。
-    默认为 <code>'/tmp'</code>。注意，这个套接字可能被 cron 任务删除。
-    我们建议设置这个值为 <code>'/var/run'</code> 或类似目录。
-    </p>
-    <p>
-    需要重启 pgpool-II 以使改动生效。</p>
-    </dd>
-
-</dl>
-
-<h3>池</h3>
-
-<dl>
-<dt><a name="NUM_INIT_CHILDREN"></a>num_init_children</dt>
-    <dd>
-        <p>预生成的 pgpool-II 服务进程数。默认为 32。
-        num_init_children 也是 pgpool-II 支持的从客户端发起的最大并发连接数。
-        如果超过 num_init_children 数的客户端尝试连接到 pgpool-II，它们将被阻塞（而不是拒绝连接），
-        直到到任何一个 pgpool-II 进程的连接被关闭为止。
-        最多有 2*num_init_children 可以被放入等待队列。
-        </p>
-        <p>
-        这个队列存在于操作系统内核中，名为 "监听队列(listen queue)"。监听队列的长度被称为 "积压(backlog)"。
-        一些系统中有对积压的上限限制，如果 num_init_children*listen_backlog_multiplier 达到这个数值，你需要将积压值设置得更高点。否则，在高负载的系统中可能发生以下问题：1) 连接到 pgpool-II 失败 2) 连接到 pgpool-II 的时间变长，因为内核中存在一些限制。
-        你可以使用命令 "netstat -s" 检查监听队列是不是发生过溢出。
-        如果你发现类似于以下的：
-		</p>
-		<pre>
-535 times the listen queue of a socket overflowed
-		</pre>
-		</p>
-		<p>
-那么很明显监听队列溢出了。
-        这种情况下你需要增加积压(backlog)值（需要管理员权限）。
-        </p>
-        <p>
-        <pre>
-# sysctl net.core.somaxconn
-net.core.somaxconn = 128
-# sysctl -w net.core.somaxconn = 256
-		</pre>
-		</p>
-		<p>
-你也可以添加以下语句到 /etc/sysctl.conf 中。
-		</p>
-		<p>
-		<pre>
-net.core.somaxconn = 256
-		</pre>
-    </p>
-		<p>
-    到每个 PostgreSQL 的连接数大约为 max_pool*num_init_children</p>
-
-    <p>对于以上内容的一些提示：</p>
-    <ul>
-        <li>取消一个执行中的查询将导致建立另一个到后端的连接；因此，如果所有的连接都在使用，
-            则查询无法被取消。如果你想确保查询可以被取消，设置本值为预期最大连接数的两倍。</li>
-
-        <li>PostgreSQL 允许最多 max_connections - superuser_reserved_connections
-            个非超级用户的并发连接。</li>
-    </ul>
-
-    <p>归纳起来，max_pool，num_init_children，max_connections
-        和 superuser_reserved_connections 必须符合以下规则：
-    </p>
-<pre>
-max_pool*num_init_children &lt;= (max_connections - superuser_reserved_connections) (不需要取消查询)
-max_pool*num_init_children*2 &lt;= (max_connections - superuser_reserved_connections) (需要取消查询)
-</pre>
-
-    <p>
-    本参数必须在服务器启动前设置。</p>
-    </dd>
-
-<dt><a name="LISTEN_BACKLOG_MULTIPLIERE"></a>listen_backlog_multiplier <span class="version">V3.4 -</span></dt>
-    <dd>
-        <p>
-        控制前端到 pgpool-II 的连接队列的长度。默认值为 2。
-        队列长度（实际上是系统调用 listen 的 "backlog" 参数）由 listen_backlog_multiplier * num_init_children 定义。
-        如果这个队列不够长，你应该增加这个参数。
-        有一些系统会限制 listen 系统调用的 backlog 参数的上限。
-        参考 <a href="#NUM_INIT_CHILDREN">num_init_children</a> 获取详细信息。
-        </p>
-        <p>
-        本参数必须在服务启动前设置。</p>
-    </dd>
-
-<dt><a name="SERIALIZE_ACCEPT"></a>serialize_accept <span class="version">V3.5 -</span></dt>
-    <dd>
-		<p>
-		  是否针对客户端的连接串行化 accept() 的调用过程。
-		  默认为 off，即不进行串行化（和 pgpool-II 3.4 以及以前版本的行为相同）。
-		  如果为 off，则内核唤醒所有的 pgpool-II 子进程来执行 accept() 且其中一个会真正获取到进入的连接。
-		  这里的问题是，由于有太大量的子进程被唤醒，会发生大量的上下文切换，应能可能会受影响。
-		  这种现象就是经典的“惊群问题（the thundering herd problem）”。
-		  在启用 serialize_accept 后，只有一个 pgpool-II 子进程被唤醒并执行 accept() 且以上问题得以避免。
-		  你什么时候需要开启 serialize_accept 呢？
-		  在 num_init_children 的值非常大的时候，推荐开启 serialize_accept。
-		  对于 num_init_children 被设置得很小的情况，不会提升性能，反而由于串行的成本而可能降低性能。
-		  这个值有多大则依赖于实际环境。建议在做决定前做一次性能测试。
-		  以下为一个使用 pgbench 进行性能测试的例子：
-		</p>
-		<p>
-		  <pre>
-		    pgbench -n -S -p 9999 -c 32 -C -S -T 300 test
-		  </pre>
-		</p>
-		<p>
-		  这里，-C 告诉 pgbench 在每个事物被执行的时候都发起一个新连接。
-		  -c 32 表示连接到 pgpool-II 的并行会话数。可以根据你系统的需求改变这个值。
-		  当 pgbench 执行完后，你需要查看“including connections establishing”中得出的数字。
-		</p>
-		<p>
-		  注意如果 <a href="#CHILD_LIFE_TIME">child_life_time</a> 被启用，则 serialize_accept无效。
-		  也就是要注意如果你希望启用 serialize_accept，则需要将 child_life_time 设置为 0。
-		  如果你担心 pgpool-II 进程的内存泄露或其他潜在的问题，你应该使用 <a href="#CHILD_MAX_CONNECTIONS">child_max_connections</a> 来替代它。
-		  这是一种为了限制而限制的实现方式，可能以后会被移除。
-		</p>
-		<p>
-		本参数必须在服务启动前设置。</p>
-    </dd>
-
-<dt><a name="CHILD_LIFE_TIME"></a>child_life_time</dt>
-    <dd>
-    <p>pgpool-II 子进程的生命周期，单位为秒。
-    如果子进程空闲了这么多秒，它将被终止，一个新的子进程将被创建。
-    这个参数是用于应对内存泄露和其他不可预料错误的一个措施。默认值为 300 （5分钟）。
-    0 将禁用本功能。注意它不影响尚未接受任何连接的进程。
-    </p>
-    <p>
-      注：如果本参数非零，则 <a href="#SERIALIZE_ACCEPT">serialize_accept</a> 无效。
-    </p>
-    <p>
-    如果改变了这个值，你需要重新加载 pgpool.conf 以使变动生效。
-    </p>
-    </dd>
-
-<dt><a name="CHILD_MAX_CONNECTIONS"></a>child_max_connections</dt>
-    <dd>
-    <p>当 pgpool-II 子进程处理这么多个客户端连接后，它将被终止。
-    这个参数在繁忙到 <a href=#CHILD_LIFE_TIME">child_life_time</a> 和
-    <a href="#CONNECTION_LIFE_TIME">connection_life_time</a> 永远不会触发的服务器上有效。
-    </p>
-    <p>
-    如果你改变了这个值，需要重新加载 pgpool.conf 以使变动生效。
-    </p>
-    </dd>
-
-<dt><a name="CLIENT_IDLE_LIMIT"></a>client_idle_limit</dt>
-    <dd>
-    <p>当一个客户端在执行最后一条查询后如果空闲到了 client_idle_limit 秒数，
-      到这个客户端的连接将被断开。
-      这在避免 pgpool 子进程被懒客户端占用或者探测断开的客户端和 pgpool 之间的 TCP/IP 连接非常有用。
-    </p>
-    <p>
-      如果你改变了这个值，需要重新加载 pgpool.conf 以使变动生效。
-    </p>
-    </dd>
-
-<dt><a name="ENABLE_POOL_HBA"></a>enable_pool_hba</dt>
-    <dd>
-    <p>
-    如果为 true，则使用 pgpool_hba.conf 来进行客户端认证。
-    参考<a href="#hba">设置用于客户端认证的 pool_hba.conf</a>。
-    </p>
-    <p>
-    如果你改变了这个值，需要重新加载 pgpool.conf 以使变动生效。
-    </p>
-    </dd>
-
-<dt><a name="POOL_PASSWD"></a>pool_passwd</dt>
-    <dd>
-    <p>
-    指定用于 md5 认证的文件名。默认值为"pool_passwd"。"" 表示禁用。
-    参考 <a href="#md5">认证 / 访问控制</a> 获得更多信息。
-    </p>
-    <p>
-    如果你改变了这个值，需要重启 pgpool-II 以生效。
-    </p>
-    </dd>
-
-<dt><a name="AUTHENTICATION_TIMEOUT"></a>authentication_timeout</dt>
-    <dd>
-    <p>指定 pgpool 认证超时的时长。0 指禁用超时，默认值为 60 。
-    </p>
-    <p>
-    如果你改变了这个值，需要重新加载 pgpool.conf 以使变动生效。
-    </p>
-    </dd>
-</dl>
-
-<h3>日志</h3>
-
-<dl>
-<dt><a name="LOG_DESTINATION"></a>log_destination <span class="version">V3.1 -</span></dt>
-    <dd>
-    <p>pgpool-II 支持多种记录服务器消息的方式，包括 stderr 和 syslog。默认为记录到 stderr。
-    </p>
-    <p>注：要使用syslog 作为 log_destination 的选项，你将需要更改你系统的 syslog 守护进程的配置。
-    pgpool-II 可以记录到 syslog 设备 LOCAL0 到 LOCAL7 （参考 syslog_facility），
-    但是大部分平台的默认的 syslog 配置将忽略这些消息。你需要添加如下一些内容
-    </p>
-<pre>
-local0.*    /var/log/pgpool.log
-</pre>
-      <p>到 syslog 守护进程的配置文件以使它生效。</p>
-    </dd>
-
-<dt><a name="PRINT_TIMESTAMP"></a>print_timestamp <span class="version">- V3.4 (REMOVED)</span></dt>
-    <dd>
-    <p>
-    如果本值被设置为 true ，则将在日志中添加时间戳。默认值为 true。
-    </p>
-    <p>
-    如果你改变了这个值，需要重新加载 pgpool.conf 以使变动生效。
-    </p>
-    </dd>
-
-<dt><a name="PRINT_USER"></a>print_user <span class="version">- V3.4 (REMOVED)</span></dt>
-    <dd>
-    <p>如果本值被设置为 true，则将在日志中添加会话的用户名。默认为 false。
-    </p>
-    <p>
-    如果你改变了这个值，需要重新加载 pgpool.conf 以使变动生效。
-    </p>
-    </dd>
-
-	<dt><a name="LOG_LINE_PREFIX"></a>log_line_prefix</dt>
-	<dd>
-	<p>
-    这是输出到每行日志开头的打印样式字符串。
-    % 字符开始的 "转义序列" 将被下表的内容替换。
-    所有不支持的转义将被忽略。其他的字符串将直接拷贝到日志行中。
-
-    默认值为 '%t: pid %p: '，即打印时间戳和进程好，
-    这将与 3.4 之前的版本保持兼容。
-	</p>
-	<table border>
-	<tr class="header"><th>转义字符</th><th>效果</th></tr>
-	<tr><td>%a</td><td>客户端应用程序名</td></tr>
-	<tr><td>%p</td><td>进程号 (PID)</td></tr>
-	<tr><td>%P</td><td>进程名</td></tr>
-	<tr><td>%t</td><td>时间戳</td></tr>
-	<tr><td>%d</td><td>数据库名</td></tr>
-	<tr><td>%u</td><td>用户名</td></tr>
-	<tr><td>%l</td><td>为每个进程记录行号</td></tr>
-	<tr><td>%%</td><td>'%' 字符</td></tr>
-	</table>
-	<p>
-    如果你改变了这个值，需要重新加载 pgpool.conf 以使变动生效。
-	</p>
-	</dd>
-
-<dt><a name="LOG_ERROR_VERBOSITY"></a>log_error_verbosity</dt>
-    <dd>
-    <p>
-    控制记录的日支消息的详细程度。有效的取值包括 TERSE、DEFAULT 和 VERBOSE，每个都会增加显示的消息内容。
-    TERSE 不包括记录 DETAIL、HINT 以及 CONTEXT 错误信息。
-    </p>
-    <p>
-    如果你改变了这个值，需要重新加载 pgpool.conf 以使变动生效。
-    </p>
-    </dd>
-
-<dt><a name="LOG_CONNECTIONS"></a>log_connections</dt>
-    <dd>
-    <p>
-    如果为 true，进入的连接将被打印到日志中。
-    </p>
-    <p>
-    如果你改变了这个值，需要重新加载 pgpool.conf 以使变动生效。
-    </p>
-    </dd>
-
-<dt><a name="CLIENT_MIN_MESSAGES"></a>client_min_messages</dt>
-    <dd>
-    <p>
-    控制哪个最小级别的消息被发送到客户端。
-    可用的值为 DEBUG5、DEBUG4、DEBUG3、DEBUG2、DEBUG1、LOG、NOTICE、
-    WARNING 以及 ERROR。每个级别包含它后面的级别。
-    默认值为 NOTICE。
-    </p>
-    <p>
-    如果你改变了这个值，需要重新加载 pgpool.conf 以使变动生效。
-    </p>
-    </dd>
-
-<dt><a name="LOG_MIN_MESSAGES"></a>log_min_messages</dt>
-    <dd>
-    <p>
-    控制哪个最小级别的消息被发送到日志中。
-    可用的值为 DEBUG5、DEBUG4、DEBUG3、DEBUG2、DEBUG1、LOG、NOTICE、
-    WARNING、ERROR、FATAL 以及 PANIC。每个级别包含它后面的级别。
-    默认值为 NOTICE。
-    </p>
-    <p>
-    如果你改变了这个值，需要重新加载 pgpool.conf 以使变动生效。
-    </p>
-    </dd>
-
-<dt><a name="LOG_HOSTNAME"></a>log_hostname</dt>
-    <dd>
-    <p>
-    如果为 true，ps 命令将显示客户端的主机名而不是 IP 地址。
-    而且，如果 <a href="#LOG_CONNECTIONS">log_connections</a> 被开启，也会将主机名写入日志。
-    </p>
-    <p>
-    如果你改变了这个值，需要重新加载 pgpool.conf 以使变动生效。
-    </p>
-    </dd>
-
-<dt><a name="LOG_STATEMENT"></a>log_statement</dt>
-    <dd>
-    <p>当设置为 true 时生成 SQL 日志消息。
-    这类似于 PostgreSQL 中的 log_statement 参数。
-    即使调试选项没有在启动的时候传递到 pgpool-II，它也会产生日志。
-    </p>
-    <p>
-    如果你改变了这个值，需要重新加载 pgpool.conf 以使变动生效。
-    </p>
-    </dd>
-
-<dt><a name="LOG_PER_NODE_STATEMENT"></a>log_per_node_statement <span class="version">V2.3 -</span></dt>
-    <dd>
-    <p>类似于 <a href="#LOG_PER_NODE_STATEMENT">log_statement</a>，除了它是针对每个 DB 节点产生日志外。例如它对于确定复制是否正常运行非常有用。
-    </p>
-    <p>
-    如果你改变了这个值，需要重新加载 pgpool.conf 以使变动生效。
-    </p>
-    </dd>
-
-<dt><a name="SYSLOG_FACILITY"></a>syslog_facility <span class="version">V3.1 -</span></dt>
-    <dd>
-    <p>当记录日志到 syslog 被启用，本参数确定被使用的 syslog “设备”。
-    你可以使用 LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7；
-    默认为 LOCAL0。还请参考你系统的 syslog 守护进程的文档。
-    </p>
-    </dd>
-
-<dt><a name="SYSLOG_IDENT"></a>syslog_ident <span class="version">V3.1 -</span></dt>
-    <dd>
-    <p>当记录日志到 syslog 被启用，本参数确定用于标记 syslog 中 pgpool-II 消息的程序名。默认为“pgpool”。
-    </p>
-    </dd>
-
-<dt><a name="DEBUG_LEVEL"></a>debug_level <span class="version">V3.0 -</span></dt>
-    <dd>
-    <p>
-    调试消息详细程度级别。0 表示没有消息。大于 1 表示更详细的消息。默认值为 0。
-    </p>
-    </dd>
-</dl>
-
-<h3>文件位置</h3>
-
-<dl>
-<dt><a name="PID_FILE_NAME"></a>pid_file_name</dt>
-    <dd>
-    <p>到包含 pgpool-II 进程 ID 的文件的完整路径名。
-    默认为 <code>'/var/run/pgpool/pgpool.pid'</code>。
-    </p>
-    <p>
-    需要重启 pgpool-II 以使改动生效。
-    </p>
-    </dd>
-
-<dt><a name="LOGDIR"></a>logdir</dt>
-    <dd>
-    <p>保存日志文件的目录。 pgpool_status 将被写入这个目录。</p>
-    </dd>
-</dl>
-
-<h3>连接池</h3>
-
-<dl>
-<dt><a name="CONNECTION_CACHE"></a>connection_cache</dt>
-    <dd>
-    <p>如果本值被设置为 true，则缓存到 PostgreSQL 的连接。默认为 true。
-    </p>
-    <p>
-    需要重启 pgpool-II 以使改动生效。
-    </p>
-    </dd>
-</dl>
-
-<h3>健康检查</h3>
-
-<dl>
-<dt><a name="HEALTH_CHECK_TIMEOUT"></a>health_check_timeout</dt>
-    <dd>
-    <p>pgpool-II 定期尝试连接到后台以检测服务器是否在服务器或网络上有问题。
-    这种错误检测过程被称为“健康检查”。如果检测到错误，
-    则 pgpool-II 会尝试进行故障恢复或者退化操作。
-    </p>
-    <p>
-    本参数用于避免健康检查在例如网线断开等情况下等待很长时间。
-    超时值的单位为秒。默认值为 20 。0 禁用超时（一直等待到 TCP/IP 超时）。
-    </p>
-    <p>
-    健康检查需要额外的到后端程序的连接，所以 <code>postgresql.conf</code>
-    中的 <code>max_connections</code> 需要加一。
-    </p>
-    <p>
-    如果你改变了这个值，需要重新加载 pgpool.conf 以使变动生效。
-    </p>
-    </dd>
-
-<dt><a name="HEALTH_CHECK_PERIOD"></a>health_check_period</dt>
-    <dd>
-    <p>本参数指出健康检查的间隔，单位为秒。默认值为 0 ，代表禁用健康检查。
-    </p>
-    <p>
-    如果你改变了这个值，需要重新加载 pgpool.conf 以使变动生效。
-    </p>
-    </dd>
-
-<dt><a name="HEALTH_CHECK_USER"></a>health_check_user</dt>
-    <dd>
-    <p>用于执行健康检查的用户。用户必须存在于 PostgreSQL 后台中。
-    </p>
-    <p>
-    如果你改变了这个值，需要重新加载 pgpool.conf 以使变动生效。
-    </p>
-    </dd>
-
-<dt><a name="HEALTH_CHECK_PASSWORD"></a>health_check_password <span class="version">V3.1 -</span></dt>
-    <dd>
-    <p>用于执行健康检查的用户的密码。
-    </p>
-    <p>
-    如果你改变了这个值，需要重新加载 pgpool.conf 以使变动生效。
-    </p>
-    </dd>
-
-<dt><a name="HEALTH_CHECK_DATABASE"></a>health_check_database <span class="version">V3.5 -</span></dt>
-    <dd>
-    <p>执行健康检查的数据库名。默认为 ''，即首先尝试使用“postgres”数据库，之后尝试“template1”数据库，直到成功。
-      这和 3.4 或者以前版本的行为相同。
-    </p>
-    <p>
-    如果你改变了这个值，需要重新加载 pgpool.conf 以使变动生效。
-    </p>
-    </dd>
-
-<dt><a name="HEALTH_CHECK_MAX_RETRIES"></a>health_check_max_retries <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>在执行失效故障切换前尝试的最大失效健康检查次数。
-    这个参数对于网络不稳定的时，健康检查失败但主节点依旧正常的情况下非常有效。
-    默认值为 0，也就是不重试。如果你想启用 health_check_max_retries，
-    建议你禁用 <a href="#FAIL_OVER_ON_BACKEND_ERROR">fail_over_on_backend_error</a>。
-    </p>
-    <p>
-    如果你改变了 health_check_max_retries，需要重新加载 pgpool.conf。
-    </p>
-    </dd>
-
-<dt><a name="HEALTH_CHECK_RETRY_DELAY"></a>health_check_retry_delay <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>失效健康检查重试的间隔时间（单位为秒）（ health_check_max_retries > 0 时有效 ）。
-    如果为 0 则立即重试（不延迟）。
-    </p>
-    <p>
-    如果你改变了 health_check_retry_delay，需要重新加载 pgpool.conf。
-    </p>
-    </dd>
-
-<dt><a name="CONNECT_TIMEOUT"></a>connect_timeout <span class="version">V3.4 -</span></dt>
-    <dd>
-    <p>使用 connect() 系统调用时候放弃连接到后端的超时毫秒值。
-    默认为 10000 毫秒（10秒）。网络不稳地的用户可能需要增加这个值。
-    0 表示不允许超时。注意本参数不仅仅用于健康检查，也用于普通连接池的连接。
-    </p>
-    <p>
-    如果你改变了 connect_timeout，需要重新加载 pgpool.conf。
-    </p>
-    </dd>
-
-<dt><a name="SEARCH_PRIMARY_NODE_TIMEOUT"></a>search_primary_node_timeout <span class="version">V3.3 -</span></dt>
-    <dd>
-    <p>本参数指定在发生故障切换的时候查找一个主节点的最长时间，单位为秒。
-    默认值为 10。pgpool-II 将在发生故障切换的时候在设置的时间内尝试搜索主节点，
-    如果到达这么长时间未搜索到则放弃搜索。0 表示一直尝试。
-    本参数在流复制模式之外的情况下被忽略。
-    </p>
-    <p>
-    如果你改变了 search_primary_node_timeout，需要重新加载 pgpool.conf。
-    </p>
-    </dd>
-</dl>
-
-<h3>故障切换和恢复</h3>
-
-<dl>
-<dt><a name="FAILOVER_COMMAND"></a>failover_command</dt>
-    <dd>
-    <p>本参数指定当一个节点断开连接时执行的命令。
-    pgpool-II 使用后台对应的信息代替以下的特别字符。
-    </p>
-
-
-    <table border>
-    <tr><td>特殊字符</td><td>描述</td></tr>
-    <tr><td>%d</td><td>断开连接的节点的后台 ID。</td></tr>
-    <tr><td>%h</td><td>断开连接的节点的主机名。</td></tr>
-    <tr><td>%p</td><td>断开连接的节点的端口号。</td></tr>
-    <tr><td>%D</td><td>断开连接的节点的数据库实例所在目录。</td></tr>
-    <tr><td>%M</td><td>旧的主节点 ID。</td></tr>
-    <tr><td>%m</td><td>新的主节点 ID。</td></tr>
-    <tr><td>%H</td><td>新的主节点主机名。</td></tr>
-    <tr><td>%P</td><td>旧的第一节点 ID。</td></tr>
-    <tr><td>%r</td><td>新的主节点的端口号。</td></tr>
-    <tr><td>%R</td><td>新的主节点的数据库实例所在目录。</td></tr>
-    <tr><td>%%</td><td>'%' 字符</td></tr>
-    </table>
-
-    <p>
-    如果你改变了这个值，需要重新加载 pgpool.conf 以使变动生效。
-    </p>
-
-    <p>
-    当进行故障切换时，pgpool 杀掉它的所有子进程，这将顺序终止所有的到 pgpool 的会话。
-    然后，pgpool 调用 failover_command 并等待它完成。
-    然后，pgpool 启动新的子进程并再次开始从客户端接受连接。
-    </p>
-    </dd>
-
-<dt><a name="FAILBACK_COMMAND"></a>failback_command</dt>
-    <dd>
-    <p>
-    本参数指定当一个节点连接时执行的命令。pgpool-II 使用后台对应的信息代替以下的特别字符。
-    </p>
-
-    <table border>
-    <tr><td>特殊字符</td><td>描述</td></tr>
-    <tr><td>%d</td><td>新连接上的节点的后台 ID。</td></tr>
-    <tr><td>%h</td><td>新连接上的节点的主机名。</td></tr>
-    <tr><td>%p</td><td>新连接上的节点的端口号。</td></tr>
-    <tr><td>%D</td><td>新连接上的节点的数据库实例所在目录。</td></tr>
-    <tr><td>%M</td><td>旧的主节点 ID。</td></tr>
-    <tr><td>%m</td><td>新的主节点 ID。</td></tr>
-    <tr><td>%H</td><td>新的主节点主机名。</td></tr>
-    <tr><td>%P</td><td>旧的第一节点 ID。</td></tr>
-    <tr><td>%r</td><td>新的主节点的端口号。</td></tr>
-    <tr><td>%R</td><td>新的主节点的数据库实例所在目录。</td></tr>
-    <tr><td>%%</td><td>'%' 字符</td></tr>
-    </table>
-
-    <p>
-    如果你改变了这个值，需要重新加载 pgpool.conf 以使变动生效。
-    </p>
-    </dd>
-
-<dt><a name="FOLLOW_MASTER_COMMAND"></a>follow_master_command <span class="version">V3.1 -</span></dt>
-    <dd>
-    <p>
-    本参数指定一个在主备流复制模式中发生主节点故障恢复后执行的命令。
-    pgpool-II 使用后台对应的信息代替以下的特别字符。
-    </p>
-
-    <table border>
-    <tr class="header"><th>特殊字符</th><th>描述</th></tr>
-    <tr><td>%d</td><td>断开连接的节点的后台 ID。</td></tr>
-    <tr><td>%h</td><td>断开连接的节点的主机名。</td></tr>
-    <tr><td>%p</td><td>断开连接的节点的端口号。</td></tr>
-    <tr><td>%D</td><td>断开连接的节点的数据库实例所在目录。</td></tr>
-    <tr><td>%M</td><td>旧的主节点 ID。</td></tr>
-    <tr><td>%m</td><td>新的主节点 ID。</td></tr>
-    <tr><td>%H</td><td>新的主节点主机名。</td></tr>
-    <tr><td>%P</td><td>旧的第一节点 ID。</td></tr>
-    <tr><td>%r</td><td>新的主节点的端口号。</td></tr>
-    <tr><td>%R</td><td>新的主节点的数据库实例所在目录。</td></tr>
-    <tr><td>%%</td><td>'%' 字符</td></tr>
-    </table>
-
-    <p>
-    如果你改变了这个值，需要重新加载 pgpool.conf 以使变动生效。
-    </p>
-
-    <p>
-    如果 follow_master_commnd 不为空，当一个主备流复制中的主节点的故障切换完成，
-    pgpool 退化所有的除新的主节点外的所有节点并启动一个新的子进程，
-    再次准备好接受客户端的连接。
-    在这之后，pgpool 针对每个退化的节点运行 ‘follow_master_command’ 指定的命令。
-    通常，这个命令应该用于调用例如 <a href="#pcp_recovery_node">pcp_recovery_node</a> 命令来从新的主节点恢复备节点。
-    </p>
-    </dd>
-
-<dt><a name="FAIL_OVER_ON_BACKEND_ERROR"></a>fail_over_on_backend_error <span class="version">V2.3 -</span></dt>
-    <dd>
-    <p>
-    如果为 true，当往后台进程的通信中写入数据时发生错误，pgpool-II 将触发故障处理过程。
-    这和 pgpool-II 2.2.x 甚至以前版本的行为一样。如果设置为 false，则 pgpool 将报告错误并断开该连接。
-    请注意如果设置为 true，当连接到一个后台进程失败或者 pgpool 探测到 postmaster 由于管理原因关闭，pgpool 也会执行故障恢复过程。
-    </p>
-    <p>
-    如果你改变了这个值，需要重新加载 pgpool.conf 以使变动生效。
-    </p>
-    </dd>
-</dl>
-
-<h3>负载均衡模式</h3>
-
-<dl>
-  <dt><a name="IGNORE_LEADING_WHITE_SPACE"></a>ignore_leading_white_space</dt>
-    <dd>
-    <p>在负载均衡模式中 pgpool-II 忽略 SQL 查询语句前面的空白字符。
-        如果使用类似于 DBI/DBD:Pg 一类的在用户的查询前增加空白的 API 中非常有用。
-    </p>
-    <p>
-    如果你改变了这个值，需要重新加载 pgpool.conf 以使变动生效。
-    </p>
-    </dd>
-
-      <dt id="ALLOW_SQL_COMMENTS">allow_sql_comments <span class="version">V3.4 -</span></dt>
-    <dd>
-    <p>
-      如果设置为 on，在判断是否负载均衡或查询缓存的时候忽略 SQL 注释。
-      如果设置为 off，SQL 注释会有效地阻止以上的判断（3.4以前版本的行为）。
-    </p>
-    <p>
-    如果你改变了这个值，需要重新加载 pgpool.conf 以使变动生效。
-    </p>
-    </dd>
-</dl>
-
-<h3>后端（PostgreSQL 服务）</h3>
-
-<dl>
-<dt><a name="BACKEND_HOSTNAME"></a>backend_hostname</dt>
-    <dd>
-    <p>指出连接到 PostgreSQL 后台程序的地址。它用于 pgpool-II 与服务器通信。如果你改变了这个值，需要重新加载 pgpool.conf 以使变动生效。
-    </p>
-    <p>
-    对于 TCP/IP 通信，本参数可以是一个主机名或者IP地址。如果它是从斜线开始的，它指出是通过 UNIX 域套接字通信，而不是 TCP/IP 协议；它的值为存储套接字文件所在的目录。如果 backend_host 为空，则它的默认行为是通过 <code>/tmp</code> 中的 UNIX 域套接字连接。
-    </p>
-    <p>
-    可以通过在本参数名的末尾添加一个数字来指定多个后台程序（例如<code>backend_hostname0</code>）。这个数字对应为“数据库节点 ID”，是从 0 开始的正整数。被设置数据库节点ID为 0 的后台程序后台程序将被叫做“主数据库”。当定义了多个后台程序时，即使主数据库当机后依然能继续（某些模式下不行）。在这种情况下，存活的最小的数据库节点编号的数据库将被变成新的主数据库。
-    <p> 请注意有编号为 0 的节点在流复制中没有其他意义。但是，你需要注意数据库节点是不是“主节点”。请参考 <a href="#stream">流复制</a> 获得更多细节。</p>
-    </p>
-    <p>如果你只计划使用一台 PostgreSQL 服务器，可以通过 <code>backend_hostname0</code> 指定。</p>
-    <p>
-    可以通过配置本参数后重新加载配置文件添加新的节点。但是，对已有的值无法更新，所以这种情况下你必须重启 pgpool-II。
-    </p>
-    </dd>
-
-<dt><a name="BACKEND_PORT"></a>backend_port</dt>
-    <dd>
-    <p>指定后台程序的端口号。可以通过在本参数名的末尾添加一个数字来指定多个后台程序（例如<code>backend_port0</code>）。
-    如果你只计划使用一台 PostgreSQL 服务器，可以通过 <code>backend_port0</code> 指定。
-    </p>
-    <p>
-    可以通过配置本参数后重新加载配置文件添加新的后台端口。但是，对已有的值无法更新，所以这种情况下你必须重启 pgpool-II。
-    </p>
-    </dd>
-
-<dt><a name="BACKEND_WEIGHT"></a>backend_weight</dt>
-    <dd>
-    <p>指定后台程序的负载均衡权重。
-    可以通过在本参数名的末尾添加一个数字来指定多个后台程序（例如<code>backend_weight0</code>）。
-    如果你只计划使用一台 PostgreSQL 服务器，可以通过 <code>backend_weight0</code> 指定。
-    在原始模式中，请将本值设置为 1。</p>
-    <p>
-    可以通过配置本参数后重新加载配置文件添加新的负载均衡权重。
-    </p>
-    <p>
-    在 pgpool-II 2.2.6/2.3 或者更新的版本中，你可以通过重新加载配置文件来改变本值。
-    但这只对新连接的客户会话生效。
-    这在主备模式中可以避免任何执行一些管理工作的查询被发送到备用节点上。
-    </p>
-    </dd>
-
-<dt><a name="BACKEND_DATA_DIRECTORY"></a>backend_data_directory</dt>
-    <dd>
-    <p>指定后台的数据库实例的目录。
-    可以通过在本参数名的末尾添加一个数字来指定多个后台程序（例如<code>backend_data_directory0</code>）。
-    如果你不打算使用在线恢复，你可以不设置本参数。
-    </p>
-    <p>
-    可以通过配置本参数后重新加载配置文件添加新的后台的数据库实例目录。
-    但是，对已有的值无法更新，所以这种情况下你必须重启 pgpool-II。
-    </p>
-    </dd>
-
-<dt><a name="BACKEND_FLAG"></a>backend_flag <span class="version">V3.1 -</span></dt>
-    <dd>
-    <p>控制大量的后台程序的行为。可以通过在本参数名的末尾添加一个数字来指定多个后台程序（例如<code>backend_flag0</code>）
-    </p>
-    <p>
-    当前支持以下的内容。多个标志可以通过“|”来分隔。
-    </p>
-
-    <table border>
-    <tr><th class="nodec">ALLOW_TO_FAILOVER</th>
-        <td>允许故障切换或者从后台程序断开。本值为默认值。指定本值后，不能同时指定 DISALLOW_TO_FAILOVER 。
-        </td></tr>
-    <tr><th class="nodec">DISALLOW_TO_FAILOVER</th>
-    <td>不允许故障切换或者从后台程序断开。本值在你使用 HA（高可用性）软件例如 Heartbeat 或者 Packmaker 来保护后台程序时非常有用。
-        本值为默认值。指定本值后，不能同时指定 DISALLOW_TO_FAILOVER 。
-    </td></tr>
-    </table>
-  </dt>
-</dl>
-
-<h3>SSL</h3>
-
-<dl>
-<dt><a name="SSL">ssl</a> <span class="version">V2.3 -</span></dt>
-    <dd>
-    <p>
-    如果设置为 ture，则启用了到前端程序和后端程序的连接的 ssl 支持。
-    注意为了能与前端程序进行 SSL 连接，
-    必须设置 <code>ssl_key</code> 和 <code>ssl_cert</code>。
-    </p>
-
-    <p>
-    SSL 默认被关闭。就像在 <a href="#install">pgpool-II 的安装</a> 小节所说的，
-    注意必须在编译时配置 OpenSSL 支持才能打开 SSL 支持。
-    </p>
-
-    <p>
-    如果修改了 SSL 相关的设置， pgpool-II 守护进程必须重启。
-    </p>
-    </dd>
-
-<dt><a name="SSL_KEY"></a>ssl_key <span class="version">V2.3 -</span></dt>
-    <dd>
-    <p>
-    对于进入的连接使用的私钥文件所在路径。
-    </p>
-
-    <p>
-    本选项没有默认值，如果本值不设置，则对于进入的连接将禁用 SSL。
-    </p>
-    </dd>
-
-<dt><a name="SSL_CERT"></a>ssl_cert <span class="version">V2.3 -</span></dt>
-    <dd>
-    <p>
-    对于进入的连接使用的公共 x509 证书文件所在的路径。
-    </p>
-
-    <p>
-    本选项没有默认值，如果本值不设置，则对于进入的连接将禁用 SSL。
-    </p>
-    </dd>
-
-<dt><a name="SSL_CA_CERT"></a>ssl_ca_cert</dt>
-    <dd>
-    <p>
-    到一个 PEM 格式的证书文件路径，包含一个或多个 CA 根证书，
-    用于校验后端的服务器证书。
-    类似于 OpenSSL 的 <code>verify(1)</code> 命令的 <code>-CAfile</code> 选项。
-    </p>
-
-    <p>
-    本选项的默认值是不设置，因此不会发生校验。
-    但是在 <code>ssl_ca_cert_dir</code> 被设置的时候，还是会发生校验。
-    </p>
-    </dd>
-
-<dt><a name="SSL_CA_CERT_DIR"></a>ssl_ca_cert_dir</dt>
-    <dd>
-    <p>
-    到一个包含 PEM 格式的 CA 证书的目录的路径，
-    用于校验后端的服务器证书。
-    类似于 OpenSSL 的 <code>verify(1)</code> 命令的 <code>-CApath</code> 选项。
-    </p>
-
-    <p>
-    本选项的默认值是不设置，因此不会发生校验。
-    但是在 <code>ssl_ca_cert</code> 被设置的时候，还是会发生校验。
-    </p>
-    </dd>
-
-</dl>
-
-<h3>其他</h3>
-
-<dl>
-<dt><a name="RELCACHE_EXPIRE"></a>relcache_expire <span class="version">V3.1 -</span></dt>
-    <dd>
-    <p>
-     关系缓存的生命周期。0（默认值）表示没有缓冲区过期。
-     关系缓存用于缓存用来获取包含表结构信息或一个表是不是一个临时表等大量信息的相关的
-     PostgreSQL 系统 catalog 的查询结果。缓存位于 pgpool 子进程的本地，并被保存到它的生命结束。
-     如果某些人使用了 ALTER TABLE 修改了表结构或其他类似内容，关系缓存不再一致。
-     为了这个目的，relcache_expire 控制缓存的生命周期。
-    </p>
-    </dd>
-
- <dt><a name="RELCACHE_SIZE"></a>relcache_size <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-        relcache 的条目数。默认为 256。
-        如果你频繁看到以下信息，请增加此数量。
-    </p>
-<pre>
-"pool_search_relcache: cache replacement happened"
-</pre>
-    </dd>
-
-<dt><a name="CHECK_TEMP_TABLE"></a>check_temp_table <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-        如果为 on，在 SELECT 语句中启用临时表检查。这会在启动查询前查询主节点上的系统对象，
-        因此增加了主节点上的负载。如果你确定你的系统不会使用临时表，并且你想降低对主节点的访问，
-        弄可以将它设置为 off。默认为 on。
-    </p>
-    </dd>
-
-<dt><a name="CHECK_UNLOGGED_TABLE"></a>check_unlogged_table <span class="version">V3.4 -</span></dt>
-    <dd>
-    <p>
-    如果设置为 on，启用在 SELECT 语句中对无日志表的检查。
-    这回在主节点上查询系统表，因此会增加主节点的负载。
-    如果你确认你的系统没有使用无日志的表（例如，你在使用 PostgreSQL 9.0 或者之前的版本），
-    并且你想减少对主节点的访问，你可以将本选项设置为 off。默认值为 on。
-    </p>
-    </dd>
-
-</dl>
-
-<h2>生成 SSL 证书</h2>
-<p>证书处理不在本文档讨论范围。postgresql.org 的 <a href="http://developer.postgresql.org/pgdocs/postgres/ssl-tcp.html">
-Secure TCP/IP Connections with SSL</a> 页面指出了一些用来生成自签名证书的示例命令。
-</p>
-
-<h2 id="failover_in_raw_mode">在原始模式中的故障切换</h2>
-
-<p>如果定义了多个服务器，可以在原始模式中进行故障切换。
-pgpool-II 在普通操作中通常访问 <code>backend_hostname0</code> 指定的后台程序。
-如果 backend_hostname0 因为某些原因不能正常工作，pgpool-II 尝试访问 backend_hostname1 指定的后台程序。
-如果它也不能正常工作，pgpool-II 尝试访问 backend_hostname2，3 等等。</p>
-
-<p class="top_link"><a href="#Top">返回顶部</a></p>
-
-<!-- ================================================================================ -->
-
-<h1><a name="connection_pool_mode"></a>连接池模式</h1>
-
-<p>在连接池模式中，所有在原始模式中的功能以及连接池功能都可以使用。要启用本模式，你需要设置 "<a href="#CONNECTION_CACHE">connection_cache</a>" 为 on。
-以下参数会对连接池产生影响。</p>
-
-<dl>
-<dt><a name="MAX_POOL"></a>max_pool</dt>
-  <dd>
-    <p>在 pgpool-II 子进程中缓存的最大连接数。当有新的连接使用相同的用户名连接到相同的数据库，pgpool-II 将重用缓存的连接。如果不是，则 pgpool-II 建立一个新的连接到 PostgreSQL。如果缓存的连接数达到了 max_pool，则最老的连接将被抛弃，并使用这个槽位来保存新的连接。默认值为 4。请小心通过 pgpool-II 进程到后台的连接数可能达到
-        <code><a href="#NUM_INIT_CHILDREN">num_init_children</a></code> *
-      <code><a href="#MAX_POOL">max_pool</a></code> 个。需要重启 pgpool-II 以使改动生效。
-    </p>
-  </dd>
-<dt><a name="CONNECTION_LIFE_TIME"></a>connection_life_time</dt>
-  <dd>
-      <p>缓存的连接的过期时长，单位为秒。过期的缓存连接将被关闭。默认值为 0，表示缓存的连接将不被关闭。</p>
-  </dd>
-<dt><a name="RESET_QUERY_LIST"></a>reset_query_list</dt>
-    <dd>
-    <p>指定在推出一个会话时发送到后台程序的SQL命令。
-    多个命令可以通过“;”隔开。默认为以下的设置但你可以根据你的需求改变。
-
-<pre>
-reset_query_list = 'ABORT; DISCARD ALL'
-</pre>
-
-<p>
-      不同版本的 PostgreSQL 需要使用不同的命令。以下为推荐的设置。
-</p>
-
-    <table border>
-    <tr class="header"><th>PostgreSQL 版本</th><th>reset_query_list 的值</th></tr>
-    <tr><td>7.1 或更老的版本</td><td>ABORT</td></tr>
-    <tr><td>7.2 到 8.2</td><td>ABORT; RESET ALL; SET SESSION AUTHORIZATION DEFAULT</td></tr>
-    <tr><td>8.3 或更新的版本</td><td>ABORT; DISCARD ALL</td></tr>
-    </table>
-
-    <ul>
-    <li>在 7.4 或更新的版本中，当不是在一个事务块中的时候，“ABORT”将不会被发出。</li>
-    </ul>
-
-    <p>
-    修改本参数后需要重新加载 pgpool.conf 以使改变生效。
-    </p>
-    </dd>
-</dl>
-
-<h2><p>连接池模式中的故障切换</p></h2>
-
-<p>连接池模式中的故障切换和原始模式的相同。</p>
-
-<p class="top_link"><a href="#Top">返回顶部</a></p>
-
-<!-- ================================================================================ -->
-
-<h1><a name="replication_mode"></a>复制模式</h1>
-
-<p>本模式在后台程序间启用了数据复制。以下配置参数必须在设置以上参数之外另外设置。</p>
-
-<dl>
-<dt><a name="REPLICATION_MODE"></a>replication_mode</dt>
-  <dd>
-      <p>设置为 true 以启用复制模式。默认值为 false。</p>
-  </dd>
-
-<dt><a name="LOAD_BALANCE_MODE"></a>load_balance_mode</dt>
-  <dd>
-      <p>当设置为 true 时，SELECT 查询将被分发到每个后台程序上用于负载均衡。默认值为 false。本参数必须在服务器启动前设置。</p>
-  </dd>
-
-<dt><a name="REPLICATION_STOP_ON_MISMATCH"></a>replication_stop_on_mismatch</dt>
-  <dd>
-    <p>当设置为 true 时，当不同的后台程序返回不同的包类型时，则和其他后台程序差别最大的后台程序将被退化。</p>
-    <p>一个典型的用例为一个事务中的 SELECT 语句，在 <a href="#REPLICATE_SELECT">replicate_select</a> 设置为 true 的情况下，一个 SELECT 语句从不同的后台程序中返回不同的行数。非 SELECT 语句也可能触发这种情况。
-    例如，一个后台程序执行 UPDATE 成功但其他的失败。注意 pgpool 不会检查 SELECT 返回的记录的内容。
-    </p>
-    <p>
-    如果设置为 false，则会话被终止但后台程序不被退化。默认值为 false。</p>
-  </dd>
-
-<dt><a name="FAILOVER_IF_AFFECTED_TUPLES_MISMATCH"></a>failover_if_affected_tuples_mismatch
-    <span class="version">V3.0 -</span></dt>
-    <dd>
-    <p>当设置为 true 时，如果后端在执行 INSERT/UPDATE/DELETE 时返回影响的行数不相同，
-    那么拥有与其他后端匹配度最低的结果的后端将被退化掉（踢出集群）。
-    如果匹配度相同，则包含主数据库节点（拥有最小节点 ID 的数据库节点）的一组将被保留
-    而其他的将被退化掉。
-    </p>
-    <p>
-    如果设置为 false，则会话被终止但后端不被退化。默认值为 false。</p>
-    </dd>
-
-<dt><a name="WHITE_FUNCTION_LIST"></a>white_function_list <span class="version">V3.0 -</span></dt>
-    <dd>
-    <p>指定一系列用逗号隔开的<strong>不会</strong>更新数据库的函数名。在复制模式中，不在本列表中指定的函数将即不会被负载均衡，也不会被复制。在主备模式中，这些 SELECT 语句只被发送到主节点。</p>
-    <p>你可以使用正则表达式来匹配函数名，例如你通过前缀“get_”或“select_”来作为你只读函数的开头：
-    </p>
-<pre>
-white_function_list = 'get_.*,select_.*'
-</pre>
-</dd>
-
-<dt><a name="BLACK_FUNCTION_LIST"></a>black_function_list <span class="version">V3.0 -</span></dt>
-<dd>
-<p>指定一系列用逗号隔开的<strong>会</strong>更新数据库的函数名。在复制模式中，在本列表中指定的函数将即不会被负载均衡，也不会被复制。在主备模式中，这些 SELECT 语句只被发送到主节点。</p>
-<p>你可以使用正则表达式来匹配函数名，例如你通过前缀“set_”、“update_”、“delete_”或“insert_”来作为你只读函数的开头：</p>
-<pre>
-black_function_list = 'nextval,setval,set_.*,update_.*,delete_.*,insert_.*'
-</pre>
-<p>
-以上两项不能同时配置。
-</p>
-<p>在 pgpool-II 3.0 之前，nextval() 和 setval() 是已知的会写入数据库的函数。你可以通使用 white_function_list 好 balck_function_list 来做到：
-</p>
-
-<pre>
-white_function_list = ''
-black_function_list = 'nextval,setval,lastval,currval'
-</pre>
-
-    <p>注意我们在 nextval 和 setval 后面追加了 lastval 和 currval。
-    虽然 lastval() 和 currval() 不是会写入的函数，
-    但添加 lastval() 和 currval() 可以避免这些函数被无意地被负载均衡到其他的数据库节点而导致错误。
-    添加到 black_function_list 将避免它们被负载均衡。
-    </p>
-    </dd>
-
-<dt><a name="REPLICATE_SELECT"></a>replicate_select</dt>
-<dd>
-<p>当设置为 true，pgpool-II 在复制模式中将复制 SELECT 语句。如果为 false，则 pgpool-II 只发送它们到主数据库。默认为 false。
-</p>
-<p>
-    如果 SELECT 查询是在一个显式的事务块中，<a href="#REPLICATE_SELECT">replicate_select</a> 和 <a href="#LOAD_BALANCE_MODE">load_balance_mode</a> 将影响复制的工作模式。以下为具体的细节。
-</p>
-
-    <table border>
-    <tr class="center">
-        <th class="nodec">replicate_select 为 true</th>
-        <td>Y</td><td colspan="4">N</td>
-    </tr>
-    <tr class="center">
-        <th class="nodec">load_balance_mode 为 true</th>
-        <td>any</td><td colspan="3">Y</td><td>N</td>
-    <tr class="center">
-        <th class="nodec">SELECT 在一个事务块中</th>
-        <td>any</td><td colspan="2">Y</td><td>N</td><td>任意</td>
-    </tr>
-    <tr class="center">
-        <th class="nodec">事务隔离级别为 SERIALIZABLE 且事务执行了写类型的查询</th>
-        <td>any</td><td>Y</td><td>N</td><td>任意</td><td>任意</td>
-    </tr>
-    <tr class="footer center">
-        <th class="nodec">结果（R：复制，M：发送到主节点，L：负载均衡）</th>
-        <td>R</td><td>M</td><td>L</td><td>L</td><td>M</td>
-    </tr>
-    </table>
-    </dd>
-
-<dt><a name="INSERT_LOCK"></a>insert_lock</dt>
-  <dd>
-      <p>如果在包含 SERIAL 类型的表中做复制， SERIAL 列的值在不同后台间可能不同。这个问题可以通过显式的锁表解决（当然，事务的并发性将被严重退化）。为了达到这个目的，必须做以下的改变：</p>
-
-<pre>
-INSERT INTO ...
-</pre>
-
-    <p>
-    改变为
-    </p>
-
-<pre>
-BEGIN;
-LOCK TABLE ...
-INSERT INTO ...
-COMMIT;
-</pre>
-
-      <p>当 <code>insert_lock</code> 为 true 时，pgpool-II 自动在每次执行 INSERT 时添加以上的查询（如果已经在事务中，它只是简单地添加 LOCK TABLE ... ）。
-    </p>
-      <p>pgpool-II 2.2 或更高的版本中，可以自动探测是否表拥有 SERIAL 类型的列，所以如果没有 SERIAL 类型的列，则将不会锁表。
-    </p>
-       <p>
-       pgpool-II 3.0 系列直到 3.0.4 为止针对串行的关系使用一个行锁，而不是表锁。这使在 VACUUM（包括 autovacuum）时的锁冲突最小。但这会导致另一个问题。如果发生了嵌套事务，对串行的关系使用行所会导致 PostgreSQL 的内部错误（确切地说，保存事务状态的 pg_clog 会发生访问错误）。为了避免这个问题，PostgreSQL 核心开发者决定禁止对串行的关系加锁，当然这也会让 pgpool-II 无法工作（&quot;修复&quot;后的 PostgreSQL 版本为 9.0.5, 8.4.9, 8.3.16 和 8.2.22）。
-       </p>
-       <p>
-       由于新版的 PostgreSQL 不允许对串行的关系加锁，pgpool-II 3.0.5 或更新的版本针对 pgpool_catalog.insert_lock 使用行锁。所以需要预先在通过 pgpool-II 访问的数据库中建立 insert_lock 表。详细内容请参考<a href="#install">建立 insert_lock 表</a>。如果不存在 insert_lock 表，pgpool-II 将锁定插入的目标表。这种行为和 pgpool-II 2.2 和 2.3 系列相同。如果你希望使用与旧版本兼容的 insert_lock，你可以在配置脚本中指定锁定模式。详细内容请参考 <a href="#install">configure</a> 。
-       </p>
-       <p>
-      你也许需要更好（针对每个事务）的控制手段：
-      </p>
-
-      <ol>
-    <li>设置 <code>insert_lock</code> 为 true，并添加 <code>/*NO INSERT LOCK*/</code> 代码到你不想要表锁的 INSERT 语句的开始位置。</li>
-
-    <li>设置 <code>insert_lock</code> 为 false，并添加 <code>/*INSERT LOCK*/</code> 到你需要表锁的 INSERT 语句的开始位置。</li>
-      </ol>
-
-      <p>
-      默认值为 false。如果 <code>insert_lock</code> 被启用，则（通过 pgpool-II 运行的） PostgreSQL 8.0 的事务、权限、规则和 alter_table 的回归测试会失败。原因是 pgpool-II 会尝试 LOCK 这些规则测试的 VIEW ，并产生以下的错误消息：
-      </p>
-
-<pre>
-! ERROR: current transaction is aborted, commands ignored until
-end of transaction block
-</pre>
-
-      <p>例如，事务测试尝试 INSERT 到一个不存在的表，而 pgpool-II 导致 PostgreSQL 在这之前请求锁。事务将被终止，而之后的 INSERT 语句会产生以上的错误消息。
-      </p>
-
-
-<dt><a name="RECOVERY_USER"></a>recovery_user</dt>
-<dd>
-<p>
-本参数指定一个用于在线恢复的 PostgreSQL 用户名。改变本参数不需要重启。
-</p>
-
-<dt><a name="RECOVERY_PASSWORD"></a>recovery_password</dt>
-<dd>
-<p>
-本参数指定一个用于在线恢复的 PostgreSQL 密码。改变本参数不需要重启。
-</p>
-
-<dt><a name="RECOVERY_1ST_STAGE_COMMAND"></a>recovery_1st_stage_command</dt>
-<dd>
-<p>
-本参数指定一个在在线恢复第一阶段在主（Primary）PostgreSQL 服务器上运行的命令。处于安全原因，本命令必须被放置在数据库实例目录中。例如，如果 recovery_1st_stage_command = 'sync-command'，那么 pgpool-II 将执行 $PGDATA/sync-command。
-</p>
-<p>
-recovery_1st_stage_command 将接受以下 3 个参数：
-</p>
-<ol>
-<li>到主（Primary）数据库实例的路径</li>
-<li>需要恢复的 PostgreSQL 主机名</li>
-<li>需要恢复的数据库实例路径</li>
-</ol>
-</p>
-<p>
-注意 pgpool-II 在执行 recovery_1st_stage_command 时<b>接收</b>连接和查询。在本阶段中，你可以查询和更新数据。
-</p>
-<p>
-改变本参数不需要重启。
-</p>
-
-<dt><a name="RECOVERY_2ND_STAGE_COMMAND"></a>recovery_2nd_stage_command</dt>
-    <dd>
-    <p>
-    本参数指定一个在在线恢复第二阶段在主（Primary）PostgreSQL 服务器上运行的命令。处于安全原因，本命令必须被放置在数据库实例目录中。例如，如果 recovery_2st_stage_command = 'sync-command'，那么 pgpool-II 将执行 $PGDATA/sync-command。
-    </p>
-    <p>
-    recovery_2nd_stage_command 将接受以下 4 个参数：
-    </p>
-    <ol>
-        <li>到主（Primary）数据库实例的路径</li>
-        <li>需要恢复的 PostgreSQL 主机名</li>
-        <li>需要恢复的数据库实例路径</li>
-        <li>需要恢复的数据库实例的端口号</li>
-    </ol>
-    </p>
-    <p>
-    注意 pgpool-II 在运行 recovery_2nd_stage_command 时<b>不接收</b>连接和查询。因此如果一个客户端长时间持有一个连接，则恢复命令不会被执行。pgpool-II 等待所有的客户端关闭它们的连接。这个命令只在没有任何客户端连接到 pgpool-II 时才执行。
-    </p>
-	<p>
-	<font color="red">
-	CAUTION:
-	</font>
-    recovery_2nd_stage_command 对于 PostgreSQL 来说就是运行一个 SQL 命令。如果你启用了 PostgreSQL 的 statement_time_out 且它的值比 recovery_2nd_stage_command 执行的时间要短，PostgreSQL 会（在时间到达后）取消这个命令的执行。
-    这种情况的典型现象是，例如命令中的 rsync 收到信号 2。
-    </p>
-    <p>
-    改变本参数不需要重启。
-    </p>
-    </dd>
-
-<dt><a name="RECOVERY_TIMEOUT"></a>recovery_timeout</dt>
-    <dd>
-    <p>
-    pgpool 在第二阶段不接受新的连接。如果一个客户端在恢复过程中连接到 pgpool，它必须等待到恢复结束。
-    </p>
-    <p>
-    本参数指定恢复超时的时间，单位为秒。如果到达了本超时值，则 pgpool 取消在线恢复并接受连接。0 表示不等待。
-    </p>
-    <p>
-    改变本参数不需要重启。
-    </p>
-    </dd>
-
-<dt><a name="CLIENT_IDLE_LIMIT_IN_RECOVERY"></a>client_idle_limit_in_recovery
-    <span class="version">V2.2 -</span></dt>
-    <dd>
-    <p> 类似于 client_idle_limit 但是只在恢复的第二阶段生效。从执行最后一个查询后空闲到 client_idle_limit_in_recovery 秒的客户端将被断开连接。
-    这对避免 pgpool 的恢复被懒客户端扰乱或者客户机和 pgpool 之间的 TCP/IP 连接被意外断开（例如网线断开）非常有用。如果设置为 -1 ，则立即断开客户端连接。
-    client_idle_limit_in_recovery 的默认值为 0，表示本功能不启用。
-    </p>
-    <p> 如果你的客户端非常繁忙，则无论你将 client_idle_limit_in_recovery 设置为多少 pgpool-II 都无法进入恢复的第二阶段。在这种情况下，
-    你可以设置 client_idle_limit_in_recovery 为 -1 因而 pgpool-II 在进入第二阶段前立即断开这些繁忙的客户端的连接。
-    </p>
-    <p>
-    如果你改变了 client_idle_limit_in_recovery 你需要重新加载 pgpool.conf 。</p>
-    </dd>
-
-<dt><a name="LOBJ_LOCK_TABLE"></a>lobj_lock_table <span class="version">V2.2 -</span></dt>
-    <dd>
-    <p>
-    本参数指定一个表名用于大对象的复制控制。如果它被指定，pgpool 将锁定由 lobj_lock_table 指定的表并通过查找 pg_largeobject 系统 catalog 生产一个大对象 id，并调用 lo_create 来建立这个大对象。这个过程保证 pgpool 在复制模式中在所有的数据库节点中获得相同的大对象 id。注意 PostgreSQL 8.0 或者更老的版本没有 lo_create，因此本功能将无法工作。
-    </p>
-<p>
-对 libpq 的 lo_creat() 函数的调用将触发本功能。通过 Java API（JDBC 驱动），PHP API（pg_lo_create，或者 PHP 库中类似的 API 例如 PDO）进行的大对象创建，以及其他各种编程语言中相同的 API 使用相同的协议，因此也应该能够运行。
-</p>
-<p>
-以下的大对象建立操作将无法运行：
-<p>
-<ul>
-<li>libpq 中的 lo_create
-<li>任何语言中使用 lo_create 的任何 API
-<li>后台程序的 lo_import 函数
-<li>SELECT lo_creat
-</ul>
-</p>
-<p>
-lobj_lock_table 存储在哪个 schema 并不重要，但是这个表必须对任何用户都可以写入。以下为如何建立这样一个表的示例：
-</p>
-<p>
-<pre>
-CREATE TABLE public.my_lock_table ();
-GRANT ALL ON public.my_lock_table TO PUBLIC;
-</pre>
-</p>
-<p>
-lobj_lock_table 指定的表必须被预先建立。如果你在 template1 中建立这个表，之后建立的任何数据库都将有这个表。
-</p>
-<p>
-如果 lobj_lock_table 为空字符串('')，这个功能被禁用（大对象的复制将无法工作）。lobj_lock_table is 的默认值为''。
-</p>
-
-</dl>
-
-<h2 id="condition_for_load_balance">负载均衡的条件</h2>
-<p>
-需要对一个查询使用负载均衡，需要满足以下的所有条件：
-</p>
-
-<ul>
-    <li>PostgreSQL 7.4 或更高版本</li>
-    <li>即可以在复制模式中，也可以在主备模式中</li>
-    <li>在复制模式中，查询必须不是在一个显式的事务中（例如，不在 BEGIN ~ END 块中）
-        <ul>
-          <li>不过，如果碰到以下情况，即使是在显式事务中，也能够进行负载均衡：
-              <ul>
-                <li>事务的隔离级别不为 SERIALIZABLE</li>
-                <li>事务一直没执行一个写类查询（直到执行了一个写类型的查询，负载均衡都能生效。在这里“写类型查询”指非 SELECT DML 或者 DDL。
-                	调用了在黑名单或者白名单里面的函数的 SELECT 语句不会被认为是写类型的查询。不过这在以后可能会改变。）</li>
-		<li>如果函数黑白名单为空，则调用了函数的 SELECT 语句会被认为是只读的。</li>
-              </ul>
-          </li>
-        </ul>
-    </li>
-    <li>不能是 SELECT INTO</li>
-    <li>不能是 SELECT FOR UPDATE 或者 FOR SHARE</li>
-    <li>以 "SELECT" 开始或者为 COPY TO STDOUT, EXPLAIN, EXPLAIN ANALYZE SELECT... 其中一个，ignore_leading_white_space = true 将忽略开头的空格。
-        （除非是在 <a href="#BLACK_FUNCTION_LIST">black_list</a> 或者 <a href="#WHITE_FUNCTION_LIST">white_list</a> 指明的有写动作的函数）
-    <li><span class="version">V3.0 -</span>在主备模式中，除了以上条件，还包含以下条件：
-        <ul>
-          <li>不能使用临时表</li>
-          <li>不能使用不写日志的表</li>
-          <li>不能使用系统表</li>
-          <li>不过，如果碰到以下条件，即使是显式事务，依然有可能进行负载均衡</li>
-              <ul>
-                <li>事务隔离级别不是SERIALIZABLE</li>
-                <li>事务一直没有进行写查询（直到发生写入查询前，都可能进行负载均衡）</li>
-              </ul>
-        </ul>
-    </li>
-</ul>
-
-<p>
-注意你可以通过在 SELECT 语句之前插入任意的注释来禁止负载均衡：
-<pre>
-/*REPLICATION*/ SELECT ...
-</pre>
-</p>
-
-<p>
-请参考<a href="#replicate_select">replicate_select</a>。也可以参考<a href="where_to_send_queries.pdf">flow chart</a>。
-</p>
-
-<p>
-<font color="red">
-注：JDBC 驱动有自动提交的选项。如果自动提交为 false，
-则 JDBC 驱动将自己发送 "BEGIN" 和 "COMMIT"。在这种情况下<a href="#condition_for_load_balance">与进行负载均衡相同的约束</a>也会发生。
-</font>
-</p>
-
-<h2 id="failover_in_replication_mode">复制模式中的故障切换</h2>
-
-<p> pgpool-II 退化一个死掉的后台并继续提供服务。只要最少还有一个后台还或者，服务就可以继续。</p>
-
-<h2 id="errors_in_replication_mode">复制模式中的特有错误</h2>
-<p>
-在复制模式中，如果 pgpool 发现 INSERT，UPDATE 和 DELETE 生效的行数不同，如果 failover_if_affected_tuples_mismatch 被设置为 false，则 pgpool 将发送错误的 SQL 语句到所有的数据库节点来取消当前当前事务（如果为 false 则发生退化）。
-在这种情况下，你将在客户端终端中看到以下错误信息：
-<p>
-<pre>
-=# UPDATE t SET a = a + 1;
-ERROR: pgpool detected difference of the number of update tuples Possible last query was: "update t1 set i = 1;"
-HINT: check data consistency between master and other db node
-</pre>
-
-<p>
-你将在 PostgreSQL 的日志中看到更新的行数（在本例中，数据库节点 0 更新了 0 行而数据库节点 1 更新了 1 行）。
-</p>
-<pre>
-2010-07-22 13:23:25 LOG:   pid 5490: SimpleForwardToFrontend: Number of affected tuples are: 0 1
-2010-07-22 13:23:25 LOG:   pid 5490: ReadyForQuery: Degenerate backends: 1
-2010-07-22 13:23:25 LOG:   pid 5490: ReadyForQuery: Number of affected tuples are: 0 1
-</pre>
-
-<p class="top_link"><a href="#Top">返回顶部</a></p>
-
-<!-- ================================================================================ -->
-
-<h1><a name="master_slave_mode"></a>主/备模式</h1>
-
-<p>
-本模式用于使用其他负责完成实际的数据复制的主/备复制软件（类似于 Slong-I 和 基于流复制）来连接 pgpool-II。
-必须设置数据库节点的信息（如果你需要在线恢复功能，<a href="#BACKEND_HOSTNAME">backend_hostname</a>、<a href="#BACKEND_PORT">backend_port</a>、
-<a href="#BACKEND_WEIGHT">backend_weight</a>、<a href="#BACKEND_FLAG">backend_flag</a> 和 <a href="#BACKEND_DATA_DIRECTORY">backend_data_directory</a>），
-这和复制模式中的方法相同。另外，还需要设置 <code><a href="#MASTER_SLAVE_MODE">master_slave_mode</a></code> 和 <code><a href="#LOAD_BALANCE_MODE">load_balance_mode</a></code> 为 true。
-</p>
-<p>
-pgpool-II 将发送需要复制的查询到主数据库，并在必要时将其他的查询将被负载均衡。不能被负载均衡而发送到主数据库的查询当然也是受负载均衡逻辑控制的。
-</p>
-
-
-<p>在主/备模式中，对于临时表的 DDL 和 DML 操作只能在主节点上被执行。SELECT 也可以被强制在主节点上执行，但这需要你在 SELECT 语句前添加一个 /*NO LOAD BALANCE*/ 注释。
-</p>
-
-<p>在主/备模式中， <code><a href="#REPLICATION_MODE">replication_mode</a></code> 必须被设置为 false ，并且 <code><a href="#MASTER_SLAVE_MODE">master_slave_mode</a></code> 为 true。</p>
-
-<p>主/备模式有一个“master_slave_sub mode”。默认值为 'slony'，用于 Slony-I。你也可以设置它为 'stream'，它在你想使用 PostgreSQL 内置的复制系统（基于流复制）时被设置。用于 Slony-I 子模式的示例配置文件为 pgpool.conf.sample-master-slave，用于基于流复制的子模式的示例文件为 sub-module is pgpool.conf.sample-stream。
-</p>
-<p>
-修改以上任何参数都需要重新启动 pgpool-II。
-</p>
-<p>
-在主/备模式中，你可以通过设置 <a href="#WHITE_FUNCTION_LIST">white_function_list</a> 和 <a href="#BLACK_FUNCTION_LIST">black_function_list</a> 来控制负载均衡。参考 <a href="#WHITE_FUNCTION_LIST">white_function_list</a> 获得详细信息。
-</p>
-
-<p class="top_link"><a href="#Top">返回顶部</a></p>
-
-<!-- ================================================================================ -->
-
-<h1><a name="stream"></a>流复制 <span class="version">V3.1 -</span></h1>
-<p>
-就像以上规定的，pgpool-II 可以与 PostgreSQL 9.0 带来的基于流复制协同工作。要使用它，启用“<a href="#MASTER_SLAVE_MODE">master_slave_mode</a>”并设置“<a href="#MASTER_SLAVE_SUB_MODE">master_slave_sub_mode</a>”为“stream”。
-pgpool-II 认为基于流复制启用了热备，也就是说备库是以只读方式打开的。以下参数可以用于本模式：
-</p>
-
-<dl>
-<dt id="DELAY_THRESHOLD">delay_threshold <span class="version">V3.0 -</span></dt>
-    <dd>
-    <p>
-    指定能够容忍的备机上相对于主服务器上的 WAL 的复制延迟，单位为字节。
-    如果延迟到达了 delay_threshold，pgpool-II 不再发送 SELECT 查询到备机。
-    所有的东西都被发送到主服务器，即使启用了负载均衡模式，直到备机追赶上来。
-    如果 delay_threshold 为 0 或者流复制检查被禁用，则延迟检查不被执行。
-    这个检查在每“<a href=#SR_CHECK_PERIOD">sr_check_period</a>”周期执行一次。
-    delay_threshold 的默认值为 0。
-    </p>
-    <p>
-    要使对本参数的改动生效，你需要重新加载 pgpool.conf。
-    </p>
-    </dd>
-
-<dt id="SR_CHECK_PERIOD">sr_check_period <span class="version">V3.1 -</span></dt>
-    <dd>
-    <p>
-    本参数指出基于流复制的延迟检查的间隔，单位为秒。
-    默认为 0，表示禁用这个检查。
-    </p>
-    <p>
-    如果你修改了 sr_check_period，需要重新加载 pgpool.conf 以使变动生效。
-    </p>
-    </dd>
-
-<dt id="SR_CHECK_USER">sr_check_user <span class="version">V3.1 -</span></dt>
-    <dd>
-    <p>
-    执行基于流复制检查的用户名。用户必须存在于所有的 PostgreSQL 后端上，否则，检查将出错。
-    注意即使 sr_check_period 为 0， sr_check_user 和 sr_check_password 也会被使用。
-    要识别主服务器，pgpool-II 发送函数调用请求到每个后端。
-    sr_check_user 和 sr_check_password 用于这个会话。
-    </p>
-    <p>
-    如果你修改了 sr_check_user，需要重新加载 pgpool.conf 以使变动生效。
-    </p>
-    </dd>
-
-<dt id="SR_CHECK_PASSWORD">sr_check_password <span class="version">V3.1 -</span></dt>
-    <dd>
-    <p>
-    执行流复制检测的用户的密码。如果不需要密码，则指定空串（''）。
-    </p>
-    <p>
-    如果你改变了 sr_check_password，你需要重新加载 pgpool.conf。
-    </p>
-    </dd>
-
-<dt id="SR_CHECK_DATABASE">sr_check_database <span class="version">V3.5 -</span></dt>
-    <dd>
-    <p>
-    执行流复制延迟检测的数据库。默认为“postgres”（这是 3.4 或者以前版本使用的内置数据库名）。
-    </p>
-    <p>
-    如果你改变了 sr_check_database，你需要重新加载 pgpool.conf。
-    </p>
-    </dd>
-
-<dt id="LOG_STANDBY_DELAY">log_standby_delay <span class="version">V3.1 -</span></dt>
-    <dd>
-    <p>
-        指出如何记录复制延迟。如果指定 'none'，则不写入日志。
-        如果为 'always'，在每次执行复制延迟检查时记录延迟。
-        如果 'if_over_threshold' 被指定，只有当延迟到达 <a href="#DELAY_THRESHOLD">delay_threshold</a> 时记录日志。
-        log_standby_delay 的默认值为 'none'。
-    </p>
-    <p>
-    如果你改变了 log_standby_delay，你需要重新加载 pgpool.conf。
-    </p>
-    <p>
-        你也可以使用“<a href="#pool_status">show pool_status</a>”命令监控复制延迟。
-        列名为“standby_delay#”（其中 '#' 需要用数据库节点编号代替）。
-    </p>
-    </dd>
-</dl>
-
-<h2>流复制下的故障切换</h2>
-<p>
-在使用流复制的主/备模式中，如果主节点或者备节点失效，pgpool-II 可以被设置为触发一个故障切换。节点可以被自动断开而不需要进行更多设置。
-当进行流复制的时候，备节点检查一个“触发文件”的存在，一旦发现它，则备节点停止持续的恢复并进入读写模式。通过使用这种功能，我们可以使备数据库在主节点失效的时候进行替换。
-</p>
-<p>
-<strong>警告：如果你计划使用多个备节点，我们建议设置一个 delay_threshold 值来避免任何查询由于查询被发送到其他备节点而导致获取旧数据。
-</p>
-<p>
-如果第二个备节点在第一个备节点已经发生替换的时候替换主节点，你会从第二备节点获取错误的数据。我们不推荐计划使用这种配置。
-</strong>
-</p>
-<p>
-以下例举了如何设置一个故障切换的配置。
-</p>
-<p>
-<ol>
-    <li>将一个故障切换脚本放置到某个地方（例如 /usr/local/pgsql/bin ）并给它执行权限。
-<pre>
-$ cd /usr/loca/pgsql/bin
-$ cat failover_stream.sh
-#! /bin/sh
-# Failover command for streaming replication.
-# This script assumes that DB node 0 is primary, and 1 is standby.
-#
-# If standby goes down, do nothing. If primary goes down, create a
-# trigger file so that standby takes over primary node.
-#
-# Arguments: $1: failed node id. $2: new master hostname. $3: path to
-# trigger file.
-
-failed_node=$1
-new_master=$2
-trigger_file=$3
-
-# Do nothing if standby goes down.
-if [ $failed_node = 1 ]; then
-    exit 0;
-fi
-
-# Create the trigger file.
-/usr/bin/ssh -T $new_master /bin/touch $trigger_file
-
-exit 0;
-
-chmod 755 failover_stream.sh
-</pre>
-    </li>
-
-    <li>在 pgpool.conf 中设置 <a href="#FAILOVER_COMMAND">failover_commmand</a>。
-<pre>
-failover_command = '/usr/local/src/pgsql/9.0-beta/bin/failover_stream.sh %d %H /tmp/trigger_file0'
-</pre>
-    </li>
-
-    <li>在备节点中设置 recovery.conf。
-    <a href="recovery.conf.sample">一个 recovery.conf 示例</a> 可以在 PostgreSQL 安装目录中找到。
-    它的名字为 "share/recovery.conf.sample"。
-    拷贝 recovery.conf.sample 为 recovery.conf 到数据库节点目录并编辑它。
-<pre>
-standby_mode = 'on'
-primary_conninfo = 'host=name of primary_host user=postgres'
-trigger_file = '/tmp/trigger_file0'
-</pre>
-    </li>
-
-    <li>设置主节点上的 postgresql.conf 。以下仅仅是一个示例。你需要根据你自己的环境做调整。
-<pre>
-wal_level = hot_standby
-max_wal_senders = 1
-</pre>
-    </li>
-
-    <li>设置主节点上的 pg_hba.conf 。以下仅仅是一个示例。你需要根据你自己的环境做调整。
-<pre>
-host    replication    postgres        192.168.0.10/32        trust
-</pre>
-    </li>
-
-</ol>
-
-<p>
-启动首要 PostgreSQL 节点和第二 PostgreSQL 节点来初始化基于流复制。如果主节点失效，备节点将自动启动为普通 PostgreSQL 并准备好接受写查询。
-</p>
-
-<h2>流复制</h2>
-<p>
-当使用流复制和热备的时候，确定哪个查询可以被发送到主节点或备节点或者不能被发送到备节点非常重要。pgpool-II 的流复制模式可以很好的处理这种情况。在本章，我们将解释 pgpool-II 如何做到这一点的。
-</p>
-<p>
-我们通过检查查询来辨别哪个查询应该被发送到哪个节点。
-</p>
-<p>
-<ul>
-    <li>这些查询只允许被发送到主节点
-    <ul>
-       <li>INSERT, UPDATE, DELETE, COPY FROM, TRUNCATE, CREATE, DROP, ALTER, COMMENT</li>
-       <li>SELECT ... FOR SHARE | UPDATE</li>
-       <li>在事务隔离级别为 SERIALIZABLE 的 SELECT</li>
-       <li>比 ROW EXCLUSIVE MODE 更严厉的 LOCK 命令</li>
-       <li>DECLARE, FETCH, CLOSE</li>
-       <li>SHOW</li>
-       <li>一些事务相关命令：
-           <ul>
-             <li>BEGIN READ WRITE, START TRANSACTION READ WRITE</li>
-             <li>SET TRANSACTION READ WRITE, SET SESSION CHARACTERISTICS AS TRANSACTION READ WRITE</li>
-             <li>SET transaction_read_only = off
-            </ul>
-       </li>
-       <li>两步提交命令：PREPARE TRANSACTION, COMMIT PREPARED, ROLLBACK PREPARED</li>
-       <li>LISTEN, UNLISTEN, NOTIFY</li>
-       <li>VACUUM</li>
-       <li>一些序列生成器操作函数（nextval 和 setval）</li>
-       <li>大对象建立命令</li>
-    </ul>
-    </li>
-
-    <li>这些查询可以被发送到主节点和备节点。
-    如果启用了负载均衡，这些查询可以被发送到备节点。
-    但是，如果设置了 <a href="#DELAY_THRESHOLD">delay_threshold</a> 且复制延迟大于这个值，
-    则查询被发送到主节点。
-    <ul>
-       <li>SELECT not listed above</li>
-       <li>COPY TO</li>
-    </ul>
-    </li>
-
-    <li>以下查询被同时发送到主节点和备节点
-   <ul>
-       <li>SET</li>
-       <li>DISCARD</li>
-       <li>DEALLOCATE ALL</li>
-   </ul>
-   </li>
-</ul>
-</p>
-
-<p>
-在一个显式的事务中：
-</p>
-<ul>
-    <li>启动事务的命令例如 BEGIN 只被发送到主节点。</li>
-    <li>接下来的 SELECT 和一些可以被发送到主节点或备节点的其他查询会在事务中执行或者在备节点中执行。</li>
-    <li>无法在备节点中执行的命令例如 INSERT 被发送到主节点。在这些命令之后的命令，即使是 SELECT 也被发送到主节点。这是因为这些 SELECT 语句可能需要立即查看 INSERT 的结果。这种行为一直持续到事务关闭或者终止。
-</ul>
-
-<p>
-在扩展协议中，在负载均衡模式中在分析查询时，有可能探测是否查询可以被发送到备节点。规则和非扩展协议下相同。例如，INSERT 被发送到主节点。接下来的 bind，describe 和 execute 也将被发送到主节点。
-</p>
-
-<p>
-[注：如果对 SELECT 语句的分析由于负载均衡被发送到备节点，然后一个 DML 语句，例如一个 INSERT ，被发送到 pgpool-II，那么，被分析的 SELECT 必须在主节点上执行。因此，我们会在主节点上重新分析这个 SELECT 语句。]
-</p>
-<p>
-最后，pgpool-II 的分析认为有错误的查询将被发送到主节点。
-</p>
-
-<p>
-在指定负载均衡的时候，你可以使用数据库名和应用程序名而达到更小的粒度。
-</p>
-
-<p>
-<dl>
-  <dt id="DATABASE_REDIRECT_PREFERENCE_LIST">database_redirect_preference_list <span class="version">V3.4 -</span></dt>
-    <dd>
-    <p>
-      你可以成对设置 "database name:node id" 来指定在连接到数据库时候使用的节点编号。
-      例如，指定 "test:1"，则 pgpool-II 在连接到 "test" 数据库的时候总是将 SELECT 语句重定向到节点 1。
-      你可以指定多个用逗号(,)分隔的 "database name:node id" 参数对。
-      数据库名允许使用正则表达式。
-      关键字 "primary" 表示主节点，关键字 "standby" 表示备节点。
-    </p>
-    <p>
-      示例如下：
-    <pre>
-database_redirect_preference_list = 'postgres:primary,mydb[01]:1,mydb2:standby'
-    </pre>
-    </p>
-    <p>
-      连接到 postgres 数据库时 SELECT 语句将被重定向到主节点。
-      连接到 mydb0 或者  mydb1 将重定向 SELECT 语句到节点 1。
-      连接到 mydb2 将重定向 SELECT 语句重定向到一个备节点。
-    </p>
-    <p>
-    要使对本参数的改动生效，你需要重新加载 pgpool.conf。
-    </p>
-    </dd>
-
-  <dt id="APP_NAME_REDIRECT_PREFERENCE_LIST">app_name_redirect_preference_list <span class="version">V3.4 -</span></dt>
-    <dd>
-    <p>
-      你可以成对设置 "application name:node id" 来指定应用程序使用的节点编号。
-      "Application name" 是客户端连接到数据库时指定的一个名称。
-      你可以在 PostgreSQL 9.0 或以后的版本中使用。
-    </p>
-    <p>
-      <blockquote>
-	<font color="red">注意：</font>
-	即使为 JDBC 驱动指定了“ApplicationName”选项以及“assumeMinServerVersion=9.0”选项，
-	postgresql-9.3 以及以前版本的 JDBC 驱动在启动包中不会发送应用程序名，因此也无法使用这个功能。
-	如果你希望使用这个功能，请使用 postgresql-9.4 或者之后版本的驱动。
-      </blockquote>
-    </p>
-    <p>
-      例如，psql 命令的名称是 "psql"。
-      pgpool-II 只能识别客户端在初始数据包中包含的应用程序名。
-      客户端可以在之后发送应用程序名但 pgpool-II 无法识别它。
-    </p>
-    <p>
-      app_name_redirect_preference_list 的概念和 app_name_redirect_preference_list 相同。
-      因此你也可以使用正则表达式来匹配应用程序名。
-    </p>
-    <p>
-      以下为一个示例：
-    <pre>
-app_name_redirect_preference_list = 'psql:primary,myapp1:1,myapp2:standby'
-    </pre>
-    </p>
-    <p>
-      本例中， psql 的 SELECT 语句被发送到主节点，myapp1 的发送到节点 1，myapp2 的发送到备节点。
-    </p>
-    <p>
-      app_name_redirect_preference_list 的优先级高于 database_redirect_preference_list。
-      例如：
-      <pre>
-        database_redirect_preference_list = 'bigdb:primary'
-        app_name_redirect_preference_list = 'myapp:2'
-      </pre>
-    </p>
-    <p>
-      应用程序连接到数据库 bigdb 并发送 SELECT 语句到主节点。
-      但是 myapp 发送 SELECT 语句到节点 2，即使它连接到的是 bigdb 数据库。
-      这在脚本中非常有用：myapp2 发送大量繁重的 SELECT 语句以执行分析任务。
-      你想单独使用节点 2 来进行分析工作。
-    </p>
-    <p>
-    要使对本参数的改动生效，你需要重新加载 pgpool.conf。
-    </p>
-    </dd>
-</dl>
-</p>
-
-
-
-<h2 id="online_recovery_in_stream_mode">流复制中的在线恢复</h2>
-<p>
-在流复制的主/备模式中，可以执行在线恢复。在在线恢复过程中，首要务器扮演了主服务器的角色并恢复到指定的备服务器。因此恢复过程需要首要服务器启动并运行。
-如果第一服务器失效且没有备用服务器被提升，你需要停止 pgpool-II 和所有的 PostgreSQL 服务器并手动恢复它们。
-</p>
-
-<p>
-<ol>
-    <li>设置 <a href="#RECOVERY_USER">recovery_user</a>。通常为 "postgres"。
-<pre>
-recovery_user = 'postgres'
-</pre>
-    </li>
-
-    <li>设置登录到数据库的 <a href="#RECOVERY_USER">recovery_user</a> 的 <a href="#RECOVERY_PASSWORD">recovery_password</a>。
-<pre>
-recovery_password = 't-ishii'
-</pre>
-    </li>
-
-    <li>设置 <a href="#RECOVERY_1ST_STAGE_COMMAND">recovery_1st_stage_command</a>。
-        这个阶段的这个脚本用来执行一个首要数据库的备份并还原它到备用节点。
-        将此脚本放置在首要数据库示例的目录中并给它可执行权限。
-        这里有一个用于配置了一个主节点和一个备节点的示例脚本 <a href="basebackup.sh">(basebackup.sh)</a> 。
-        你需要设置 ssh 让 recovery_user 可以从首要节点登录到备用节点而不需要提供密码。
-
-<pre>
-recovery_1st_stage_command = 'basebackup.sh'
-</pre>
-    </li>
-
-    <li>让 <a href="#RECOVERY_2ND_STAGE_COMMAND">recovery_2nd_stage_command</a> 保留为空。
-<pre>
-recovery_2nd_stage_command = ''
-</pre>
-    </li>
-
-    <li>在每个数据库节点中安装必须的执行在线恢复的 C 和 SQL 函数。
-</p>
-
-<pre>
-# cd pgpool-II-x.x.x/sql/pgpool-recovery
-# make
-# make install
-# psql -f pgpool-recovery.sql template1
-</pre>
-
-    <li>在完成在线恢复后，pgpool-II 将在备节点启动 PostgreSQL。
-        在每个数据库节点中安装用于本用途的脚本。
-        <a href="pgpool_remote_start">示例脚本</a> 包含在源码的“sample”目录中。
-        这个脚本使用了 ssh。你需要允许 recover_user 从首要节点登录到备用节点而不需要输入密码。
-    </li>
-</ol>
-</p>
-
-<p>
-以上未全部内容。现在你可以使用 pcp_recovery_node （作为备用节点的步骤）或者点击 pgpoolAdmin 的“恢复”按钮来执行在线恢复了。
-如果出现问题，请检查 pgpool-II 的日子，首要服务器的日志和备用服务器的日志。
-</p>
-
-<p>
-作为参考，以下为恢复过程的步骤。
-<ol>
-    <li>Pgpool-II 使用 user = <a href="#RECOVERY_USER">recovery_user</a>,
-        password = <a href="#RECOVERY_PASSWORD">recovery_password</a>
-        连接到首要服务器的 template1 数据库。
-    </li>
-    <li>首要服务器执行 pgpool_recovery 函数。
-    </li>
-    <li>pgpool_recovery 函数执行 recovery_1st_stage_command。
-        注意 PostgreSQL 在数据库实例的当前目录中执行函数。
-        因此，recovery_1st_stage_command 在数据库实例的目录中执行。
-    </li>
-    <li>首要服务器执行 pgpool_remote_start 函数。
-        本函数执行一个在数据库实例路径中名为“pgpool_remote_start”的脚本，
-        它通过 ssh 在备用服务器上执行 pg_ctl 命令来进行恢复。pg_ctl 将在后台启动 postmaster。
-        所以我们需要确保备用节点上的 postmaster 真正启动了。
-    </li>
-    <li>pgpool-II 尝试使用 user = recovery_user 和 password = recovery_password
-        连接到备用 PostgreSQL。如果可能，连接到的数据库为“postgres”。
-        否则，使用“template1”。pgpool-II 尝试 <a href="#RECOVERY_TIMEOUT">recovery_timeout</a> 秒。
-        如果成功，进行下一步。
-    </li>
-    <li>如果 <a href="#FAILBACK_COMMAND">failback_command</a> 不为空，pgpool-II 父进程执行这个脚本。
-    </li>
-    <li>在 failback_command 完成后，pgpool-II 重新启动所有的子进程。
-    </li>
-</ol>
-</p>
-
-<p class="top_link"><a href="#Top">返回顶部</a></p>
-
-<!-- ================================================================================ -->
-
-<h1><a name="hba"></a>设置用于客户端认证(HBA)的 pool_hba.conf</h1>
-
-<p>
-和 PostgreSQL 中使用的 pg_hba.conf 文件类似，pgpool-II 使用一个称之为 "pool_hba.conf" 的配置文件来支持类似的客户端认证功能。
-</p>
-<p>
-当安装 pgpool 的时候，pool_hba.conf.sample 文件将被安装在"/usr/local/etc"目录下，该位置也是配置文件的默认目录。拷贝 pool_hba.conf.sample 为 pool_hba.conf，如果必要的话并修改它。默认的情况下，<a href="#ENABLE_POOL_HBA">enable_pool_hba</a> 认证被开启。
-</p>
-<p>
-    pool_hba.conf 文件的格式和 PostgreSQL 的 pg_hba.conf 的格式遵循的非常相近。
-</p>
-<pre>
-local      DATABASE  USER  METHOD  [OPTION]
-host       DATABASE  USER  CIDR-ADDRESS  METHOD  [OPTION]
-</pre>
-<p>
-查看 "pool_hba.conf.sample" 文件获取每个字段详细的解释。
-</p>
-<p>
-下面是 pool_hba 的一些限制。
-</p>
-
-<ul>
-<li>DATABASE 字段使用的"samegroup" 不被支持</li>
-    <p>
-    尽管 pgpool 并不知道后端服务器的用户的任何信息，但是将通过 pool_hba.conf 中的 DATABASE 字段项对数据库名进行简单的检查。
-    </p>
-
-<li>USER 字段使用的 group 名字后面跟个"+"不被支持 </li>
-    <p>
-    这与上面介绍的 "samegroup" 原因相同，将通过 pool_hba.conf 中 USER 字段项对用户名进行简单的检查。
-    </p>
-
-<li>为 IP address/mask 使用的 IPv6 不被支持</li>
-    <p>
-    pgpool 当前不支持 IPv6.
-    </p>
-
-<li>METHOD 字段仅仅支持 "trust", "reject", "md5" 和 "pam" </li>
-    <p>
-    再次，这与上面介绍的 "samegroup" 原因相同, pgpool 不能够访问 user/password 信息。
-    </p>
-    <p>
-    要使用md5认证，你需要在 "pool_passwd" 中注册你的名字和密码。详见<a href="#md5">认证/访问控制</a>。
-</ul>
-
-<p>
-    注意本节描述的所有认证发生在客户端和 pgpool-II 之间；客户端仍然需要继续通过 PostgreSQL 的认证过程。
-    pool_hba 并不关心客户端提供的用户名/数据库名（例如 psql -U testuser testdb）是否真实存在于后端服务器中。pool_hba 仅仅关心是否在 pool_hba.conf 中存在匹配。
-</p>
-
-<p>
-    PAM 认证使用 pgpool 运行的主机上的用户信息来获得支持。若让 pgpool 支持PAM，需要在 configure 时指定"--with-pam"选项。
-</p>
-<pre>
-configure --with-pam
-</pre>
-<p>
-  若启用 PAM 认证，你需要为 pgpool 在系统的 PAM 配置目录(通常是在"/etc/pam.d")中创建一个 service-configuration 文件。
-  一个 service-configuration 的示例文件被安装为安装目录下的"share/pgpool.pam"。
-</p>
-
-<!-- ================================================================================ -->
-
-<h1><a name="memqcache"></a> 基于内存的查询缓存 <span class="version">V3.2 -</span></h1>
-
-<p>你可以在任何模式中使用基于内存的查询缓存。它不同于以上的查询缓存，因为基于内存的查询缓存会快很多，因为缓存存储于内存中。
-    另外，如果缓存事小了，你不需要重启 pgpool-II 因为相关的表已经得到更新了。
-</p>
-
-<p>基于内存的缓存保存 SELECT 语句（以及它绑定的参数，如果 SELECT 是一个扩展的查询）以及对应的数据。
-如果是相同的 SELECT 语句，则直接返回缓存的值。因为不再有 SQL 分析或者到 PostgreSQL 的调用，实际上它会非常快。
-</p>
-
-<p>
-其他方面，它会比较慢，因为它增加了一些负载用于缓存。另外，当一个表被更新，pgpool 自动删除相关的表的缓存。
-因此，在有很多更新的系统中，性能会降低。如果 cache_hit_ratio 低于 70%，建议你关闭基于内存的缓存。
-</p>
-
-<h2 id="MEMORY_CACHE_RESTRICTIONS">限制</h2>
-<ul>
-    <li>
-    基于内存的查询缓存通过监视 UPDATE，INSERT，ALTER TABLE一类的查询语句来自动删除缓存的数据。
-    但 pgpool-II 无法发现通过触发器、外键和 DROP TABLE CASCADE 产生的非显式的更新。
-    你可以通过配置 <a href="#MEMQCACHE_EXPIRE">memqcache_expire</a> 让 pgpool 在固定时间周期内自动删除缓存来避免这个问题，
-    你也可以通过配置 <a href="#BLACK_MEMQCACHE_TABLE_LIST">black_memqcache_table_list</a> 来让 pgpool 的基于内存的缓存忽略指定的表。
-    </li>
-
-    <li>
-    如果你使用 pgpool-II 的多个实例来使用共享内存进行缓存，可能出现一个 pgpool 发现表被更新了因而删除了缓存，但另一个依旧使用旧的缓存。
-    对于这种情况，使用 memcached 是一个更好的策略。
-    </li>
-</ul>
-
-<h2 id="MEMORY_CACHE_ENABLED">启用基于内存的查询缓存</h2>
-<p>
-要启用基于内存的查询缓存，设置以下选项为 on（默认为 off）。
-</p>
-
-<pre>
-memory_cache_enabled = on
-</pre>
-
-<h2 id="MEMQCACHE_METHOD">选择缓存存储</h2>
-<p>
-你可以选择一个缓存策略：共享内存或者 <a href="http://memcached.org">memcached</a>（不能同时使用）。
-使用共享内存的查询缓存很快且简单，因为你不需要安装和配置 memcached，但缓存的最大数量限制于共享内存。
-使用 memcached 的查询缓存需要更多的负载用于访问网络，但你可以任意设置你需要的大小。
-</p>
-<p>
-可以通过 memqcache_method 指定内存缓存的行为。可以是 “shmem”（共享内存） 或者 “memcached”。默认为 shmem。
-</p>
-<pre>
-memqcache_method = 'shmem'
-</pre>
-
-
-<h2 id="memqcache_cases">基于内存缓存被禁用的情况</h2>
-<p>
-并非所有的 SELECT 和 WITH 语句可以被缓存。在包括以下列表的一些情况，为了保证数据库和缓存的一致性，缓存被避免了。
-</p>
-<ul>
-    <li>SELECT 语句以 "/*NO QUERY CACHE*/" 注释开始</li>
-    <li>SELECT 包含以下表的 <a href="#BLACK_MEMQCACHE_TABLE_LIST">black_memqcache_table_list</a></li>
-    <li>SELECT FOR SHARE / UPDATE</li>
-    <li>SELECT 包含 un-immutable 函数</li>
-    <li>SELECT 包含 TEMP TABLE</li>
-    <li>SELECT 包含 系统对象</li>
-      <li>SELECT 包含 VIEW 和 不记录日志的表。但如果表在 <a href="#WHITE_MEMQCACHE_TABLE_LIST">white_memqcache_table_list</a> 中，结果还是会被缓存的。</li>
-
-    <li>SELECT 包含 VIEW </li>
-    <li>SELECT 在一个被终止的显示事务中</li>
-    <li>SELECT 结果超出 <a href="#MEMQCACHE_MAXCACHE">memqcache_maxcache</a></li>
-</ul>
-
-<h2 id="non_memqcache_case">缓存不被使用的情况</h2>
-<p>
-存在一些情况，及时匹配的查询缓存存在，pgpool 也不返回结果。
-</p>
-<ul>
-    <li>如果一个更新擦做在一个显式的事务中执行，在事务中，pgpool 不使用查询缓存。</li>
-    <li>匹配的查询是由其他用户（因为安全原因）生成的。</li>
-    <li>匹配的查询由于 <a href="#MEMQCACHE_EXPIRE">memqcache_expire</a> 设置而需要被删除。</li>
-</ul>
-
-<h2 id="memqcache_params">配置</h2>
-
-<p>
-以下参数可以同时用于 shmem 和 memcached。
-</p>
-
-<dl>
-<dt id="MEMQCACHE_EXPIRE">memqcache_expire <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    查询缓存的生命周期，默认为 0。0 表示没有缓存超时，而且缓存被启用直到表被更新。
-    本参数和 <a href="#MEMQCACHE_AUTO_CACHE_INVALIDATION">memqcache_auto_cache_invalidation</a> 是相交的。
-    </p>
-    </dd>
-
-<dt id="MEMQCACHE_AUTO_CACHE_INVALIDATION">memqcache_auto_cache_invalidation
-<span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    如果为 on，则在表被更新的时候自动删除相关的缓存。
-    如果为 off，则不删除缓存。默认为 on。
-    本参数和 <a href="#MEMQCACHE_EXPIRE">memqcache_expire</a> 相交。
-    </p>
-    </dd>
-
-<dt id="MEMQCACHE_MAXCACHE">memqcache_maxcache <span class="version">V3.2 -</span></dt>
-    <dd>
-        <p>
-        如果 SELECT 结果集的大小超出了 memqcache_maxcache 字节，则不缓存且显示以下消息：
-        </p>
-<pre>
-2012-05-02 15:08:17 LOG:   pid 13756: pool_add_temp_query_cache: data size exceeds memqcache_maxcache. current:4095 requested:111 memq_maxcache:4096
-</pre>
-        <p>
-        要避免这个问题，你需要将 memqcache_maxcache 设置得大一些。
-        但如果你使用共享内存作为缓存策略，它必须小于 <a href="#MEMQCACHE_CACHE_BLOCK_SIZE">memqcache_cache_block_size</a>。
-        如果是 memchached，她必须小于 slab 的大小（默认为 1 MB）。
-        </p>
-    </dd>
-
-<dt id="WHITE_MEMQCACHE_TABLE_LIST">white_memqcache_table_list <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    指定一个以逗号分隔的表名的列表，用于使 SELECT 的结果被缓存，也可以是视图或者不写日志的表。可以使用正则表达式。
-    </p>
-    <p>
-    同时存在于 white_memqcache_table_list 和 <a href="#BLACK_MEMQCACHE_TABLE_LIST">black_memqcache_table_list</a> 的表和视图将被缓存。
-    </p>
-    </dd>
-
-<dt id="BLACK_MEMQCACHE_TABLE_LIST">black_memqcache_table_list <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-        指定一个以逗号分隔的表名的列表，用于使 SELECT 的结果不被缓存，也可以是视图或者不写日志的表。可以使用正则表达式。
-    </p>
-    </dd>
-
-<dt id="MEMQCACHE_OIDDIR">memqcache_oiddir <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    用于 SELECT 的存储表的 OID 的目录的完整路径。在 memqcache_oiddir 下有使用数据库 oid 命名的目录，
-    每个目录之下是在 SELECT 中使用的以表的 oid 命名的文件。在文件中，存储了查询缓存。它们是用于删除缓存的关键。
-    </p>
-    <p>
-    在 memqcache_oiddir 下的目录和文件不会被删除，即使 pgpool-II 重启。
-    如果你使用 "<a href="#start">pgpool -C</a>" 启动 pgpool，则 pgpool 使用旧的 oid 映射。
-    </p>
-    </dd>
-</dl>
-
-<h2 id="monitoring_memqcache">监控缓存</h2>
-<p>
-这里讲述如何监控查询缓存。要知道一个 SELECT 的结果是不是从查询缓存获得，需要启用 <a href="#LOG_PER_NODE_STATEMENT">log_per_node_statement</a>。
-</p>
-<pre>
-2012-05-01 15:42:09 LOG:   pid 20181: query result fetched from cache. statement: select * from t1;
-</pre>
-
-<p>
-<a href="#pool_status">pool_status</a> 命令显示缓存的命中率。
-</p>
-<pre>
-memqcache_stats_start_time           | Tue May  1 15:41:59 2012 | Start time of query cache stats
-memqcache_no_cache_hits              | 80471                    | Number of SELECTs not hitting query cache
-memqcache_cache_hits                 | 36717                    | Number of SELECTs hitting query cache
-</pre>
-
-
-<p>
-在本例中，你可以通过以下方法计算：
-</p>
-<p>
-<pre>
-(memqcache_cache_hits) / (memqcache_no_cache_hits+memqcache_cache_hits) = 36717 / (36717 + 80471) = 31.3%
-</pre>
-
-<p>
-<a href="#pool_cache">show pool_cache</a> 也显示相同的结果。
-</p>
-
-<h2 id="shmem_params">配置使用共享内存</h2>
-<p>
-以下为用于共享内存缓存策略的参数。
-</p>
-
-<dl>
-<dt id="MEMQCACHE_TOTAL_SIZE">memqcache_total_size <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    指定用于缓存的共享内存的大小，单位为字节。
-    </p>
-    </dd>
-
-<dt id="MEMQCACHE_MAX_NUM_CACHE">memqcache_max_num_cache <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    制定缓存的项目数。这用于定义缓存管理空间的大小。（你需要它来协助 <a href="#MEMQCACHE_TOTAL_SIZE">memqcache_total_size</a> 参数）。
-    可以使用以下方法计算缓存管理空间的大小：<a href="#MEMQCACHE_MAX_NUM_CACHE">memqcache_max_num_cache</a> * 48 字节。
-    如果数量太小，则注册缓存的时候会报错。但如果太大则浪费空间。
-    </p>
-    </dd>
-
-<dt id="MEMQCACHE_CACHE_BLOCK_SIZE">memqcache_cache_block_size <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    如果缓存存储是共享内存，pgpool 使用内存除以 memqcache_cache_block_size。SELECT 的结果被放入块中。
-    但是因为 SELECT 的结果不能被放入多个块中，它无法缓存大于 memqcache_cache_block_size 的结果。
-    memqcache_cache_block_size 必须大于或等于 512。
-    </p>
-    </dd>
-</dl>
-
-<h2 id="memcached_params">配置使用 memcached</h2>
-
-<p>
-以下为用于 memcached 缓存策略的参数。
-</p>
-
-<dl>
-<dt id="MEMQCACHE_MEMCACHED_HOST">memqcache_memcached_host <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    指定 memcached 工作的主机的主机名或 IP 地址。如果和 pgpool-II 在同一台机器，设置为 'localhost'。
-    </p>
-    </dd>
-
-<dt id="MEMQCACHE_MEMCACHED_PORT">memqcache_memcached_port <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    指定 memcached 的端口。默认为 11211。
-    </p>
-    </dd>
-</dl>
-
-
-<h3 id="install_memcached">memcached 安装</h3>
-
-<p>
-要使用 memcached 作为缓存策略，pgpool-II 需要配合 memcached 和其客户端 libmemcached 使用。
-通过 rpm 安装很简单。这里讲解如何使用源码安装。
-</p>
-
-<p>
-可以在以下位置获得 memcached 的源码：
-<a href="http://memcached.org/">memcached development page</a>
-</p>
-
-<dl>
-<dt>configure</dt>
-    <dd>
-    <p>
-    在解压源码包后，执行配置脚本。
-    </p>
-<pre>
-./configure
-</pre>
-    </dd>
-
-<dt>make</dt>
-    <dd>
-<pre>
-make
-make install
-</pre>
-    </dd>
-</dl>
-
-<h3 id="install_libmemcached">libmemcached 安装</h3>
-
-<p>
-Libmemcached 是 memcached 的客户端库。你需要在安装 memcached 后安装 libmemcached。
-</p>
-
-<p>
-可以在以下位置获得 libmemcached 的源码：
-<a href="http://libmemcached.org/libMemcached.html">libmemcached development page</a>
-</p>
-
-<dl>
-<dt>configure</dt>
-    <dd>
-    <p>
-    在解压源码包后，执行配置脚本。
-    </p>
-<pre>
-./configure
-</pre>
-
-    <p>
-    如果你不想使用默认值，一些可选项为：
-    </p>
-
-    <ul>
-        <li><code>--with-memcached=path</code><br/>
-        安装 Memcached 的顶层目录。</li>
-    </ul>
-    </dd>
-
-<dt>make</dt>
-    <dd>
-<pre>
-make
-make install
-</pre>
-    </dd>
-</dl>
-
-<p class="top_link"><a href="#Top">回到顶部</a></p>
-
-<!-- ================================================================================ -->
-
-<h1>启动/停止 pgpool-II<a name="start"></a></h1>
-
-<h2 id="start_pgpool">启动 pgpool-II</h2>
-
-<p>所有后端服务都必须在启动 pgpool-II 之前启动。
-</p>
-
-<pre>
-pgpool [-c][-f config_file][-a hba_file][-F pcp_config_file][-n][-D][-d]
-</pre>
-
-<table border>
-  <tr><td>-c</td><td>--clear-cache</td>
-      <td>删除 query cache</td></tr>
-  <tr><td>-f config_file</td><td>--config-file config-file</td>
-      <td>指定 pgpool.conf</td></tr>
-  <tr><td>-a hba_file</td><td>--hba-file hba_file</td>
-       <td>指定 pool_hba.conf</tr>
-  <tr><td>-F pcp_config_file</td><td>--pcp-password-file</td>
-      <td>指定 pcp.conf</td></tr>
-  <tr><td>-n</td><td>--no-daemon</td>
-      <td>非守护进程模式（不脱离终端运行）</td></tr>
-  <tr><td>-D</td><td>--discard-status</td>
-      <td>忽略 pgpool_status 文件且不恢复到先前的状态
-      <span class="version">V3.0 -</span></td></tr>
-  <tr><td>-C</td><td>--clear-oidmaps</td>
-      <td>忽略用于基于内存的查询缓存的 <a href="#MEMQCACHE_OIDDIR">memqcache_oiddir</a> 中的 oid 映射文件
-      （仅当 <a href="#MEMQCACHE_METHOD">memqcache_method</a> 为 'memcached'时有效），
-      如果是 shm，则总是忽略。
-      <span class="version">V3.2 -</span></td></tr>
-  <tr><td>-d</td><td>--debug</td><td>调试模式</tr>
-      <tr><td>-x</td><td>--debug-assertions</td>
-      <td>启用变量断言(assertion)检查，本功能用于调试</td></tr>
-</table>
-
-<h2 id="stop_pgpool">Stop pgpool-II</h2>
-<p>
-有两种方式来关闭 pgpool-II。一种是使用 PCP 命令（后面介绍），另外一种是使用 pgpool-II 命令。下面是使用 pgpool-II 命令的示例。
-</p>
-
-<pre>
-pgpool [-f config_file][-F pcp_config_file] [-m {s[mart]|f[ast]|i[mmediate]}] stop
-</pre>
-
-<table border>
-  <tr><td><code>-m s[mart]</code></td><td><code>--mode s[mart]</code></td>
-      <td>等待客户端断开连接，然后关闭(默认)</td></tr>
-  <tr><td><code>-m f[ast]</code></td><td><code>--mode f[ast]</code></td>
-      <td>并不等待客户端; 立即关闭</td></tr>
-  <tr><td><code>-m i[mmediate]</code></td><td><code>--mode i[mmediate]</code></td>
-      <td>等同于 <code>'-m f'</code></td></tr>
-</table>
-
-<p>
-    pgpool 记录后端服务器的状态到 [logdir]/pgpool_status 文件中，当 pgpool 重启时，它读该文件并恢复后端服务器的状态。
-    这将避免可能由于下述原因造成的DB节点间的具有不同的数据：
-<p>
-pgpool 记录后端服务器的状态到 [logdir]/pgpool_status 文件中。
-从 pgpool-II 3.4.0 开始，pgpool_status 文件的格式发生了变化：它是一个文本文件了，你可以使用你最喜欢的文本编辑器读取或者编辑它。
-例如，你可以添加新的后端并重启 pgpool-II，你可能要等很久才能等到 pgpool-II 探测到新的后端并执行故障转移。
-通过编辑 pgpool_status 来设置后端为停机状态，你可以避免以上情况，因为 pgpool-II 的健康检查跳过了已停机的节点。
-文件中的每行对应每个后端节点的状态。
-第一个后端的状态在第一行，第二个后端的状态在第二行，以此类推。
-后端状态包含："up"、"down"、"unused" (表示忽略)。
-以下为一个 pgpool_status 文件的示例：
-<pre>
-up
-down
-up
-</pre>
-</p>
-
-<p>
-注意 pgpool-II 3.4.0 之前的版本中使用二进制的 pgpool_status 文件。pgpool-II 3.4.0 及以后版本也可以读这个文件。但是 pgpool-II 3.4.0 之前的版本无法读 ASCII 格式的 pgpool_status 文件。
-</p>
-
-<p>
-当 pgpool 重启的时候，它读取这个文件并恢复后端节点的状态。
-这将避免可能由于下述原因造成的DB节点间的具有不同的数据：
-</p>
-<ol>
-    <li>一个后端服务器突然停止，然后pgpool执行恢复程序
-    <li>一个update通过pgpool出现在一个活动的DBs上
-    <li>管理员决定停止pgpool
-    <li>其它人决定重启已停止的DB但并没通知管理员
-    <li>管理员重启pgpool
-</ol>
-
-<p>
-    如果由于某些原因，例如，停止的DB已经通过其它另外的方式已经获得了同步，则 pgpool_status 可在启动 pgpool 之前被安全的移除。
-</p>
-
-<p class="top_link"><a href="#Top">回到顶部</a></p>
-
-<!-- ================================================================================ -->
-
-<h1>重新加载 pgpool-II 配置文件<a name="reload"></a></h1>
-<p>pgpool-II 能够不需要重启而重新加载配置文件。
-</p>
-
-<pre>
-pgpool [-c][-f config_file][-a hba_file][-F pcp_config_file] reload
-</pre>
-<p>
-
-<table border>
-  <tr><td>-f config_file</td><td>--config-file config-file</td><td>指定 pgpool.conf</tr>
-  <tr><td>-a hba_file</td><td>--hba-file hba_file</td><td>指定 pool_hba.conf</tr>
-  <tr><td>-F pcp_config_file</td><td>--pcp-password-file</td><td>指定 pcp.conf</tr>
-</table>
-
-<p>
-    需要指出的是，一些配置项并不能通过重新加载来改变。新的修改后的配置将在新会话上生效。
-</p>
-
-<p class="top_link"><a href="#Top">回到顶部</a></p>
-
-<!-- ================================================================================ -->
-
-<h1><a name="show-commands"></a>SHOW 命令</h1>
-<h2>概述</h2>
-<p>
-pgpool-II 通过 SHOW 命令提供一些信息。SHOW 是一个真实的 SQL 语句, 但是如果该命令查询 pgpool-II 信息的话，pgpool-II 解释了该命令。可用选项如下:
-<ul>
-  <li>pool_status, 获取配置</li>
-  <li>pool_nodes, 获取节点信息 <span class="version">V3.0 -</span></li>
-  <li>pool_processes, 获取pgPool-II 进程信息 <span class="version">V3.0 -</span></li>
-  <li>pool_pools, 获取pgPool-II 所有的连接池信息 <span class="version">V3.0 -</span></li>
-  <li>pool_version, 获取pgPool_II 版本信息 <span class="version">V3.0 -</span></li>
-</ul>
-<p>除 "pool_status" 之外的选项都是从 pgpool-II 3.0 开始添加的。
-<p>
-<u>注意</u>：术语 'pool' 指的是一个 pgpool 进程所拥有的 PostgreSQL 会话池，并非指所有的 pgpool 所拥有的会话。
-</p>
-</p>
-<p>SQL语句中的 "pool_status" 在以前的版本中已经存在，但是其它可选项在 3.0 中才出现。
-</p>
-<h2>pool_status</h2>
-<p>"SHOW pool_status" 返回配置参数列表，包含参数的 name, value, 和 description。下面是返回结果的一个摘录:
-<pre>
-benchs2=# show pool_status;
-                 item                 |             value              |                           description
---------------------------------------+--------------------------------+------------------------------------------------------------------
- listen_addresses                     | localhost                      | host name(s) or IP address(es) to listen to
- port                                 | 9999                           | pgpool accepting port number
- socket_dir                           | /tmp                           | pgpool socket directory
- pcp_port                             | 9898                           | PCP port # to bind
- pcp_socket_dir                       | /tmp                           | PCP socket directory
-</pre>
-</p>
-<h2 id="pool_nodes">pool_nodes <span class="version">V3.0 -</span></h2>
-<p>"SHOW pool_nodes" 返回所有配置节点的列表。
-它显示了节点的 id，hostname，port，status 以及权重 weight (仅在使用负载均衡模式时有意义)，
-角色和在每个后端上执行的 SELECT 查询计数。
-status 列可能的值可在 <a href="#pcp_node_info">pcp_node_info reference</a> 里获得解释。
-如果 hostname 类似于“/tmp”，则意味着 pgpool-II 使用域套接字连接后端。
-SELECT 计数在每次 pgpool-II 重启后会被重置为零。
-</p>
-<pre>
-benchs2=# show pool_nodes;
- node_id | hostname | port  | status | lb_weight |  role   | select_cnt
----------+----------+-------+--------+-----------+---------+------------
- 0       | /tmp     | 11002 | 2      | 0.500000  | primary | 9231
- 1       | /tmp     | 11003 | 2      | 0.500000  | standby | 9469
-(2 rows)
-</pre>
-
-<h2>pool_processes <span class="version">V3.0 -</span></h2>
-<p>"SHOW pool_processes" 返回 pgpool-II 所有进程的信息，这些进程正等待连接或在处理一个连接。
-</p>
-<p>
-结果有 6 列:
-<ul>
-    <li>pool_pid 是显示的pgPool-II进程的PID</li>
-    <li>start_time 是该进程启动时的时间戳</li>
-    <li>database 是该进程当前连接的活跃的后台数据库名</li>
-    <li>username 是该进程当前连接的活跃的后台用户名</li>
-    <li>create_time 是连接的的创建时间和日期</li>
-    <li>pool_counter 计数客户端使用该连接池（进程）的次数</li>
-</ul>
-</p>
-<p>结果将一直返回 num_init_children 行。</p>
-<pre>
-benchs2=# show pool_processes;
- pool_pid |     start_time      | database | username  |     create_time     | pool_counter
-----------+---------------------+----------+-----------+---------------------+--------------
- 8465     | 2010-08-14 08:35:40 |          |           |                     |
- 8466     | 2010-08-14 08:35:40 | benchs   | guillaume | 2010-08-14 08:35:43 | 1
- 8467     | 2010-08-14 08:35:40 |          |           |                     |
- 8468     | 2010-08-14 08:35:40 |          |           |                     |
- 8469     | 2010-08-14 08:35:40 |          |           |                     |
-(5 lines)
-</pre>
-<h2>pool_pools <span class="version">V3.0 -</span></h2>
-<p>"SHOW pool_pools" 返回 pgpool-II 所处理的连接池列表，包含它们的 name, value, 和 description，下面是结果的一个摘录：
-</p>
-<p>
-共 11 列:
-<ul>
-<li>pool_pid 是 pgpool-II 进程的PID</li>
-<li>start_time 是该进程启动时的时间和日期</li>
-<li>pool_id is 是连接池的标识符 (应该在 0 到 max_pool-1之间)</li>
-<li>backend_id 是后端服务器的标识符(应该在0到最大配置的后端服务器数-1之间)</li>
-<li>database 是该进程的连接池所连接的数据库名</li>
-<li>username 是该进程的连接池所连接的用户名</li>
-<li>create_time 是该连接的创建时间和日期</li>
-<li>majorversion and minorversion 是该连接使用的协议版本</li>
-<li>pool_counter 计数客户端使用该连接的次数</li>
-<li>pool_backendpid 是PostgreSQL 进程的PID </li>
-<li>pool_connected 如果前端正使用该后端服务器时是true (1).</li>
-</ul>
-</p>
-<p>结果将一直返回 <a href="#NUM_INIT_CHILDREN">num_init_children</a> * <a href="#MAX_POOL">max_pool</a> * number_of_backends 行.</p>
-<pre>
-  pool_pid |     start_time      | pool_id | backend_id | database | username  |     create_time     | majorversion | minorversion | pool_counter | pool_backendpid | pool_connected
-----------+---------------------+---------+------------+----------+-----------+---------------------+--------------+--------------+--------------+-----------------+----------------
- 8465     | 2010-08-14 08:35:40 | 0       | 0          |          |           |                     |              |              |              |                 |
- 8465     | 2010-08-14 08:35:40 | 1       | 0          |          |           |                     |              |              |              |                 |
- 8465     | 2010-08-14 08:35:40 | 2       | 0          |          |           |                     |              |              |              |                 |
- 8465     | 2010-08-14 08:35:40 | 3       | 0          |          |           |                     |              |              |              |                 |
- 8466     | 2010-08-14 08:35:40 | 0       | 0          | benchs   | guillaume | 2010-08-14 08:35:43 | 3            | 0            | 1            | 8473            | 1
- 8466     | 2010-08-14 08:35:40 | 1       | 0          |          |           |                     |              |              |              |                 |
- 8466     | 2010-08-14 08:35:40 | 2       | 0          |          |           |                     |              |              |              |                 |
- 8466     | 2010-08-14 08:35:40 | 3       | 0          |          |           |                     |              |              |              |                 |
- 8467     | 2010-08-14 08:35:40 | 0       | 0          |          |           |                     |              |              |              |                 |
- 8467     | 2010-08-14 08:35:40 | 1       | 0          |          |           |                     |              |              |              |                 |
- 8467     | 2010-08-14 08:35:40 | 2       | 0          |          |           |                     |              |              |              |                 |
- 8467     | 2010-08-14 08:35:40 | 3       | 0          |          |           |                     |              |              |              |                 |
- 8468     | 2010-08-14 08:35:40 | 0       | 0          |          |           |                     |              |              |              |                 |
- 8468     | 2010-08-14 08:35:40 | 1       | 0          |          |           |                     |              |              |              |                 |
- 8468     | 2010-08-14 08:35:40 | 2       | 0          |          |           |                     |              |              |              |                 |
- 8468     | 2010-08-14 08:35:40 | 3       | 0          |          |           |                     |              |              |              |                 |
- 8469     | 2010-08-14 08:35:40 | 0       | 0          |          |           |                     |              |              |              |                 |
- 8469     | 2010-08-14 08:35:40 | 1       | 0          |          |           |                     |              |              |              |                 |
- 8469     | 2010-08-14 08:35:40 | 2       | 0          |          |           |                     |              |              |              |                 |
- 8469     | 2010-08-14 08:35:40 | 3       | 0          |          |           |                     |              |              |              |                 |
-(20 lines)
-</pre>
-
-<h2 id="pool_version">pool_version <span class="version">V3.0 -</span></h2>
-<p>"SHOW pool_version" 将显示包含 pgpool-II 版本号的一个字符串。下面是一个示例：</p>
-<pre>
-benchs2=# show pool_version;
-      pool_version
-------------------------
- 3.0-dev (umiyameboshi)
-(1 line)
-</pre>
-
-<h2 id="pool_cache">pool_cache <span class="version">V3.0 -</span></h2>
-<p>"SHOW pool_cache" 显示启用 <a href="#memqcache">on memory query cache</a> 时缓存的存储统计。以下为一个示例：
-</p>
-
-<pre>
-test=# \x
-\x
-Expanded display is on.
-test=# show pool_cache;
-show pool_cache;
--[ RECORD 1 ]---------------+---------
-num_cache_hits              | 891703
-num_selects                 | 99995
-cache_hit_ratio             | 0.90
-num_hash_entries            | 131072
-used_hash_entries           | 99992
-num_cache_entries           | 99992
-used_cache_enrties_size     | 12482600
-free_cache_entries_size     | 54626264
-fragment_cache_entries_size | 0
-</pre>
-
-<ul>
-<li>num_cache_hits  表示命中缓存的 SELECT 语句数量。</li>
-<li>num_selects  表示未命中缓存的 SELECT 语句数量。</li>
-<li>
-cache_hit_ratio  表示缓存的命中率，算法为 num_cache_hits/(num_cache_hits+num_selects)。
-<br>num_hash_entries 之下的任何项目仅仅在缓存为共享内存的情况下有效。
-</li>
-<li>
-num_hash_entries  表示哈希表中的项目数，它用于索引缓存存储，其应该和 pgpool.conf 中的
-<a href="#MEMQCACHE_MAX_NUM_CACHE">memqcache_max_num_cache</a> 相同。这是缓存条目的上限。
-</li>
-<li>used_hash_entries  表示 num_hash_entries 中已经使用的项目。</li>
-<li>num_cache_entries  表示缓存存储中有效的缓存项目数，应该等于 used_hash_entries。</li>
-<li>used_cache_entries_size  表示已经使用的总共缓存存储字节数。</li>
-<li>free_cache_entries_size  表示未使用或者说可用的总共缓存存储字节数。</li>
-<li>fragment_cache_entries_size  表示由于是碎片而无法使用的总共缓存存储字节数。</li>
-<li>如果 free_cache_entries_size 变成 0（或者没有足够的空间存储 SELECT 的结果），则碎片区域可以被重用。</li>
-</ul>
-
-<p class="top_link"><a href="#Top">返回顶部</a></p>
-
-<!-- ================================================================================ -->
-
-<h1><a name="online-recovery"></a>在线恢复</h1>
-<h2>概述</h2>
-<p>
-pgpool-II，在复制模式下在给客户端提供服务的同时，能够同步一个数据库并关联(attach)一个节点，我们称这项特性为"在线恢复"。
-</p>
-
-<p>
-在执行在线恢复之前，一个恢复的目标节点必须处于 detached 状态。如果你想动态的增加一个 PostgreSQL server，则在pgpool.conf中增加'backend_hostname'及其相关的参数并重新加载该配置文件。 pgpool-II 把该新的节点注册为 detached 节点。
-</p>
-
-<p>
-<font color="red">
-注意：停止 master 节点(第一个启动和运行的节点)上的autovacuum。如果Autovacuum运行的话，它可能会改变数据的内容并可能造成在线恢复后的不一致性。这仅适用于使用简单的复制机制的恢复，例如下文将会讨论的 rsync 方式，而对使用 PostgreSQL 的PITR机制进行在线恢复的并不适用。
-</font>
-</p>
-
-<p>
-  若目标 PostgreSQL 服务器已经启动开，你需要关闭它。
-</p>
-
-<p>
-pgpool-II 以两个阶段来执行在线恢复。
-当一个恢复节点同步数据库时，客户端可能需要等待几秒到几分钟不等的时间来连接 pgpool-II。
-下面是这些步骤：
-</p>
-
-<ol>
-    <li> CHECKPOINT</li>
-    <li> 在线恢复的第一阶段</li>
-    <li> 等待所有的客户端连接断开</li>
-    <li> CHECKPOINT</li>
-    <li> 在线恢复的第二阶段</li>
-    <li> 启动 postmaster （执行 <a href="#pool_remote_start">pgpool_remote_start</a>）</li>
-    <li> 节点连接上来</li>
-  </ol>
-
-<p>
-   数据同步的第一个步称之为"第一阶段"。 数据在第一阶段中被同步，在第一阶段中，数据<b>能够</b>被并行的从任意表更新或获取。
-</p>
-
-<p>
-你可以指定第一阶段中执行的脚本。pgpool-II传递三个参数到该脚本中。
-</p>
-
-<ol>
-    <li>主节点的数据库实例路径。
-    <li>被恢复的目标节点的主机名
-    <li>被恢复的目标节点的数据库实例路径
-</ol>
-
-<p>
-数据同步在称之为"第二阶段"中完成。在进入第二阶段前，pgpool-II 等待所有的客户端断开连接。它阻塞所有新来的连接直到第二阶段完成。
-</p>
-<p>
-当所有的连接被中断后，pgpool-II合并在第一和第二阶段中更新的数据。这是同步的最终数据。
-</p>
-
-<p>
-<font color="red">
-注意：关于在线恢复有一个限制。如果 pgpool-II 本身安装在多个主机上，在线恢复则不能正确的工作，这是因为 pgpool-II需要在在线恢复的第二阶段中断所有客户端连接。如果存在多个 pgpool-II 主机，只有一个主机能收到在线恢复命令，然后阻塞连接。
-</font>
-</p>
-
-<h2 id="online_recovery_params">配置在线恢复</h2>
-<p>
-    为在线恢复在pgpool.conf中设置如下参数：
-</p>
-
-<ul>
-    <li><a href="#BACKEND_DATA_DIRECTORY">backend_data_directory</a></li>
-    <li><a href="#RECOVERY_USER">recovery_user</a></li>
-    <li><a href="#RECOVERY_PASSWORD">recovery_password</a></li>
-    <li><a href="#RECOVERY_1ST_STAGE_COMMAND">recovery_1st_stage_command</a></li>
-    <li><a href="#RECOVERY_2ND_STAGE_COMMAND">recovery_2nd_stage_command</a></li>
-</ul>
-
-
-<h2><a name="installing-c-functions"></a>安装c语言函数</h2>
-<p>
-    你需要为在线恢复在所有的后端节点中的"template1"数据库中安装c语言函数。源代码在pgpool-II的压缩包中。
-</p>
-
-<pre>
-pgpool-II-x.x.x/sql/pgpool-recovery/
-</pre>
-
-<p>
-改变相应的目录，并执行"make install"。
-</p>
-
-<pre>
-% cd pgpool-II-x.x.x/sql/pgpool-recovery/
-% make install
-</pre>
-
-<p>
-然后安装 SQL 函数。
-</p>
-
-<pre>
-% cd pgpool-II-x.x.x/sql/pgpool-recovery/
-% psql -f pgpool-recovery.sql template1
-</pre>
-
-
-<h2 id="recovery_script"> 恢复脚本部署 </h2>
-<p>
-    我们必须在数据库实例目录($PGDATA)中部署一些数据同步脚本和一个远程启动脚本。在pgpool-II-x.x.x/sample 目录中可找到一些示例脚本文件。
-</p>
-
-<h3 id="recovery_pitr">通过PITR在线恢复</h3>
-<p>
-本节说明如何通过基于时间点的恢复（Point In Time Recovery，PITR）执行在线恢复。PITR 在 PostgreSQL 8.2 以及后续版本可用。注意所有的涉及的 PostgreSQL 服务器都需要支持 PITR。
-</p>
-<h4>第一阶段</h4>
-<p>
-    需要一个脚本从主节点获取一个备份库，然后把它拷贝到恢复目标节点中去。该脚本可命名为如"copy-base-backup"。下面是个示例：
-</p>
-
-<pre>
-#! /bin/sh
-DATA=$1
-RECOVERY_TARGET=$2
-RECOVERY_DATA=$3
-
-psql -c "select pg_start_backup('pgpool-recovery')" postgres
-echo "restore_command = 'scp $HOSTNAME:/data/archive_log/%f %p'" &gt; /data/recovery.conf
-tar -C /data -zcf pgsql.tar.gz pgsql
-psql -c 'select pg_stop_backup()' postgres
-scp pgsql.tar.gz $RECOVERY_TARGET:$RECOVERY_DATA
-</pre>
-
-<p>
-    该脚本把主数据库设成backup模式，生成如下的 recovery.conf：
-</p>
-<pre>
-restore_command = 'scp master:/data/archive_log/%f %p'
-</pre>
-<p>
-执行备份，接着把主数据库不再设成备份模式，然后拷贝备份库到选择的目标节点。
-</p>
-<h4>第二阶段</h4>
-<p>
-该过程的第二阶段是一个脚本进行强制 XLOG 文件转换。
-该脚本此处命名为"pgpool_recovery_pitr"。它强制执行事务日志的一个转换。
-为此，pg_switch_xlog可能会被用到。
-</p>
-<p><span class="version">V3.1 -</span>
-然而它可能在转换执行完<b>前</b>返回，这样可能会导致在线恢复过程的失败。
-Pgpool-II提供了一个更加安全的称之为"pgpool_switch_xlog"的函数，
-该函数等待一直到事务日志转换实际被完成后。
-pgpool_switch_xlog 在<a href="#installing-c-functions">安装 C 函数</a>小节过程执行时被安装。
-</p>
-
-<p>
-下面是示例脚本。
-</p>
-<pre>
-#! /bin/sh
-# Online recovery 2nd stage script
-#
-datadir=$1       # master dabatase cluster
-DEST=$2          # hostname of the DB node to be recovered
-DESTDIR=$3       # database cluster of the DB node to be recovered
-port=5432        # PostgreSQL port number
-archdir=/data/archive_log    # archive log directory
-
-# Force to flush current value of sequences to xlog
-psql -p $port -t -c 'SELECT datname FROM pg_database WHERE NOT datistemplate AND datallowconn' template1|
-while read i
-do
-  if [ "$i" != "" ];then
-    psql -p $port -c "SELECT setval(oid, nextval(oid)) FROM pg_class WHERE relkind = 'S'" $i
-  fi
-done
-
-psql -p $port -c "SELECT pgpool_switch_xlog('$archdir')" template1
-</pre>
-</p>
-
-<p>
-该序列注入(flushing of sequences)仅在复制模式下有效：在该情况下，序列不得不在所有节点上具有同一个起点。在主/备模式下并不可用。
-</p>
-<p>
-脚本中的循环强制 PostgreSQL 发出所有数据库中序列生成器的当前值到事务日志中，这样它就传播到恢复的目标节点中去。
-</p>
-
-<p>
-我们部署这些脚本到 $PGDATA 目录中去。
-</p>
-<p>
-最后，我们修改pgpool.conf。
-
-<pre>
-recovery_1st_stage_command = 'copy-base-backup'
-recovery_2nd_stage_command = 'pgpool_recovery_pitr'
-</pre>
-
-<p>
-我们已完成通过PITR进行在线恢复的准备工作。
-</p>
-
-<h4 id="pool_remote_start">pgpool_remote_start</h4>
-<p>
-    该脚本启动远程主机的 postmaster 进程。pgpool-II 以如下方式执行。
-</p>
-
-<pre>
-% pgpool_remote_start remote_host remote_datadir
-remote_host:    Hostname of a recovery target.
-remote_datadir: Database cluster path of a recovery target.
-</pre>
-
-<p>
-    在该示例脚本中，我们通过 ssh 启动 postmaster 进程。所以如果你想要它能够运行，你需要提供不需要密码输入的 ssh 连接。
-</p>
-
-<p>
-    如果你使用PITR进行恢复，你需要部署一个库备份。PostgreSQL 将自动启动一个 PITR 恢复，然后它开始接受连接。
-</p>
-
-<pre>
-#! /bin/sh
-DEST=$1
-DESTDIR=$2
-PGCTL=/usr/local/pgsql/bin/pg_ctl
-
-# Deploy a base backup
-ssh -T $DEST 'cd /data/; tar zxf pgsql.tar.gz' 2&gt;/dev/null 1&gt;/dev/null &lt; /dev/null
-# Startup PostgreSQL server
-ssh -T $DEST $PGCTL -w -D $DESTDIR start 2&gt;/dev/null 1&gt;/dev/null &lt; /dev/null &amp;
-</pre>
-
-<h3 id="recovery_rsync">通过 rsync 在线恢复</h3>
-<p>
-    PostgreSQL 7.4 没有PITR ，rsync 可被用来进行在线恢复。在 pgpool-II 的压缩包中的"sample"目录中，有一个"pgpool_recovery"交恢复脚本。该脚本使用rsync命令，pgpool-II使用三个参数调用该脚本。
-</p>
-
-<pre>
-% pgpool_recovery datadir remote_host remote_datadir
-datadir:        Database cluster path of a master node.
-remote_host:    Hostname of a recovery target node.
-remote_datadir: Database cluster path of a recovery target node.
-</pre>
-
-<p>
-    该脚本通过 ssh 使用 rsync 拷贝物理文件。所以你需要提供不需要密码输入的 ssh 连接。
-</p>
-
-<p>
-关于rsync的一些笔记:
-<ul>
- <li>-c (or --checksum) 当可靠文件传输时需要设置该可选项
- <li>-z (or --compress) 该可选项用于传输数据时数据压缩。这可能对低速连接非常棒，但是对于一个 100Mbit 或更快的连接可能会增加太多的 CPU 负担，在这种情况下你可能不愿意使用该可选项。
- <li>rsync 3.0.5 有着巨大的速度性能提升（根据 pgpool-general 邮件列表里的一份报告，会快50%）
-</ul>
-
-</p>
-
-<p>
-    如果你使用 pgpool_recovery，在 pgpool.conf 里增加如下几行。
-</p>
-
-<pre>
-recovery_1st_stage_command = 'pgpool_recovery'
-recovery_2nd_stage_command = 'pgpool_recovery'
-</pre>
-
-<h2 id="perform_online_recovery">如何执行在线恢复</h2>
-<p>
-    为了执行在线恢复，使用 <a href="#PCP_RECOVERY_NODE">pcp_recovery_node</a> 命令或 pgpoolAdmin。
-</p>
-
-<p>
-    注意你需要给 <a href="#pcp_recovery_node">pcp_recovery_node</a> 第一个参数传递一个大数。该数是一个以秒为单位的定时参数。如果你使用 pgpoolAdmin，在pgmgt.conf.php中设置 "_PGPOOL2_PCP_TIMEOUT "参数为一个大数。
-</p>
-
-<h2 id="minorup_w_online_recovery">使用在线恢复实现 PostgreSQL 版本升级</h2>
-<h3>复制模式的情况下</h3>
-<p>
-如果 pgpool-II 运行在复制模式，你可以不停止 pgpool-II 实现对每个 PostgreSQL节点的升级。
-注意在断开和重连数据库节点时，从客户端到 pgpool-II 的激活的会话会被关闭。
-还请注意这种情况下你不能用以下描述的方法做大版本升级
-（例如，需要 dump/restore 的版本升级）。
-</p>
-
-<p>
-<ol>
-    <li><p>
-    准备在线恢复</p>
-    </li>
-
-    <li><p>版本升级应该先从不是主节点的节点开始。
-          在非主节点上停止 PostgreSQL。
-          Pgpool-II 将探测到 PostgreSQL 停止并生成以下日志。
-          这种情况下，到 pgpool-II 的会话都将被关闭。
-        </p>
-<pre>
-2010-07-27 16:32:29 LOG:   pid 10215: set 1 th backend down status
-2010-07-27 16:32:29 LOG:   pid 10215: starting degeneration. shutdown host localhost(5433)
-2010-07-27 16:32:29 LOG:   pid 10215: failover_handler: set new master node: 0
-2010-07-27 16:32:29 LOG:   pid 10215: failover done. shutdown host localhost(5433)
-</pre>
-    </li>
-
-    <li><p>
-        在停止的节点上执行 PostgreSQL 的版本升级。
-        你可以覆盖旧的 PostgreSQL，我们建议你将旧版本的 PostgreSQL 移动到某处
-        以便在必要情况下恢复它。
-    </p>
-    </li>
-
-    <li><p>
-        如果你安装新的 PostgreSQL 在和旧版本不同的位置且你不想更新你的恢复脚本，
-        你需要使用软连接一类的工具来修正路径。
-        如果你选择覆盖，你可以跳过以下步骤，直到安装 C 函数的步骤。
-        你可以立即执行在线恢复。
-    </p>
-    </li>
-
-    <li><p>
-        改变旧的 PostgreSQL 的安装目录。
-        在以下示例中，PostgreSQL 的安装目录被假设为 /user/local/pgsql。
-    </p>
-<pre>
-$ mv /usr/local/pgsql /usr/local/pgsql-old
-</pre>
-    </li>
-
-    <li><p>
-        建立一个到新版本 PostgreSQL 安装位置的软连接。
-        这允许你使用你当前的命令搜索路径。
-        在以下示例中，新的 PostgreSQL 的安装路径被假设为 /usr/local/pgsql-new。
-    </p>
-<pre>
-$ ln -s /usr/local/pgsql-new /usr/local/pgsql
-</pre>
-    </li>
-
-    <li><p>
-        如果数据库目录位于旧的 PostgreSQL 安装目录中，
-        你应该建立或者拷贝一份因而新的 PostgreSQL 可以访问它。
-        在以下示例中我们使用软连接。
-    </p>
-<pre>
-$ ln -s /usr/local/pgsql-old/data /usr/local/pgsql/data
-</pre>
-    </li>
-
-    <li><p>
-      安装 C 函数到 PostgreSQL 中。参考“安装 C 函数”小节。
-      因为在线恢复复制了数据库集群，最后一步使用 psql 安装函数不是必要的。
-      只需要 make install。
-    </p>
-    </li>
-
-    <li><p>
-        执行在线恢复。这样，你完成了一个节点的版本升级。
-        要只需在线恢复，你需要使用 <a href="#pcp_recovery_node">pcp_recovery_node</a> 或 pgpoolAdmin。
-    </p>
-    </li>
-
-    <li><p>
-        针对每个节点重复以上步骤。到最后一步才是升级主节点。然后你就完成了。
-    </p>
-    </li>
-</ol>
-
-<h3>如果你使用流复制</h3>
-<p>
-可以升级备节点而不停止 pgpool-II。
-</p>
-
-<p>
-升级 PostgreSQL 备节点的步骤和以上复制模式的步骤一样。
-请参考“流复制模式中的在线恢复”设置 recovery_1st_stage_command 和 recovery_2nd_stage_command。
-</p>
-
-<p>
-无法实现不停止 pgpool-II 升级主节点。
-你需要在升级主节点时停止 pgpool-II。
-升级主 PostgreSQL 服务器的过程和和备节点相同。
-升级主 PostgreSQL 服务器的过程如下：
-</p>
-<ol>
-    <li>停止 pgpool-II</li>
-    <li>停止主 PostgreSQL</li>
-    <li>升级主 PostgreSQL</li>
-    <li>启动主 PostgreSQL</li>
-    <li>启动 pgpool-II</li>
-</ol>
-
-<p class="top_link"><a href="#Top">返回顶部</a></p>
-
-<!-- ================================================================================ -->
-
-<h1><a name="backup"></a>备份</h1>
-<p>
-要备份后端的 PostgreSQL 服务，你可以使用物理备份，逻辑备份（pg_dump，pg_dumpall）和 PITR。
-注意使用逻辑备份和 PITR 应该直接在 PostgreSQL 上执行，
-而不是通过 pgpool-II，这样才能避免由于 <a href="#LOAD_BALANCE_MODE">load_balance_mode</a> 和
-<a href="#REPLICATE_SELECT">replicate_select</a> 引起的错误。
-</p>
-
-<h2 id="backup_rep_or_ms_mode">复制模式和主/备模式</h2>
-<p>
-如果 pgpool-II 运行在复制模式或主/备模式，只要备份集群中的一个数据库节点。
-</p>
-
-<p>
-如果你使用的是主/备模式并且使用了异步复制系统（Slony-I和流复制）且想要最新的备份，
-你应该在主节点做备份。
-</p>
-
-<p>
-pg_dump 在数据库中使用共享锁（ACCESS SHARE lock）。使用排他锁（ACCESS EXECUTE lock）
-的命令例如 ALTER TABLE， DROP TABLE， TRUNCATE, REINDEX，CLUSTER 和
-VACUUM FULL 将等待 pg_dump 的完成，因为存在锁冲突。这甚至会影响主节点，
-即使你在备节点执行 pg_dump。
-</p>
-
-<p class="top_link"><a href="#Top">返回顶部</a></p>
-
-<!-- ================================================================================ -->
-
-<h1><a name="deploy"></a>部署 pgpool-II</a></h1>
-<p>
-pgpool-II 可以运行在专用的服务器上，应用服务运行的服务器上或者其他服务器上。
-本章我们将讲述如何实现这些部署以及相应的利弊。
-</p>
-
-<p>
-<dl>
-<dt>专用服务器</dt>
-    <dd>
-    <p>
-    pgpool-II 运行在专用服务器上。结构简单且 pgpool-II 不受其他服务软件的影响。
-    很明显，缺点是你需要买更多硬件。
-    而且这种配置下，pgpool-II 可能发生单点故障
-    （你可以使用以下提到的 pgpool-HA 避免这个问题）。
-    </p>
-    </dd>
-
-<dt>部署在网站服务器或应用服务器上</dt>
-    <dd>
-    <p>
-    将 pgpool-II 部署到一台运行 Apache， JBoss， Tomcat 或其他网站服务器和应用服务器上。
-    由于 pgpool-II 和网站服务器或者应用服务器之间的通信是本地的，网络通信速度比服务器间的通信更快。
-    而且如果你使用多个网站服务器或者应用服务器，你可以避免单点故障
-    （这种情况下，你必须为每个 pgpool-II 实例配置相同的 pgpool.conf）。
-    这种配置情况下，你必须注意几项事项：
-    </p>
-    <ul>
-        <li>如果 pgpool-II 和数据库服务器之间的通信部稳定，
-            有可能数据库节点 #1 到一个 pgpool-II 实例的连接断开
-            但到另一个 pgpool-II 实例的连接是正常的。
-            要避免这种问题，你可以使用双网络链路。
-        </li>
-        <li>当在复制模式中执行在线恢复时，你需要停止除进行在线恢复外所有的 pgpool-II 实例。
-            否则，数据库会运行到不一致的状态。
-            在主备模式和流复制模式中，你不需要停止其他的 pgpool-II 实例。
-            然而，你不允许在多个 pgpool-II 实例运行的时候执行在线恢复。
-        </li>
-    </ul>
-    </dd>
-
-<dt>在数据库服务器上运行 pgpool-II</dt>
-    <dd>
-    <p>
-    在运行 PostgreSQL 的服务器上运行 pgpool-II。
-    这种配置下避免 pgpool-II 的单点故障的问题。
-    很明显你不需要另外购买专用服务器。
-    这种配置下的问题是，应用程序需要选择连接到哪台数据库服务器。
-    要解决这个问题你可以通过 pgpool-HA 使用虚拟 IP。
-    </p>
-    </dd>
-</dl>
-
-<h2 id="pgpool_ha">关于 pgpool-HA</h2>
-<p>
-Pgpool-HA 是一个高可用性软件来让 pgpool-II 配合 hearbeat使用。
-Pgpool-HA 是一个 pgpool 以及 pgpool-II 项目的子项目。
-Pgpool-HA 可以在 pgpool 开发网站找到，它是一个开源软件。</p>
-
-<p class="top_link"><a href="#Top">返回顶部</a></p>
-
-<!-- ================================================================================ -->
-
-<h1 id="watchdog">看门狗<span class="version">V3.2 -</span></h1>
-<h2 id="what_is_watchdog">什么是看门狗</h2>
-
-<p>
-	“看门狗”是一个 pgpool-II 的子进程，用于添加高可用性功能。
-	这通过多个 pgpool-II 的合作解决了单点故障的问题。
-	pgpool-II <span class="version">V3.5 -</span> 的看门狗功能得到了显著增强，已经可以确保全天候运行。
-	不过，要确保全天候运行机制能正常运行，需要的 pgpool-II 节点数必须大于或等于 3 且节点数必须为奇数。
-	新增的看门狗在故障耐受力更强，在处理脑列情况和网络分裂时候会更强壮。
-	看门狗提供以下功能。</p>
-<h3>pgpool-II 服务的生命检测</h3>
-    <p>
-    看门狗的存活检测是看门狗用于监控用于提供高可用的看门狗集群中的 pgpool-II 节点的健康状况的子组件。
-    “heartbeat（心跳）”和“query（查询）”模式。pgpool-II <span class="version">V3.5 -</span> 中的看门狗添加新的“external（外部）”
-    健康检测方法，启用了让 pgpool-II 的看门狗关联一个外部的第三方健康检测系统的能力。
-    参考<a href="#INTEGRATE_EXT_LIFECHECK">在看门狗中集成外部存活检测功能</a>获取关于让看门狗关联第三方系统的细节。
-    除了远程健康检测，看门狗存存活检测还可以通过监控到上游服务的连接来检测安装的节点的健康状况。    </p>
-    <ul>
-    <li>
-    在心跳模式中，看门狗使用心跳信号监控其他 pgpool-II 进程。看门狗接收其他 pgpool-II 定期发送的心跳信号。
-    如果时间周期到了还没收到信号，则看门狗认为 pgpool-II 已经失效。
-    为了冗余，你可以使用多个网络接口设备来在 pgpool-II 之间实现心跳交换。这是默认的模式，且推荐使用。
-    </li>
-    <li>
-    在查询模式中，看门狗监控 pgpool-II 提供的服务，而不是进程。看门狗向其他 pgpool-II 发送查询并检查反馈。
-    注意这种模式需要连接到其他 pgpool-II，所以如果 <a href="#NUM_INIT_CHILDREN">num_init_children</a> 不够大则可能监控失败。
-    本模式不赞成使用，保留的原因是为了向下兼容。
-    </li>
-	<li>
-	"external（外部）"<span class="version">V3.5 -</span>模式禁用了 pgpool-II 看门狗的内置存活检测，
-	期望外部系统通知看门狗关于本看门狗集群中本地和远程节点的健康状况。
-	</li>
-    </ul>
-    <p>
-        看门狗还监控到从 pgpool-II 到前端服务器的连接（例如应用服务器），并检查 pgpool-II 能否为这些服务提供服务。如果监控到失败，则认为 pgpool-II 宕机了。
-    </p>
-
-<h3>协调多个 pgpool-II 共同工作</h3>
-    <p>
-    看门狗通过互相交换信息来协调多个 pgpool-II 共同工作。
-    </p>
-    <ul>
-    <li>
-    在后端节点例如由于故障切换而发生状态变化后，看门狗通知其他 pgpool-II 节点并同步信息。
-    在发生在线恢复时，看门狗限制客户端连接到其他 pgpool-II 节点，以避免后端节点的不一致。
-    </li>
-    <li>
-    故障切换或者故障恢复的命令 (<a href="#FAILOVER_COMMAND">failover_command</a>,
-    <a href="#FAILBACK_COMMAND">failback_command</a>, <a href="#FOLLOW_MASTER_COMMAND">follow_master_command</a>)
-    通过内部锁机制只被一个 pgpool-II 节点执行。
-    </li>
-    </ul>
-
-<h3> <span class="version">V3.5 -</span>校验所有节点重要配置参数的一致性</h3>
-	<p>
-	启动的时候，看门狗会校验 pgpool-II 本地节点的配置与主看门狗节点配置的一致性。
-	这排除了由于不同 pgpool-II 节点的配置可能导致的非预期行为。
-	</p>
-
-<h3>在检测到某些故障时交换活跃/备用状态</h3>
-    <p>
-        当一个 pgpool-II 的故障被检测到，看门狗通知其他的看门狗这个消息。
-        如果是活跃的 pgpool-II 发生故障，看门狗通过投票确定新的活跃 pgpool-II 并更新活跃/备用状态。
-    </p>
-
-<h3>在服务器切换的时候实现自动虚拟 IP 地址分配</h3>
-    <p>
-        当一个备用 pgpool 服务器提升为活跃的，新的活跃服务器启动虚拟 IP 接口。
-        也就是，之前的活跃服务器停用虚拟 IP 接口。
-        这确保活动的 pgpool 使用相同的 IP 地址，即使在发生服务器切换的时候。
-    </p>
-
-<h3>在恢复的时候自动注册服务器为备用服务器</h3>
-    <p>
-        当失效的服务器恢复或者新的服务器连接上来，看门狗进程通知其他的看门狗进程关于新服务器的信息，
-        看门狗进程在活跃服务器和其他服务器上接收这些信息。
-        然后，新连接上的服务器注册为备用节点。
-    </p>
-
-<h2 id="watchdog_server_composition">服务器组件</h2>
-
-<p>
-下图描述 pgpool-II 和看门狗进程是如何配置的。
-</p>
-<p><img src="wd-en.jpg" alt="看门狗服务组件" hight=70% width=70%></p>
-
-<h2 id="start_watchdog">启动/停止看门狗</h2>
-<p>
-看门狗进程由 pgpool-II 自动启动/停止，也就是说，没有单独的命令来启动/停止它。
-</p>
-<p>
-看门狗功能启动时必须拥有<font color="red">管理员权限（root）</font> 来控制虚拟 IP 接口。
-方法之一是使用 root 权限启动 pgpool-II。
-不过，考虑安全原因，推荐通过设置设置自定义命令 <a href="#IF_UP_CMD">if_up_cmd</a>、
-<a href="#IF_DOWN_CMD">if_up_cmd</a> 和 <a href="#ARPING_CMD">if_up_cmd</a> 为使用 sudo 或者 setuid 的方法。
-</p>
-<p>
-在等待到所有的 pgpool-II 启动后，内置的存活监测将启动。
-</p>
-
-<h2>配置看门狗 (pgpool.conf)</h2>
-<p>
-看门狗的配置参数在 pgpool.conf 中配置。
-在 pgpool.conf.sample 文件中的 WATCHDOG 小节是配置看门狗的示例。
-</p>
-
-<p>
-以下所有的选项都是使用看门狗进程时必须指定的。
-</p>
-<h3>启用</h3>
-<dl>
-<dt><a name="USE_WATCHDOG"></a>use_watchdog <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    如果为 on，则激活看门狗。默认为 off 。
-    </p>
-    <p>
-    修改本值后，你需要重启 pgpool-II 以使改动生效。
-    </p>
-    </dd>
-</dl>
-
-<h3>Watchdog communication</h3>
-<dl>
-<dt><a name="WD_HOSTNAME"></a>wd_hostname <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    指定 pgpool-II 的主机名或者 IP 地址。这用于发送/接收查询和通讯包，也用于标记看门狗。
-    </p>
-    <p>
-    修改本值后，你需要重启 pgpool-II 以使改动生效。
-    </p>
-    </dd>
-
-<dt><a name="WD_PORT"></a>wd_port <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    指定看门狗的通信端口。
-    </p>
-    <p>
-    修改本值后，你需要重启 pgpool-II 以使改动生效。
-    </p>
-    </dd>
-
-<dt><a name="WD_AUTHKEY"></a>wd_authkey <span class="version">V3.3 -</span></dt>
-    <dd>
-    <p>
-    本选项指定用于看门狗通信的认证密钥。所有的 pgpool-II 必须有相同的密钥。
-    从使用不同密钥的看门狗发送过来的包将被拒绝。
-    本密钥也被用于生命检测被设置为心跳模式时的心跳信号。
-    </p>
-    <p>
-	由于 pgpool-II <span class="version">V3.5 -</span> 的 wd_authkey 也用于认证看门狗的 IPC 客户端，
-	所有与 pgpool-II 看门狗进程通信的客户端需要提供这个	wd_authkey 值用于命令的 JSON 数据的 "IPCAuthKey" 键值。
-	</p>
-    <p>
-    修改本值后，你需要重启 pgpool-II 以使改动生效。
-    </p>
-    </dd>
-</dl>
-
-<h3>连接到上游服务器</h3>
-
-<dl>
-<dt><a name="TRUSTED_SERVERS"></a>trusted_servers <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    用于检测上游连接的可信服务器列表。每台服务器都应能响应 ping。
-    指定一个用逗号分隔的服务器列表例如 "hostA,hostB,hostC"。
-    如果没有任何服务器可以 ping 通，则看门狗认为 pgpool-II 出故障了。
-    </p>
-    <p>
-    如果本选项为空，则看门狗不检查上游连接。
-    </p>
-    <p>
-    修改本值后，你需要重启 pgpool-II 以使改动生效。
-    </p>
-    </dd>
-
-<dt><a name="PING_PATH"></a>ping_path <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    本参数指定用于监控上游服务器的 ping 命令的路径。只需要设置路径例如 "/bin" 。
-    </p>
-    <p>
-    修改本值后，你需要重启 pgpool-II 以使改动生效。
-    </p>
-    </dd>
-</dl>
-
-<h3>虚拟 IP 控制</h3>
-
-<p>
-配置虚拟 IP 接口相关控制
-</p>
-
-<dl>
-<dt><a name="DELEGATE_IP"></a>delegate_IP <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    指定客户端的服务（例如应用服务等）连接到的 pgpool-II 的虚拟 IP (VIP) 地址。
-    当一个 pgpool-II 从备节点切换为激活节点时，pgpool-II 接管这个 VIP。
-    </p>
-    <p>
-    修改本值后，你需要重启 pgpool-II 以使改动生效。
-    </p>
-    </dd>
-
-<dt><a name="IF_CMD_PATH"></a>if_cmd_path <span class="version">V3.5 -</span></dt>
-    <dd>
-    <p>
-    本参数指定用于切换 IP 地址的命令的所在路径。
-    只设置路径，例如 "/sbin"。
-    </p>
-    <p>
-    修改本值后，你需要重启 pgpool-II 以使改动生效。
-    </p>
-    </dd>
-
-<dt><a name="IF_UP_CMD"></a>if_up_cmd <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    本参数指定一个命令用以启用虚拟 IP。设置命令和参数，例如
-    "ip addr add $_IP_$/24 dev eth0 label eth0:0"。
-    参数 $_IP_$  会被 <a href="#DELEGATE_IP">delegate_IP</a> 设置的值替换。
-    </p>
-    <p>
-    修改本值后，你需要重启 pgpool-II 以使改动生效。
-    </p>
-    </dd>
-
-<dt><a name="IF_DOWN_CMD"></a>if_down_cmd <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    本参数指定一个命令用以停用虚拟 IP。设置命令和参数，例如
-    "ip addr del $_IP_$/24 dev eth0"。
-    </p>
-    <p>
-    修改本值后，你需要重启 pgpool-II 以使改动生效。
-    </p>
-    </dd>
-
-<dt><a name="ARPING_PATH"></a>arping_path <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    本参数指定在发生虚拟 IP 切换后用于发送一个 ARP 请求的命令的所在路径。只设置路径，例如 "/sbin"。
-    </p>
-    <p>
-    修改本值后，你需要重启 pgpool-II 以使改动生效。
-    </p>
-    </dd>
-
-<dt><a name="ARPING_CMD"></a>arping_cmd <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    本参数指定一个命令用以在发生虚拟 IP 切换后用于发送一个 ARP 请求的命令。
-    设置命令和参数，例如 "arping -U $_IP_$ -w 1"。
-    参数 $_IP_$  会被 <a href="#DELEGATE_IP">delegate_IP</a> 设置的值替换。
-    </p>
-    <p>
-    修改本值后，你需要重启 pgpool-II 以使改动生效。
-    </p>
-    </dd>
-</dl>
-
-<h3>角色升级/降级时的行为</h3>
-
-<p>配置当 pgpool-II 角色升级为活跃（持有虚拟 IP ）时的行为
-
-<dl>
-<dt><a name="CLEAR_MEMQCACHE_ON_ESCALATION"></a>clear_memqcache_on_escalation <span class="version">V3.3 -</span></dt>
-    <dd>
-    <p>
-    如果本值为 on，pgpool-II 在升级为活跃状态时清空所有的共享内存中的查询缓存。
-    这会避免新激活的 pgpool-II 使用旧的 pgpool-II 而导致的不一致情况。默认值为 on。
-    </p>
-    <p>
-    本选项只有在 <a href="#MEMQCACHE_METHOD">memqcache_method</a> 为 'shmem' 时生效。
-    </p>
-    </dd>
-
-<dt><a name="WD_ESCALATION_COMMAND"></a>wd_escalation_command <span class="version">V3.3 -</span></dt>
-    <dd>
-    <p>
-    在节点升级为主看门狗节点的时候执行本命令。
-	<p>
-    如果配置了本命令，在启用虚拟/浮动 IP 前会立即执行这个命令。
-	</p>
-	</p>
-    </dd>
-<dt><a name="WD_DE-ESCALATION_COMMAND"></a>wd_de_escalation_command <span class="version">V3.5 -</span></dt>
-	<dd>
-	<p>
-	看门狗在主 pgpool-II 看门狗节点放弃主节点角色时执行这个命令。
-	一个主看门狗节点在探测到网络中断或者失去被选为主节点时会放弃主节点角色。
-	</p>
-	<p>
-	如果配置了本命令，在停用虚拟/浮动 IP 前会立即执行这个命令。
-	</p>
-	</dd>
-</dl>
-
-<h3>pgpool-II 存活情况检查</h3>
-
-<p>看门狗定期检查 pgpool-II 的状态。这被称为“存活检查”。
-
-<h4>通用</h4>
-
-<dl>
-<dt><a name="WD_LIFECHECK_METHOD"></a>wd_lifecheck_method <span class="version">V3.3 -</span></dt>
-    <dd>
-    <p>
-    本参数指定存活检查的模式。可以是 'heartbeat' (默认)、'query' 或者 'external'。
-    </p>
-    <p>
-    在 'heartbeat' 模式中，看门狗定期发送心跳信号（UDP 包）到其他的 pgpool-II。看门狗也从其他 pgpool-II 获取信号。
-    如果在一段时间内没有收到信号，看门狗则认为那个 pgpool-II 发生了故障。
-    考虑冗余，你可以使用多个网络接口设备进行 pgpool-II 之间的心跳交换。
-    本模式是默认和推荐使用的。
-    </p>
-    <p>
-    在 'query' 模式中，看门狗发送监控查询到其他的 pgpool-II 并检查反馈情况。
-    </p>
-    <p>
-    <font color="red">警告：如果你打算以查询模式使用看门狗，你需要设置 <a href="#NUM_INIT_CHILDREN">num_init_children</a>
-    到足够大的值。这是因为看门狗进程是以 pgpool-II 客户端的方式连接。</font>
-    </p>
-	<p>
-	在 'external' 模式(<span class="version">V3.5 -</span>) 中，禁用看门狗的内置存活检测，
-	依赖外部系统提供本地和远程看门狗节点的健康检测。
-	</p>
-    <p>
-    修改本值后，你需要重启 pgpool-II 以使改动生效。
-    </p>
-    </dd>
-<dt><a name="WD_MONITORING_INTERFACES_LIST"></a>wd_monitoring_interfaces_list <span class="version">V3.5 -</span></dt>
-    <dd>
-    <p>
-	指定一个用逗号分隔的网络设备名列表，用于让看门狗进程监控网络连接状态。
-	如果列表中的所有接口都失效（禁用或者网线被拔掉），则看门狗认为网络完全出故障，pgpool-II 节点将执行一次自我停机。
-	指定空串 '' 将禁用网络接口监控。
-	设置为 'any' 将监控处 lookback 接口外的所有网络接口。
-	默认为 '' （禁用监控）。
-    </p>
-    <p>
-    修改本值后，你需要重启 pgpool-II 以使改动生效。
-    </p>
-</dd>
-
-<dt><a name="WD_INTERVAL"></a>wd_interval <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    本参数指定 pgpool-II 进行存活检查的间隔，单位为秒（大于或等于 1）。默认为 10.
-    </p>
-    <p>
-    修改本值后，你需要重启 pgpool-II 以使改动生效。
-    </p>
-    </dd>
-
-<dt><a name="WD_PRIORITY"></a>wd_priority <span class="version">V3.5 -</span></dt>
-<dd>
-	<p>
-	本参数用于设定在主看门狗节点选举时本地看门狗节点的优先权。
-	在集群启动的时候或者旧的看门狗故障的时候，wd_priority 值较高的节点会被选为主看门狗节点。</p>
-	<p>
-	修改本值后，你需要重启 pgpool-II 以使改动生效。
-	</p>
-</dd>
-
-<dt><a name="WD_IPC_SOCKET_DIR"></a>wd_ipc_socket_dir <span class="version">V3.5 -</span></dt>
-<dd>
-	<p>
-	建立 pgpool-II 看门狗 IPC 连接的本地域套接字建立的目录。默认为 <code>'/tmp'</code> 。
-	注意这个套接字可能会被 cron 任务删掉，我们推荐设置值为 <code>'/var/run'</code> 一类的路径。
-	</p>
-	<p>
-	这个值只有在服务启动前设置才能生效。
-	</p>
-</dd>
-
-</dl>
-
-<h4>心跳模式的配置</h4>
-
-<dl>
-<dt><a name="WD_HEARTBEAT_PORT"></a>wd_heartbeat_port <span class="version">V3.3 -</span></dt>
-    <dd>
-    <p>
-    本选项指定接收心跳信号的端口号。默认为 9694 。本选项仅用于心跳模式。
-    </p>
-    <p>
-    修改本值后，你需要重启 pgpool-II 以使改动生效。
-    </p>
-    </dd>
-
-<dt><a name="WD_HEARTBEAT_KEEPALIVE"></a>wd_heartbeat_keepalive <span class="version">V3.3 -</span></dt>
-    <dd>
-    <p>
-    本选项指定发送心跳信号的间隔（秒）。默认值为 2。本选项仅用于心跳模式。
-    </p>
-    <p>
-    修改本值后，你需要重启 pgpool-II 以使改动生效。
-    </p>
-    </dd>
-
-<dt><a name="WD_HEARTBEAT_DEADTIME"></a>wd_heartbeat_deadtime <span class="version">V3.3 -</span></dt>
-    <dd>
-    <p>
-    如果本选项指定的时间周期内没有收到心跳信号，则看门狗认为远端的 pgpool-II 发生故障。本选项仅用于心跳模式。
-    </p>
-    <p>
-    修改本值后，你需要重启 pgpool-II 以使改动生效。
-    </p>
-    </dd>
-<dt><a name="HEARTBEAT_DESTINATION"></a>heartbeat_destination<font color="red">0</font> <span class="version">V3.3 -</span></dt>
-    <dd>
-    <p>
-      本选项指定心跳信号发送的目标，可以是 IP 地址或主机名。你可以指定多个目标。
-    本参数名后面的数字表示“目标序号”，从 0 开始。本参数仅用于心跳模式。
-    </p>
-    <p>
-    修改本值后，你需要重启 pgpool-II 以使改动生效。
-    </p>
-    </dd>
-<dt><a name="HEARTBEAT_DESTINATION_PORT"></a>heartbeat_destination_port<font color="red">0</font> <span class="version">V3.3 -</span></dt>
-    <dd>
-    <p>
-    本选项指定由 <a href="HEARTBEAT_DESTINATION">heartbeat_destinationX</a> 指定的心跳信号目标的端口号。
-    这个值通常等于 <a href="WD_HEARTBEAT_PORT">wd_heartbeat_port</a>。
-    但如果这个端口号在某些主机上不能使用或者一个主机上有多个 pgpool-II 的时候你必须指定另一个值。
-    本参数名后面的数字表示“目标序号”，从 0 开始。本参数仅用于心跳模式。
-    </p>
-    <p>
-    修改本值后，你需要重启 pgpool-II 以使改动生效。
-    </p>
-    </dd>
-<dt><a name="HEARTBEAT_DEVICE"></a>heartbeat_device<font color="red">0</font> <span class="version">V3.3 -</span></dt>
-    <dd>
-    <p>
-    本选项指定用于发送心跳信号到由 <a href="HEARTBEAT_DESTINATION">heartbeat_destinationX</a>指定的目标的设备名。
-    你可以向不同的目标使用相同的设备。
-    本参数名后面的数字表示“设备序号”，从 0 开始。
-    本选项仅用于心跳模式。另外，这只有在运行在 Linux 下的 root 权限中的 pgpool-II 才能生效，因为这使用了 SO_BINDTODEVICE 套接字选项。
-    </p>
-    <p>
-    修改本值后，你需要重启 pgpool-II 以使改动生效。
-    </p>
-    </dd>
-</dl>
-
-<h4>查询模式的配置</h4>
-
-<dl>
-<dt><a name="WD_LIFE_POINT"></a>wd_life_point <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    在确认 pgpool-II 失效时的重试次数（一个大于或等于 1 的数字）。默认为 3。本选项仅用于查询模式。
-    </p>
-    <p>
-    修改本值后，你需要重启 pgpool-II 以使改动生效。
-    </p>
-    </dd>
-
-<dt><a name="WD_LIFECHECK_QUERY"></a>wd_lifecheck_query <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    用于检查 pgpool-II 的查询。默认为 "SELECT 1"。本选项仅用于查询模式。
-    </p>
-    <p>
-    修改本值后，你需要重启 pgpool-II 以使改动生效。
-    </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 的用户名。用户名必须存在于后端的 PostgreSQL 中。默认为 "nobody"。
-    本选项仅用于查询模式。
-    </p>
-    </dd>
-
-<dt><a name="WD_LIFECHECK_PASSWORD"></a>wd_lifecheck_password <span class="version">V3.3 -</span></dt>
-    <dd>
-    <p>
-    用于检查 pgpool-II 的密码。默认为 ""。
-    本选项仅用于查询模式。
-    </p>
-    </dd>
-</dl>
-
-<h3>服务监控</h3>
-<dl>
-<dt><a name="OTHER_PGPOOL_HOSTNAME"></a>other_pgpool_hostname<font color="red">0</font>
-    <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    指定需要监控的 pgpool-II 服务器主机。这用于发送/接收查询和数据包，同时也是看门狗的标识。
-    本参数名后面的数字表示“服务序号”，从 0 开始。
-    </p>
-    <p>
-    修改本值后，你需要重启 pgpool-II 以使改动生效。
-    </p>
-    </dd>
-
-<dt><a name="OTHER_PGPOOL_PORT"></a>other_pgpool_port<font color="red">0</font>
-    <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    指定需要监控的 pgpool-II 服务器的 pgpool 服务的端口。
-    对于查询模式，<a href="#WD_LIFECHECK_QUERY">wd_lifecheck_query</a> 指定的查询语句将被发送到这个端口。
-    本参数名后面的数字表示“服务序号”，从 0 开始。
-    </p>
-    <p>
-    修改本值后，你需要重启 pgpool-II 以使改动生效。
-    </p>
-    </dd>
-
-<dt><a name="OTHER_WD_PORT"></a>other_wd_port<font color="red">0</font> <span class="version">V3.2 -</span></dt>
-    <dd>
-    <p>
-    指定需要监控的 pgpool-II 服务器的看门狗的端口。
-    本参数名后面的数字表示“服务序号”，从 0 开始。
-    </p>
-    <p>
-    修改本值后，你需要重启 pgpool-II 以使改动生效。
-    </p>
-    </dd>
-</dl>
-
-<h2 id="INTEGRATE_EXT_LIFECHECK">将看门狗与外部存活检测集成<span class="version">V3.5 -</span></h2>
-<p>
-pgpool-II 的看门狗进程使用 BSD 套接字与所有的 pgpool-II 进程通信，
-这个套接字也可以被任何第三方系统用于为本地以及远程的 pgpool-II 看门狗节点提供存活检测功能。
-用于 IPC 的 BSD 套接字文件名由 "s.PGPOOLWD_CMD." 添加 pgpool-II 的 <a href="WD_PORT">wd_port</a> 构成，
-套接字文件存放在 pgpool-II 的 <a href="#WD_IPC_SOCKET_DIR">wd_ipc_socket_dir</a> 目录中。
-</p>
-<h3 id="Watchdog_IPC_command_packet_format">看门狗 IPC 命令包格式</h3>
-<dl>
-<p>
-看门狗 IPC 命令包包含三个字段。下表列出了消息字段的细节描述信息。
-</p>
-<table border>
-	<tr class="header"><th>字段</th>		<th>类型</th>						<th>描述</th></tr>
-	<tr><th>TYPE</th>		<td>BYTE1</td>				<td>命令类型</td></tr>
-	<tr><th>LENGTH</th>		<td>INT32 网络字节序</td>	<td>数据长度</td></tr>
-	<tr><th>DATA</th>		<td>JSON 格式的数据</td>	<td>JSON 格式的命令数据</td></tr>
-</table>
-</dl>
-<h3 id="Watchdog_IPC_result_packet_format">看门狗 IPC 结果包格式</h3>
-<dl>
-<p>
-看门狗 IPC 结果包包含三个字段。下表列出了消息字段的细节描述信息。
-</p>
-<table border>
-	<tr class="header"><th>字段</th>		<th>类型</th>						<th>描述</th></tr>
-	<tr><th>TYPE</th>		<td>BYTE1</td>					<td>命令类型</td></tr>
-	<tr><th>LENGTH</th>		<td>INT32 网络字节序</td>		<td>数据长度</td></tr>
-	<tr><th>DATA</th>		<td>JSON 格式的数据</td>		<td>JSON 格式的命令结果数据</td></tr>
-</table>
-</dl>
-<h3 id="Watchdog_IPC_command_packet_types">看门狗 IPC 命令包类型</h3>
-<dl>
-<p>
-发送到看门狗进程的命令包的第一字节以及看门狗返回结果的第一字节标记了命令或者命令结果的类型。
-下表列出了所有的有效类型和意义：
-</p>
-<table border>
-	<tr class="header"><th>名称</th>		<th>字节值</th>	<th>类型</th><th>描述</th></tr>
-	<tr><th><a name="ipc_reg_for_notifications"></a>REGISTER FOR NOTIFICATIONS（注册通知）</th>		<td>'0'</td>	<td>命令包</td> <td>注册当前连接用于接收看门狗消息通知</td></tr>
-	<tr><th><a name="ipc_node_status_change"></a>NODE STATUS CHANGE（节点状态改变）</th>	<td>'2'</td>	<td>命令包</td> <td>通知看门狗，有看门狗节点的状态发生变化</td></tr>
-	<tr><th><a name="ipc_get_nodes_list"></a>GET NODES LIST（获取节点列表）</th>	<td>'3'</td>	<td>命令包</td> <td>获取所有配置的看门狗节点</td></tr>
-	<tr><th><a name="ipc_nodes_list_data"></a>NODES LIST DATA（节点列表数据）</th>	<td>'4'</td>	<td>结果包</td>	<td>JSON 数据包，包含所有配置的看门狗及节点的信息</th></tr>
-	<tr><th><a name="ipc_cluster_in_tran"></a>CLUSTER IN TRANSITION（集群变动中）</th>		<td>'7'</td>	<td>结果包</td> <td>在看门狗集群状态正在发生变化的时候，看门狗返回该信息表示当前无法处理命令。</td></tr>
-	<tr><th><a name="ipc_result_bad"></a>RESULT BAD（操作失败）</th>		<td>'8'</td>	<td>结果包</td> <td>当 IPC 命令执行失败时，看门狗返回这个包类型</td></tr>
-	<tr><th><a name="ipc_result_ok"></a>RESULT OK（操作成功）</th>		<td>'9'</td>	<td>结果包</td> <td>当 IPC 命令执行成功时，看门狗返回这个包类型</td></tr>
-
-</table>
-</dl>
-
-<h3 id="external_lifecheck_ipc">外部存活检测的 IPC 包和数据包</h3>
-<dl>
-看门狗的<a href="#ipc_get_nodes_list">"GET NODES LIST"</a>、<a href="#ipc_nodes_list_data">"NODES LIST DATA"</a>
-和 <a href="#ipc_node_status_change">"NODE STATUS CHANGE"</a> IPC 消息可以用于集成一个外部存活检测系统。
-注意 pgpool-II 内置的存活检测能力也是使用这个相同的通道和技术。
-<h4 id="external_lifecheck_ipc">获取已配置的看门狗节点列表</h4>
-<dl>
-任何第三方存活检测系统可以通过看门狗 IPC 套接字发送 <a href="#ipc_get_nodes_list">"GET NODES LIST"</a> 类型的请求数据包
-来获得 <a href="#ipc_nodes_list_data">"NODES LIST DATA"</a> 类型的结果包，如果已经设置<a href="#WD_AUTHKEY">wd_authkey</a>则
-请求数据包需要包含认证秘钥，否则请求数据包为空。结果包包含 JSON 格式的所有已配置的参与存活检测的看门狗节点列表。
-JSON 格式的看门狗节点包含所有看门狗节点的"WatchdogNodes"数组。每个看门狗节点的 JSON 节点包含对应的
-"ID", "NodeName"、"HostName"、"DelegateIP"、"WdPort"以及"PgpoolPort" 值。
-<pre>
--- 在 <a href="#ipc_nodes_list_data">"NODES LIST DATA"</a> 中包含的 JSON 数据示例
-
-  {
-	"NodeCount":3,
-	"WatchdogNodes":
-		[
-			{
-				"ID":0,
-				"State":1,
-				"NodeName":"Linux_ubuntu_9999",
-				"HostName":"watchdog-host1",
-				"DelegateIP":"172.16.5.133",
-				"WdPort":9000,
-				"PgpoolPort":9999
-			},
-			{
-				"ID":1,
-				"State":1,
-				"NodeName":"Linux_ubuntu_9991",
-				"HostName":"watchdog-host2",
-				"DelegateIP":"172.16.5.133",
-				"WdPort":9000,
-				"PgpoolPort":9991
-			},
-			{
-				"ID":2,
-				"State":1,
-				"NodeName":"Linux_ubuntu_9992",
-				"HostName":"watchdog-host3",
-				"DelegateIP":"172.16.5.133",
-				"WdPort":9000,
-				"PgpoolPort":9992
-			}
-		]
-  }
-
- -- 注意节点 ID 为 0 的值总是为本地看门狗节点保留。
-</pre>
-在从看门狗获取配置的看门狗节点信息后，外部存活检测系统可以进行为看门狗节点进行健康检查，
-当它检测到任何节点的一些状态改变时，它可以使用 <a href="#ipc_node_status_change">"NODE STATUS CHANGE"</a> 这个 IPC 消息将情况使用通知给看门狗。
-这个消息应该包含状态发生改变的节点的 ID （节点 ID 必须和看门狗返回的 WatchdogNodes 列表中的值相同）以及节点的新状态的 JSON 数据。
-。
-<pre>
--- 通知 pgpool-II 的看门狗 ID 为 1 的节点故障的示例 JSON 数据类似于
-
-  {
-	"NodeID":1,
-	"NodeStatus":1,
-	"Message":"optional message string to log by watchdog for this event"
-	"IPCAuthKey":"<a href="#WD_AUTHKEY">wd_authkey</a> configuration parameter value"
-  }
-
--- NodeStatus 值为以下值
-NODE STATUS DEAD  =  1
-NODE STATUS ALIVE =  2
-
-</pre>
-
-</dl>
-</dl>
-
-<h2 id="watchdog_restrictions">看门狗的限制</h2>
-<ul>
-<li>
-在查询模式中，如果所有的数据库节点由于 PostgreSQL 服务出现故障或者由于调用了 pcp_detach_node，
-看门狗会认为 pgpool-II 服务为故障状态并会剥夺虚拟 IP。这样，pgpool-II 的客户端就再也无法通过
-虚拟 IP 连接。这对于避免<i>脑裂</i>很重要，也就是说，这种情况下可能出先多个激活的 pgpool-II。
-</li>
-<li>
-不要通过真实 IP 连接到状态为下线的 pgpool-II。因为状态为下线的 pgpool-II 无法从看门狗获取信息，
-因此它的后端（数据库）信息可能与其他 pgpool-II 不同。
-</li>
-<li>
-为下线状态的 pgpool-I 不能变为激活或者备用的 pgpool-II。从下线状态恢复需要重启 pgpool-II。
-</li>
-<li>
-注意激活状态的 pgpool-II 停机，需要好几秒钟才能等到备用 pgpool-II 提升为激活状态，以确保之前的
-虚拟 IP 下线前的下线通知包被送到其他的 pgpool-II 节点。
-</li>
-</ul>
-<p class="top_link"><a href="#Top">返回顶部</a></p>
-
-<!-- ================================================================================ -->
-
-<h1 id="pcp_command">PCP 命令</h1>
-
-<h2>PCP 命令列表</h2>
-<p>PCP 命令是UNIX命令，通过网络操作pgpool-II。
-注意所有的 PCP 命令的参数格式从 3.5 开始都已经发生了改变。</p>
-<table border>
-<tr><th><a href="#pcp_node_count">pcp_node_count</a></th>
-    <td>获取节点数量</td></tr>
-<tr><th><a href="#pcp_node_info">pcp_node_info</a></th>
-    <td>获取节点信息</td></tr>
-<tr><th><a href="#pcp_watchdog_info">pcp_watchdog_info</a> <span class="version">V3.3 -</span></th>
-    <td>返回看门狗信息</td></tr>
-<tr><th><a href="#pcp_proc_count">pcp_proc_count</a></th>
-    <td>获取进程列表</td></tr>
-<tr><th><a href="#pcp_proc_info">pcp_proc_info</a></th>
-    <td>获取进程信息</td></tr>
-<tr><th><a href="#pcp_pool_status ">pcp_pool_status</a> <span class="version">V3.1 -</span></th>
-    <td>获取 pgpool.conf 中的参数</td></tr>
-<tr><th><a href="#pcp_detach_node">pcp_detach_node</a></th>
-    <td>从 pgpool-II 脱离一个节点</td></tr>
-<tr><th><a href="#pcp_attach_node">pcp_attach_node</a></th>
-    <td>给 pgpool-II 关联一个节点</td></tr>
-<tr><th><a href="#pcp_promote_node">pcp_promote_node</a> <span class="version">V3.1 -</span></th>
-    <td>给 pgpool-II 提升一个新的master节点</td></tr>
-<tr><th><a href="#pcp_stop_pgpool">pcp_stop_pgpool</a></th>
-    <td>停止 pgpool-II</td></tr>
-</table>
-
-
-<h2 id="pcp_comand_password">PCP 连接认证</h2>
-
-<p>PCP 用户名和密码必须在 <code>$prefix/etc</code> 目录中的 <code>pcp.conf</code> 文件中声明。
-<code>-F</code> 可以用于在 <code>pcp.conf</code> 被存放在其他位置的时候启动 pgpool-II。</p>
-
-<h3 id="password_file">密码文件</h3>
-
-<p>用户 home 目录中的 .pcppass 文件或者环境变量 PCPPASSFILE 应用的文件可以包含用于在建立 pcp 连接时不提供密码。</p>
-<p>这个文件应该包含以下格式的行：/<p>
-
-<pre>
-hostname:port:username:password
-</pre>
-<p>
-（你可以在通过在行前添加 # 来将一行内容转变为注释）
-前三个字段可以是文字值或者表示匹配任何值的 *。从第一行开始最先匹配当前连接参数行的 password 字段将被使用。
-（也就是，在使用通配符的情况下，尽量将使用具体值的项目靠前。）如果一个项目包含了 : 或者 \，则使用 \ 将这个
-字符转义。主机名为 localhost 可以匹配到 TCP（也就是主机名 localhost）以及从本机发起的 Unix 域套接字连接。</p>
-
-<p>.pcppass 的访问权限必须拒绝组内或者所有人访问；可以通过命令 chmod 0600 ~/.pcppass 做到。
-如果权限没这么严格，则文件会被忽略掉。</p>
-
-<h2 id="pcp_common_options">通用选项</h2>
-
-<p>有一些所有 PCP 命令都会用到的参数。它们大部分都是用于认证，其他则用于细节模式和调试消息等。
-<pre>
-例如)  $ pcp_node_count -h localhost -p 9898 -u postgres -w -d -v
-</pre>
-
-<dl class="options">
-<dt><code>
--h <strong>hostname</strong>, --host=<strong>hostname</strong>
-</code></dt>
-<dd><p>
-服务运行的主机名。如果以反斜杠开始，则被当做 Unix 域套接字的目录使用。
-</p></dd>
-
-<dt><code>
--p <strong>port</strong>, --port=<strong>port</strong>
-</code></dt>
-<dd><p>
-PCP 端口号（默认为 "9898"）。
-</p></dd>
-
-<dt><code>
--u <strong>username</strong>, --username=<strong>username</strong>
-</code></dt>
-<dd><p>
-用于 PCP 认证的用户名（默认为当前登录的操作系统用户名）。
-</p></dd>
-
-<dt><code>
--w, --no-password
-</code></dt>
-<dd><p>
-不提示输入密码。如果 .pcppass 文件中没有提供密码，则连接失败。这个选项可以用于不方便输入密码的批处理任务以及脚本。
-</p></dd>
-
-<dt><code>
--W, --password
-</code></dt>
-<dd><p>
-强制提示输入密码（默认自动发生）。
-</p></dd>
-
-<dt><code>
--d, --debug
-</code></dt>
-<dd><p>
-启用调试消息。
-</p></dd>
-
-<dt><code>
--v, --verbose
-</code></dt>
-<dd><p>
-启用详细信息输出。
-</p></dd>
-
-<dt><code>
--V, --version
-</code></dt>
-<dd><p>
-打印命令的版本，然后退出。
-</p></dd>
-
-<dt><code>
--?, --help
-</code></dt>
-<dd><p>
-显示命令行参数的帮助，然后退出。
-</p></dd>
-</dl>
-
-<h2>用于获取状态和配置的 PCP 命令</h2>
-
-<p>所有的 PCP 命令都会将结果显示到标准输出。</p>
-
-
-<h3 id="pcp_node_count">pcp_node_count</h3>
-<dl>
-<dt>格式：</dt>
-<dd>
-	<pre><code>pcp_node_count [options...] </code></pre>
-</dd>
-<dt>描述：</dt>
-<dd>
-	显示<code>pgpool.conf</code>中定义的所有的节点总数。
-	它并不区别节点状态，例如 attached/detached。所有节点都被算进去。</p>
-</dd>
-<dt>选项：</dt>
-<dd>
-	<p>参考<a href="#pcp_common_options">通用选项</a>。</p>
-</dd>
-</dl>
-
-<h3><a name="pcp_node_info"/></a>pcp_node_info</h3>
-<dl>
-<dt>格式：</dt>
-<dd>
-	<pre><code>pcp_node_info [options...] [node_id] </code></pre>
-</dd>
-<dt>描述：</dt>
-<dd>
-	<p>显示给定节点 ID 的信息。</p>
-</dd>
-<dt>选项</dt>
-<dd>
-	<dl class="options">
-	<dt><code>-n <strong>node_id</strong>, --node-id=<strong>node_id</strong></code></dt>
-	<dd>
-		<p>需要获取信息的后端节点的索引值。</p>
-	</dd>
-	<dt>其他选项</dt>
-	<dd>
-		<p>参考<a href="#pcp_common_options">通用选项</a>。</p>
-	</dd>
-	</dl>
-</dd>
-<dt>输出示例：</dt>
-<dd>
-<pre>
-$ pcp_node_info -h localhost -U postgres 0
-host1 5432 1 1073741823.500000
-</pre>
-
-<p>结果以如下顺序显示：</p>
-<ol>
-<li>主机名</li>
-<li>端口号</li>
-<li>状态</li>
-<li>负载均衡权重</li>
-</ol>
-
-<p>Status 由数字 [0 - 3] 来表示。</p>
-<ul>
-<li>0 - 该状态仅仅用于初始化，PCP从不显示它。</li>
-<li>1 - 节点已启动，还没有连接。</li>
-<li>2 - 节点已启动，连接被缓冲。</li>
-<li>3 - 节点已关闭。</li>
-</ul>
-<p>负载均衡权重以标准格式来显示。</p>
-
-<p><code>--verbose</code> 选项帮助理解输出. 例如:</p>
-
-<pre>
-$ pcp_node_info --verbose 10 localhost 9898 postgres hogehoge 0
-Hostname: host1
-Port    : 5432
-Status  : 1
-Weight  : 0.5
-</pre>
-</dd>
-</dl>
-
-<h3><a name="pcp_watchdog_info"/></a>pcp_watchdog_info <span class="version">V3.3 -</span></h3>
-<dl>
-<dt>格式：</dt>
-<dd>
-	<pre><code>pcp_watchdog_info [options...] [watchdog_id]</code></pre>
-</dd>
-<dt>描述：</dt>
-<dd>
-    <p>显示 pgpool-II 的看门狗状态。
-    <code>watchdog_id</code> 为要获得信息的看门狗的索引值。
-    如果这个值被省略了，则显示集群里所有看门狗的状态。</p>
-    <p>由于 <code>watchdog_id</code> = 0 是为当前 pgpool-II 节点保留的，
-    所以远程看门狗节点的索引值是从 1 开始。</p>
-    <p>注意, 虽然在使用 pcp_watchdog_info 命令时远程看门狗节点的索引值是从 1 开始，
-    然而在 pgpool.conf 中是从 0 开始定义远程看门狗节点的索引值，
-    所以在使用 pcp_watchdog_info 命令来获得远程看门狗信息时，需要将其看门狗的索引值加 1。</p>
-    <p>例如，在使用 pcp_watchdog_info 来获取第一个远程看门狗节点的信息时，
-    并且其节点被 other_pgpool_hostname0 参数定义为前缀配置为 0，
-    您需要使用 <code>watchdog_id</code> = 1。</p>
-</dd>
-<dt>选项：</dt>
-<dd>
-	<dl class="options">
-	<dt><code>-n <strong>watchdog_id</strong>, --node-id=<strong>watchdog_id</strong></code></dt>
-	<dd>
-		<p>要获得信息的其他 pgpool-II 的索引值。</p>
-        <p>如果这个值为 0，则获取本地 pgpool-II 看门狗的信息。</p>
-        <p>如果这个值被省略了，则获取所有 pgpool-II 看门狗节点的信息。</p>
-	</dd>
-	<dt>其他选项</dt>
-	<dd>
-		<p>参考<a href="#pcp_common_options">通用选项</a>。</p>
-	</dd>
-	</dl>
-</dd>
-<dt>输出示例：</dt>
-<dd>
-<pre>
-$ pcp_watchdog_info -h localhost -u postgres
-
-3 NO Linux_host1.localdomain_9991 host1
-
-Linux_host1.localdomain_9991 host1 9991 9001 7 STANDBY
-Linux_host2.localdomain_9992 host2 9992 9002 4 MASTER
-Linux_host3.localdomain_9993 host3 9993 9003 7 STANDBY
-</pre>
-
-<p>结果按以下顺序显示：</p>
-<p>输出的第一行描述看门狗集群的信息：</p>
-<ol>
-<li>集群内看门狗节点的总数</li>
-<li>当前节点是否启动了虚拟 IP?</li>
-<li>主节点名</li>
-<li>主节点主机名</li>
-</ol>
-
-<p>下面是看门狗节点列表：</p>
-<ol>
-    <li>节点名</li>
-    <li>主机名</li>
-    <li>pgpool 端口号</li>
-    <li>看门狗端口号</li>
-    <li>当前节点状态</li>
-    <li>当前节点名</li>
-</ol>
-</dd>
-
-<dt>细节模式:</dt>
-<dd>
-<pre>
-$ pcp_watchdog_info -h localhost -v -u postgres
-
-Watchdog Cluster Information
-Total Nodes          : 3
-Remote Nodes         : 2
-Quorum state         : QUORUM EXIST
-Alive Remote Nodes   : 2
-VIP up on local node : NO
-Master Node Name     : Linux_host2.localdomain_9992
-Master Host Name     : localhost
-
-Watchdog Node Information
-Node Name      : Linux_host1.localdomain_9991
-Host Name      : host1
-Delegate IP    : 192.168.1.10
-Pgpool port    : 9991
-Watchdog port  : 9001
-Node priority  : 1
-Status         : 7
-Status Name    : STANDBY
-
-Node Name      : Linux_host2.localdomain_9992
-Host Name      : host2
-Delegate IP    : 192.168.1.10
-Pgpool port    : 9992
-Watchdog port  : 9002
-Node priority  : 1
-Status         : 4
-Status Name    : MASTER
-
-Node Name      : Linux_host3.localdomain_9993
-Host Name      : host3
-Delegate IP    : 192.168.1.10
-Pgpool port    : 9993
-Watchdog port  : 9003
-Node priority  : 1
-Status         : 7
-Status Name    : STANDBY
-
-</pre>
-</dd>
-</dl>
-
-
-<h3 id="pcp_proc_count">pcp_proc_count</h3>
-<dl>
-<dt>格式：</dt>
-<dd>
-	<pre><code>pcp_proc_count [options...] </code></pre>
-</dd>
-<dt>描述：</dt>
-<dd>
-	<p>显示 pgpool-II 子进程 ID 列表。如果有多于一个的进程，ID 间将用空格来隔开。</p>
-</dd>
-
-<dt>选项：</dt>
-	<p>参考<a href="#pcp_common_options">通用选项</a>。</p>
-</dd>
-</dl>
-
-<h3 id="pcp_proc_info">pcp_proc_info</h3>
-<dl>
-<dt>格式：</dt>
-<dd>
-	<pre><code>pcp_proc_info [options...] [processid] </code></pre>
-</dd>
-<dt>描述：</dt>
-<dd>
-	<p>显示给定 ID 的 pgpool-II 子进程的信息。</p>
-</dd>
-<dt>选项：</dt>
-<dd>
-	<dl class="options">
-	<dt><code>-P <strong>PID</strong>, --process-id=<strong>PID</strong></code></dt>
-	<dd>
-		<p>pgpool-II 子进程的 PID。</p>
-	</dd>
-	<dt>其他选项</dt>
-	<dd>
-		<p>参考<a href="#pcp_common_options">通用选项</a>。</p>
-	</dd>
-</dd>
-<dt>输出示例：</dt>
-<dd>
-<pre>
-$ pcp_proc_info -h localhost -p 9898 -U postgres 3815
-postgres_db postgres 1150769932 1150767351 3 0 1 1467 1
-postgres_db postgres 1150769932 1150767351 3 0 1 1468 1
-</pre>
-
-<p>结果以如下顺序被显示：</p>
-<ol>
-<li>连接的数据库名</li>
-<li>连接的用户名</li>
-<li>进程启动时间戳</li>
-<li>连接创建时间戳</li>
-<li>协议major版本</li>
-<li>协议minor版本</li>
-<li>连接重用计数</li>
-<li>PostgreSQL 后端进程 ID</li>
-<li>前端连接时为 1，否则为0</li>
-</ol>
-
-<p>
-如果没有与后台的连接，不显示任何内容。
-如果有多个连接，将显示多行，每行显示一个连接的信息，时间戳显示格式是 EPOCH。
-</p>
-
-<p>
-<code>--verbose</code> 可选项帮助理解输出. 示例如下:
-</p>
-
-<pre>
-$ pcp_proc_info --verbose -U postgres 3815
-Database     : postgres_db
-Username     : postgres
-Start time   : 1150769932
-Creation time: 1150767351
-Major        : 3
-Minor        : 0
-Counter      : 1
-PID          : 1467
-Connected    : 1
-Database     : postgres_db
-Username     : postgres
-Start time   : 1150769932
-Creation time: 1150767351
-Major        : 3
-Minor        : 0
-Counter      : 1
-PID          : 1468
-Connected    : 1
-</pre>
-</dd>
-</dl>
-
-<h3 id="pcp_pool_status">pcp_pool_status <span class="version">V3.1 -</span></h3>
-<dl>
-<dt>格式：</dt>
-<dd>
-	<pre><code>pcp_pool_status [options...]</code></pre>
-</dd>
-<dt>描述：</dt>
-<dd>
-	<p>示 pgpool.conf 中的参数定义。</p>
-</dd>
-<dt>选项：</dt>
-<dd>
-	<p>参考<a href="#pcp_common_options">通用选项</a>。</p>
-</dd>
-<dt>输出示例：</dt>
-<dd>
-<pre>
-$ pcp_pool_status -h localhost -U postgres
-name : listen_addresses
-value: localhost
-desc : host name(s) or IP address(es) to listen to
-
-name : port
-value: 9999
-desc : pgpool accepting port number
-
-name : socket_dir
-value: /tmp
-desc : pgpool socket directory
-
-name : pcp_port
-value: 9898
-desc : PCP port # to bind
-</pre>
-</dd>
-</dl>
-
-<h2>用于控制后端节点等的 PCP 命令</h2>
-
-<h3 id="pcp_detach_node">pcp_detach_node</h3>
-<dl>
-<dt>格式：</dt>
-<dd>
-	<pre><code>pcp_detach_node [options...] [node_id] [gracefully]</code></pre>
-</dd>
-<dt>描述：</dt>
-<dd>
-	<p>把指定的节点从 pgpool-II 分离。已有的到 pgpool-II 的连接将被强制关闭。</dd>
-<dt>选项：</dt>
-<dd>
-	<dl class="options">
-	<dt><code>-n <strong>node_id</strong>, --node-id=<strong>node_id</strong></code></dt>
-	<dd>
-		<p>已经连接的后端节点索引值。</p>
-	</dd>
-	<dt><code>-g, --gracefully </code></dt>
-	<dd>
-		<p>等待所有的客户端断开(除非client_idle_limit_in_recovery为 -1，
-		或者 recovery_timeout 过期)。</p>
-	</dd>
-	<dt>其他选项</dt>
-	<dd>
-		<p>参考<a href="#pcp_common_options">通用选项</a>。</p>
-	</dd>
-	</dl>
-</dd>
-</dl>
-
-<h3 id="pcp_attach_node">pcp_attach_node</h3>
-<dl>
-<dt>格式：</dt>
-<dd>
-	<pre><code>pcp_attach_node [options...] [node_id]</code></pre>
-</dd>
-<dt>描述：</dt>
-<dd>
-	<p>将给定的节点加入到 pgpool-II。</p>
-</dd>
-<dt>选项：</dt>
-<dd>
-	<dl class="options">
-	<dt><code>-n <strong>node_id</strong>, --node-id=<strong>node_id</strong></code></dt>
-	<dd>
-		<p>需要连接的后端节点 ID。</p>
-	</dd>
-	<dt>其他选项</dt>
-	<dd>
-		<p>参考<a href="#pcp_common_options">通用选项</a>。</p>
-	</dd>
-	</dl>
-</dd>
-</dl>
-
-<h3 id="pcp_promote_node">pcp_promote_node <span class="version">V3.1 -</span></h3>
-<dl>
-<dt>格式：</dt>
-<dd>
-	<pre><code>pcp_promote_node [options...] [node_id] [gracefully]</code></pre>
-</dd>
-<dt>描述：</dt>
-<dd>
-	<p>提升给定的节点为 pgpool-II 中的主节点。仅用于流复制模式。只适用于 master/slave 流复制。
-		注意这个命令实际上不提升备用的 PostgreSQL 后端：它仅仅改变 pgpool-II 的内部状态并处罚故障切换，
-		用户必须在 pgpool-II 之外提升 PostgreSQL 备节点。</p>
-</dd>
-<dt>选项：</dt>
-<dd>
-	<dl class="options">
-	<dt><code>-n <strong>node_id</strong>, --node-id=<strong>node_id</strong></code></dt>
-	<dd>
-		<p>被提升为新主节点的后端节点索引值。</p>
-	</dd>
-	<dt><code>-g, --gracefully </code></dt>
-	<dd>
-		<p>等待所有的客户端断开(除非 client_idle_limit_in_recovery 为 -1，
-		或者 recovery_timeout 过期)。</p>
-	</dd>
-	<dt>其他选项</dt>
-	<dd>
-		<p>参考<a href="#pcp_common_options">通用选项</a>。</p>
-	</dd>
-	</dl>
-</dd>
-</dl>
-
-<h3 id="pcp_stop_pgpool">pcp_stop_pgpool</h3>
-<dl>
-<dt>格式：</dt>
-<dd>
-	<pre><code>pcp_stop_pgpool [options...] [mode]</code></pre>
-</dd>
-<dt>描述：</dt>
-<dd>
-	<p>终止 pgpool-II 进程。</p>
-</dd>
-<dt>选项：</dt>
-<dd>
-	<dl class="options">
-	<dt><code>-m <strong>mode</strong>, --mode=<strong>mode</strong></code></p>
-	<dd>
-		<p>使用指定的模式关闭 pgpool-II 进程。</p>
-		<p>可用的模式如下：</p>
-		<ul>
-			<li>s, smart        : 智能模式</li>
-			<li>f, fast         : 快速模式</li>
-			<li>i, immediate    : 立即模式</li>
-		</ul>
-	</dd>
-	<dt>其他选项</dt>
-	<dd>
-		<p>参考<a href="#pcp_common_options">通用选项</a>。</p>
-	</dd>
-	</dl>
-</dl>
-
-<h3 id="pcp_recovery_node">pcp_recovery_node</h3>
-<dl>
-<dt>格式：</dt>
-<dd>
-	<pre><code>pcp_recovery_node [options...] [node_id] </code></pre>
-</dd>
-<dt>描述：</dt>
-<dd>
-	<p>以恢复模式连接到给定的后端节点。</p>
-</dd>
-<dt>选项：</dt>
-<dd>
-	<dl class="options">
-	<dt><code>-n <strong>node_id</strong>, --node-id=<strong>node_id</strong></code></dt>
-	<dd>
-		<p>后端节点索引值。</p>
-	</dd>
-	<dt>其他选项</dt>
-	<dd>
-		<p>参考<a href="#pcp_common_options">通用选项</a>。</p>
-	</dd>
-	</dl>
-</dd>
-</dl>
-
-<p class="top_link"><a href="#Top">返回顶部</a></p>
-
-<h1 id="pgpool_adm">pool_adm</h1>
-<p>
-  pgpoo_adm 是用于允许 SQL 访问 pcp 命令（实际上是 pcp 库）的一组扩展。
-  它使用了下图中展示的外部数据封装技术。
-</p>
-
-<p><img src="pgpool_adm.png" alt="pgpool_adm 中的数据流" hight=70% width=70%></p>
-
-<p>
-  可以通过 pgpool-II (1) 或者通过 PostgreSQL (2) 调用这些函数。
-  在情况 (1) 中，pgpool-II 接受用户 (1) 的查询，然后转发给 PostgreSQL (3)。
-  PostgreSQL 连接到 pgpool-II (5) 之后 pgpool-II 反馈结果给 PostgreSQL (3)。
-  PostgreSQL 返回结果给 pgpool-II (5) 然后 pgpool-II 转发结果给用户 (6)。
-</p>
-<p>
-  在情况 (2) 中，PostgreSQL 接受用户 (2) 的查询。
-  PostgreSQL 连接到 pgpool-II (5) 之后 pgpool-II 反馈结果给 PostgreSQL (3)。
-  PostgreSQL 返回结果给用户 (6)。
-</p>
-<p>
-  有两种格式调用 pgpool_adm 函数：第一种格式接收 pgpool-II 的主机名（或者 IP 地址），
-  pcp 端口号，pcp 用户名，密码以及其他参数。
-</p>
-<p>
-  在第二种格式中，需要提供 pgpool-II 服务名。服务名必须已经使用 "CREATE FOREIGN SERVER" 命令在 PostgreSQL 中定义。
-  pcp 端口号硬编码为 9898，而 pcp 用户名被认为和调用的 PostgreSQL 用户名相同。
-  密码从 $HOME/.pcppass 文件中获得。
-</p>
-
-<h2>安装 pgpool_adm</h2>
-<p>
-pgpool_adm 是一个扩展，需要被安装到 PostgreSQL 服务中。
-</p>
-<p>
-<pre>
-$ cd src/sql/pgpool_adm
-$ make
-$ make install
-</pre>
-</p>
-<p>
-然后，在你需要访问的每个数据库中执行以下 SQL 命令。
-</p>
-<p>
-<pre>
-$ psql ...
-$ CREATE EXTENSION pgpool_adm
-</pre>
-</p>
-
-<h2>pgpool_adm 函数列表</h2>
-<table border>
-<tr><th><a href="#func_pcp_node_info">pcp_node_info</a></th>
-  <td>获取节点信息</td></tr>
-<tr><th><a href="#func_pcp_pool_status">pcp_pool_status</a></th>
-    <td>获取 pgpool.conf 中的参数</td></tr>
-<tr><th><a href="#func_pcp_node_count">pcp_node_count</a></th>
-  <td>获取节点数</td></tr>
-<tr><th><a href="#func_pcp_attach_node">pcp_attach_node</a></th>
-  <td>将一个节点加入到 pgpool-II 中</td></tr>
-<tr><th><a href="#func_pcp_detach_node">pcp_detach_node</a></th>
-  <td>将一个节点从 pgpool-II 中分离</td></tr>
-</table>
-
-<h3 id="func_pcp_node_info">pcp_node_info</h3>
-<dl>
-<dt>格式：</dt>
-<dd>
-  <pre><code>pcp_node_info(integer node_id, text host, integer port, text username, text password, OUT status text, OUT weight float4) returns record</code></pre>
-  <pre><code>pcp_node_info(integer node_id, text pcp_server, OUT status text, OUT weight float4) returns record</code></pre>
-</dd>
-
-<dt>描述：</dt>
-<dd>
-  <p>获取节点信息。
-  查阅 <a href="#pcp_node_info">pcp_node_info 命令</a> 获得更多细节信息。</p>
-  <p>
-    以下为示例输出。
-<pre>
-test=# SELECT * FROM pcp_node_info(0,'',11001,'t-ishii','t-ishii');
- host | port  |      status       | weight
-------+-------+-------------------+--------
- /tmp | 11002 | Connection in use |      0
-(1 row)
-</pre>
-  </p>
-</dd>
-
-<dt>参数：</dt>
-<dd>
-  <dl class="options">
-  <dt><code>node_id</strong></code></dt>
-  <p>后端节点索引值</p>
-
-  <dt><code>host</strong></code></dt>
-  <p>pcp 服务运行的主机名或者 IP 地址。</p>
-
-  <dt><code>port</strong></code></dt>
-  <p>pcp 服务监听的端口。</p>
-
-  <dt><code>username</strong></code></dt>
-  <p>访问 pcp 服务的用户名。</p>
-
-  <dt><code>password</strong></code></dt>
-  <p>访问 pcp 服务的密码。</p>
-
-  <dt><code>pcp_server</strong></code></dt>
-  <p>用于 pcp 服务的外部服务名。</p>
-
-</dd>
-
-</dd>
-</dl>
-</h3>
-
-<h3 id="func_pcp_pool_status">pcp_pool_status</h3>
-<dl>
-<dt>格式：</dt>
-<dd>
-  <pre><code>pcp_pool_status(text host, integer port, text username, text password) returns record</code></pre>
-  <pre><code>pcp_pool_status(text pcp_server) returns record</code></pre>
-</dd>
-
-<dt>描述：</dt>
-<dd>
-  <p>返回 pgpool.conf 里的参数。
-  参考 <a href="#pool_status">pool_status</a> 获得更多细节信息。</p>
-  <p>
-    以下为示例输出：
-<pre>
-test=# SELECT * FROM pcp_pool_status('localhost',11001,'t-ishii','t-ishii') WHERE item ~ 'backend.*0';
-          item           |                     value                      |          description
--------------------------+------------------------------------------------+-------------------------------
- backend_hostname0       | /tmp                                           | backend #0 hostname
- backend_port0           | 11002                                          | backend #0 port number
- backend_weight0         | 0.500000                                       | weight of backend #0
- backend_data_directory0 | /home/t-ishii/work/pgpool-II/current/aaa/data0 | data directory for backend #0
- backend_status0         | 2                                              | status of backend #0
- backend_flag0           | ALLOW_TO_FAILOVER                              | backend #0 flag
-(6 rows)
-</pre>
-  </p>
-</dd>
-
-<dt>参数：</dt>
-<dd>
-  <dl class="options">
-<dd>
-  <dt><code>host</strong></code></dt>
-  <p>pcp 服务运行的主机名或者 IP 地址。</p>
-
-  <dt><code>port</strong></code></dt>
-  <p>pcp 服务监听的端口。</p>
-
-  <dt><code>username</strong></code></dt>
-  <p>访问 pcp 服务的用户名。</p>
-
-  <dt><code>password</strong></code></dt>
-  <p>访问 pcp 服务的密码。</p>
-
-  <dt><code>pcp_server</strong></code></dt>
-  <p>用于 pcp 服务的外部服务名。</p>
-
-</dd>
-
-</dd>
-</dl>
-</h3>
-
-<h3 id="func_pcp_node_count">pcp_node_node_count</h3>
-<dl>
-<dt>格式：</dt>
-<dd>
-  <pre><code>pcp_node_count(integer node_id, text host, integer port, text username, text password, OUT node_count integer) returns integer</code></pre>
-  <pre><code>pcp_node_count(integer node_id, OUT node_count integer) returns record</code></pre>
-</dd>
-
-<dt>描述：</dt>
-<dd>
-  <p>返回节点计数。
-  参考 <a href="#pcp_node_count">pcp_node_count command</a> 获得更多细节信息。</p>
-  <p>
-    以下为示例输出：
-<pre>
-test=# SELECT * FROM pcp_node_count('localhost',11001,'t-ishii','t-ishii');
- node_count
-------------
-          2
-(1 row)
-</pre>
-  </p>
-</dd>
-
-<dt>参数：</dt>
-<dd>
-  <dl class="options">
-
-<dd>
-  <dt><code>host</strong></code></dt>
-  <p>pcp 服务运行的主机名或者 IP 地址。</p>
-
-  <dt><code>port</strong></code></dt>
-  <p>pcp 服务监听的端口。</p>
-
-  <dt><code>username</strong></code></dt>
-  <p>访问 pcp 服务的用户名。</p>
-
-  <dt><code>password</strong></code></dt>
-  <p>访问 pcp 服务的密码。</p>
-
-  <dt><code>pcp_server</strong></code></dt>
-  <p>用于 pcp 服务的外部服务名。</p>
-
-</dd>
-
-</dd>
-</dl>
-</h3>
-
-<h3 id="func_pcp_attach_node">pcp_attach_node</h3>
-<dl>
-<dt>格式</dt>
-<dd>
-  <pre><code>pcp_attach_node(integer node_id, text host, integer port, text username, text password, OUT node_attached boolean) returns boolean</code></pre>
-  <pre><code>pcp_attach_node(integer node_id, text pcp_server, OUT node_attached boolean) returns boolean</code></pre>
-</dd>
-
-<dt>描述：</dt>
-<dd>
-  <p>将节点加入 pgpool-II。
-  参考 <a href="#pcp_attach_node">pcp_attach_node 命令</a> 获得更多细节信息。</p>
-  <p>
-    以下为示例输出：
-<pre>
-test=# SELECT * FROM pcp_attach_node(1,'localhost',11001,'t-ishii','t-ishii');
- node_attached
----------------
- t
-(1 row)
-</pre>
-  </p>
-</dd>
-
-<dt>参数：</dt>
-<dd>
-  <dl class="options">
-  <dt><code>node_id</strong></code></dt>
-  <p>后端节点的索引值。</p>
-
-  <dt><code>host</strong></code></dt>
-  <p>pcp 服务运行的主机名或者 IP 地址。</p>
-
-  <dt><code>port</strong></code></dt>
-  <p>pcp 服务监听的端口。</p>
-
-  <dt><code>username</strong></code></dt>
-  <p>访问 pcp 服务的用户名。</p>
-
-  <dt><code>password</strong></code></dt>
-  <p>访问 pcp 服务的密码。</p>
-
-  <dt><code>pcp_server</strong></code></dt>
-  <p>用于 pcp 服务的外部服务名。</p>
-
-</dd>
-
-</dd>
-</dl>
-</h3>
-
-<h3 id="func_pcp_detach_node">pcp_detach_node</h3>
-<dl>
-<dt>格式：</dt>
-<dd>
-  <pre><code>pcp_detach_node(integer node_id, boolean gracefully, text host, integer port, text username, text password, OUT node_detached boolean) returns boolean</code></pre>
-  <pre><code>pcp_detach_node(integer node_id, boolean gracefully, text pcp_server, OUT node_detached boolean) returns boolean</code></pre>
-</dd>
-
-<dt>描述：</dt>
-<dd>
-  <p>将一个节点从 pgpool-II 分离并启动一个故障恢复。
-  参考 <a href="#pcp_detach_node">pcp_detach_node</a> 获得更多细节信息。</p>
-  <p>
-    以下为示例输出：
-<pre>
-test=# SELECT * FROM pcp_detach_node(1, 'false', 'localhost',11001,'t-ishii','t-ishii');
- node_detached
----------------
- t
-(1 row)
-</pre>
-  </p>
-</dd>
-
-<dt>参数：</dt>
-<dd>
-  <dl class="options">
-  <dt><code>node_id</strong></code></dt>
-  <p>后端节点的索引值。</p>
-
-  <dt><code>gracefully</strong></code></dt>
-  <p>如果为 true，则等待所有的 pgpool-II 会话终止。
-  	实际上，指定这个值为 true 不是一个好的想法，因为这个查询将不会完成，因为会话本身在等待结果。
-  	强烈推荐将本参数指定为 false。
-  </p>
-
-  <dt><code>host</strong></code></dt>
-  <p>pcp 服务运行的主机名或者 IP 地址。</p>
-
-  <dt><code>port</strong></code></dt>
-  <p>pcp 服务监听的端口。</p>
-
-  <dt><code>username</strong></code></dt>
-  <p>访问 pcp 服务的用户名。</p>
-
-  <dt><code>password</strong></code></dt>
-  <p>访问 pcp 服务的密码。</p>
-
-  <dt><code>pcp_server</strong></code></dt>
-  <p>用于 pcp 服务的外部服务名。</p>
-
-</dd>
-
-</dd>
-</dl>
-</h3>
-
-<p class="top_link"><a href="#Top">返回顶部</a></p>
-
-<!-- ================================================================================ -->
-
-<h1><a name="troubleshooting"></a>故障解决</h1>
-<p>
-本节描述你使用 pgpool-II 时碰到的问题及其解决办法。
-</p>
-
-<dl>
-
-<dt id="health_check_failed">健康检查失败</dt>
-<dd>
-<p>
-    pgpool-II 的健康检查特性检测到DB节点失效。
-</p>
-
-<pre>
-2010-07-23 16:42:57 ERROR: pid 20031: health check failed. 1 th host foo at port 5432 is down
-2010-07-23 16:42:57 LOG:   pid 20031: set 1 th backend down status
-2010-07-23 16:42:57 LOG:   pid 20031: starting degeneration. shutdown host foo(5432)
-2010-07-23 16:42:58 LOG:   pid 20031: failover_handler: set new master node: 0
-2010-07-23 16:42:58 LOG:   pid 20031: failover done. shutdown host foo(5432)
-</pre>
-
-<p>
-    该日志表明DB节点1 (主机foo) 与pgpool中断并失去连接（关闭），
-    于是DB节点0成为新的master。检查DB节点1，处理掉产生故障的原因，
-    之后如果可能则会在 DB 节点 1 上执行一个在线恢复。
-</p>
-</dd>
-
-<dt id="failed_to_read_kind_from_frontend">无法从前端读取类型</dt>
-<dd>
-<pre>
-2010-07-26 18:43:24 LOG:   pid 24161: ProcessFrontendResponse: failed to read kind from frontend. frontend abnormally exited
-</pre>
-<p>
-    该日志表明前端程序未能与 pgpool-II 正确的断开。
-    可能的原因是：客户端应的 bug，客户端应用的强制结束(kill)或者是临时的网络故障。
-    该类型的事件不会导致一个DB的破坏或者数据一致性问题。
-    其仅仅是一个关于违反协议的的警告。
-    如果该消息一直出现，建议你检查应用和网络。
-</p>
-</dd>
-
-<dt id="kind_mismatch">类型匹配错误</dt>
-    <dd>
-    <p>
-    pgpool-II 操作在复制模式时你可能得到该消息。
-    </p>
-<pre>
-2010-07-22 14:18:32 ERROR: pid 9966: kind mismatch among backends. Possible last query was: "FETCH ALL FROM c;" kind details are: 0[T] 1[E: cursor "c" does not exist]
-</pre>
-    <p>
-    pgpool-II把 SQL 命令发送给数据库节点后便会等待响应。
-    该错误消息指示并非所有的数据库节点返回同样的响应。
-    你可能会在 "Possible last query was:" 之后看到引起错误的 SQL 语句，
-    接着是响应类型。如果响应指示是一个错误，则从 PostgreSQL 返回的错误消息将被显示出来。
-    这里你看到 "0[T]" 显示 DB 节点响应：0[T]"(开始发送行描述)，
-    以及 "1[E" 表示DB节点1返回一个错误，消息是"cursor "c" does not exist"，然而数据库节点 0 发送了一个行记录。
-    </p>
-    <p>
-    注意：在主/备模式时你同样会看到这类错误。
-    例如即使在主/备模式下，SET 命令将会被发送给所有的数据库节点以保持所有的节点处于同一个状态。
-    </p>
-    <p>
-    如果你发现数据库不再同步，检查数据库并使用在线复制异步它们。
-    </p>
-
-<p>
-<dt id="difference_of_number">pgpool-II 检查插入、更新或者删除的不同的行数</dt>
-    <dd>
-    <p>
-    在复制模式下，pgpool-II 检测到 INSERT/UPDATE/DELETE 在影响的节点上产生不同的行数。
-    </p>
-<pre>
-2010-07-22 11:49:28 ERROR: pid 30710: pgpool detected difference of the number of inserted, updated or deleted tuples. Possible last query was: "update t1 set i = 1;"
-2010-07-22 11:49:28 LOG:   pid 30710: ReadyForQuery: Degenerate backends: 1
-2010-07-22 11:49:28 LOG:   pid 30710: ReadyForQuery: Affected tuples are: 0 1
-</pre>
-    <p>
-    在上面的示例中，在不同的数据库节点上执行 "update t1 set i = 1"
-    返回更新的行数不同。下一行表明 DB 1 接着出现退化 (断开，disconnected)，
-    然后是DB节点0受影响的行数是0，然而节点1受影响的行数是1.
-    </p>
-    <p>
-    停止怀疑有错误数据的数据库节点并执行在线恢复。
-    </p>
-</dl>
-
-<p class="top_link"><a href="#Top">返回顶部</a></p>
-
-
-<!-- ================================================================================ -->
-
-<h1>限制<a name="restriction"></a></h1>
-
-<p>
-<h2>PostgreSQL的函数</h2>
-<p>
-<ul>
-<li>
-    如果你使用 pg_terminate_backend() 终止后台数据库，这会触发一个故障。
-    原因是 PostgreSQL 使用完全相同的消息来关闭 postmaster 以终止一个后台数据库，
-    目前还没有办法解决它，请不要使用该函数。
-</li>
-</ul>
-
-<p>
-<h2><a name="md5"></a>认证/访问控制</h2>
-
-<p>
-<ul>
-    <li>在复制模式或主/备模式中，trust, clear text password, 以及 pam 方法被支持，
-          md5 从 pgpool-II 3.0 之后开始被支持。通过使用 "pool_passwd" 文件来支持 md5。
-          "pool_passwd" 是默认的认证文件。你可以使用 <a href="#POOL_PASSWD">pool_passwd</a>
-          来改变文件名。下面是启用 md5 的步骤：
-        <ol>
-            <li>以数据库的操作系统用户(database's operating system user)登入，
-                并键入 "pg_md5 --md5auth --username=<your_username> <your_passwd>"，
-                用户名和md5加密的密码被注册进 pool_passwd。如果 pool_passwd 还不存在，
-                pg_md5 将会自动的为你创建。</li>
-            <li>pool_passwd 格式是 "username:encrypted_passwd".</li>
-            <li>你还需要在 pool_hba.conf 中增加一个相应的 md5 项。
-                详见<a href="#hba">为客户端认证设置 pool_hba.conf (HBA)</a>。</li>
-            <li>请注意的是用户名和密码必须和 PostgreSQL 中注册的一样</li>
-            <li>在修改 md5 密码后（当然，必须在 pool_passwd 和 PostgreSQL 都必须修改），
-                你需要执行 "pgpool reload" 或重启 pgpool（如果你的 pgpool 版本小于或等于 3.1）。</li>
-        </ol>
-    </li>
-    <li>在所有的其它模式中，trust, clear text password, crypt, md5, 以及 pam都被支持。</li>
-</ul>
-</p>
-
-<h2>大对象 (Large objects)</h2>
-<p>
-pgpool-II 2.3.2 或以上版本支持大对象复制，如果后台服务器是 PostgreSQL 8.1 或以上版本。
-有鉴于此，你需要启用 pgpool.conf 中的<a href="#lobj_lock_table">lobj_lock_table</a>。
-然而，使用后台函数 lo_import 的大对象复制不被支持。
-</p>
-
-<h2 id="temp_table_in_master_slave_mode">主/备模式中的临时表</h2>
-<p>
-Creating/inserting/updating/deleting 临时表将会永远在主（首要）节点上执行。
-pgpool-II 3.0 或以上版本中，也可以在这些主节点的表上执行 SELECT。
-然而，如果在 SELECT 中临时表名被用作一个符号，就没有办法来检测到它，
-这样 SELECT 将被负载均衡。这会产生一个 "not found the table" 错误或者会找到另外一个同名的表。
-为避免该问题，使用/*NO LOAD BALANCE*/ SQL 注释。
-</p>
-
-<pre>
-将会产生问题的示例 SELECT:
-SELECT 't1'::regclass::oid;
-</pre>
-
-<p>
-psql 的 \d 命令使用符号表名。
-pgpool-II 3.0 或更高版本检查是否 SELECT
-包含任何对系统表(system catalogs)的访问，
-并永远把这些查询发送到主节点，这样我们避免了该问题。
-</p>
-
-<h2 id="caution_in_replication_mode">复制模式中的函数等</h2>
-
-<p>不保证使用依赖上下文的机制所产生的数据
-（如 random number, transaction ID, OID, SERIAL, sequence），
-都会被在多个后台服务器上被正确的复制。</p>
-<p>对于SERIAL，启用insert_lock在数据复制中很有用。
-insert_lock 还有助于 SELECT setval() 和 SELECT nextval()。</p>
-
-<p>在 pgpool-II 2.3 或更高版本中，
-使用 CURRENT_TIMESTAMP,CURRENT_DATE, now()的 INSERT/UPDATE 将会被正确的复制。
-INSERT/UPDATE 使用 CURRENT_TIMESTAMP, CURRENT_DATE, now() 作为表的默认值时，
-也将会正确的复制。这通过执行时把这些函数替换成从master节点上获取的常量值来完成。
-然而仍有一些限制：
-</p>
-
-<ul>
-    <li>在 pgpool-II 3.0 或更低的以前的版本中，
-        计算表中默认值的临时数据在一些情况下并不准确，例如，下面的表定义：
-<pre>
-CREATE TABLE rel1(
-  d1 date DEFAULT CURRENT_DATE + 1
-)
-</pre>
-    被看成如下的表:
-<pre>
-CREATE TABLE rel1(
-  d1 date DEFAULT CURRENT_DATE
-)
-</pre>
-    <p>
-    pgpool-II 3.1 后更高版本能够正确的处理这些情况。
-    这样"d1"将会把明天(CURRENT_DATE + 1)作为默认值。
-    然而当扩展的协议(例如在JDBC, PHP PDO中使用的)或者 PREPARE 被使用时，这个改进并不适用。
-    </p>
-    <p>
-    请注意如果列类型不是临时的，重写并不会被执行，这样的例子：
-    </p>
-<pre>
-foo bigint default (date_part('epoch'::text,('now'::text)::timestamp(3) with time zone) * (1000)::double precision)
-</pre>
-    </li>
-
-    <li>假定我们有如下表：
-<pre>
-CREATE TABLE rel1(
-  c1 int,
-  c2 timestamp default now()
-)
-</pre>
-
-    我们可以复制：
-<pre>
-INSERT INTO rel1(c1) VALUES(1)
-</pre>
-
-    因为这将变为：
-<pre>
-INSERT INTO rel1(c1, c2) VALUES(1, '2009-01-01 23:59:59.123456+09')
-</pre>
-
-    然而，
-<pre>
-INSERT INTO rel1(c1) SELECT 1
-</pre>
-    不能够被转换，这样在当前的实现中不能被正确的复制，
-    值将仍然会被插入，但是没有进行任何的转换。
-    </li>
-</ul>
-
-<p>如果你在使用 8.3 或更高的版本 PostgreSQL ，
-并且在 reset_query_list 中指定 DISCARD ALL，
-那么将在会话的末尾处删除 <code>CREATE TEMP TABLE</code> 创建的表。
-</p>
-<p>
-对于8.2.x或更早的版本，
-退出会话时并不会删除 <code>CREATE TEMP TABLE</code> 创建的表。
-这是由于连接池的原因，从 PostgreSQL 后台的视角来看，
-要保持 session 处于活动状态。为避免这一点，
-你必须通过发出 <code>DROP TABLE</code> 命令显式的删除该临时表，
-或在事务块中使用 <code>CREATE TEMP TABLE ... ON COMMIT DROP</code> 语句。</p>
-
-<h2 id="ng_queries">Queries</h2>
-
-<p>以下是不能被 pgpool-II 处理的查询。</p>
-
-<h3 id="ng_multibyte_chars">多字节字符 (所有模式)</h3>
-
-<p>pgpool-II 不会在不同的多字节字符间进行转换。
-客户端和后端的 PostgreSQL 服务之间的编码必须相同。</p>
-
-<h3 id="ng_multi_statement">多语句（multi-statement）查询 (所有模式)</h3>
-<p>
-pgpool-II 无法处理多语句查询。
-</p>
-
-<h2>环境要求</h2>
-
-<h3>libpq</h3>
-
-<p>
-在编译构建pgpool-II时<code>libpq</code>被链接。libpq版本必须是3.0。使用2.0版本的libpq编译pgpool-II将会失败。而且System DB 必须是 PostgreSQL 7.4 或更高版本。
-</p>
-
-<p class="top_link"><a href="#Top">返回顶部</a></p>
-
-<!-- ================================================================================ -->
-
-<h1>入门教程</h1>
-<p>
-<a href="tutorial-zh_cn.html">pgpool-II入门教程</a> 已发布。
-</p>
-
-<p class="top_link"><a href="#Top">返回顶部</a></p>
-
-</div>
-
-<div class="copyright" style="clear: both">
-<hr>
-<copyright>
-Copyright &copy; 2003 &ndash; 2016 pgpool Global Development Group
-</copyright>
-</div>
-</body>
-</html>
diff --git a/doc/pgpool.8.in b/doc/pgpool.8.in
deleted file mode 100644
index a436e8f21..000000000
--- a/doc/pgpool.8.in
+++ /dev/null
@@ -1,121 +0,0 @@
-.\" Copyright 2004-2009 by PgPool Global Development Group
-.\" This man page is subject to the same license as the rest of pgpool.
-.\"
-.TH PGPOOL 8 "12 Oct 2009"
-.\" Please adjust this date whenever revising the manpage.
-.hy 0
-.ad l
-.nf
-.SH NAME
-pgpool \- PostgreSQL connection pool daemon
-.SH SYNOPSIS
-\fBpgpool\fR [ \fB\-c\fR] [ \fB\-f config_file\fR ] [ \fB\-F pcp_config_file\fR ] [ \fB\-a hba_file\fR ] [ \fB\-n\fR ] [ \fB\-D\fR ] [ \fB\-d\fR ]
-.LP
-\fBpgpool\fR [ \fB\-f config_file\fR ] [ \fB\-F pcp_config_file\fR ] [ \fB\-a hba_file\fR ] [ \fB\-m\fR \fI{s[mart]|f[ast]|i[mmediate]}\fR ] \fBstop\fR
-.LP
-\fBpgpool\fR [ \fB\-f config_file\fR ] [ \fB\-F pcp_config_file\fR ] [ \fB\-a hba_file\fR ] \fBreload\fR
-.LP
-.SH DESCRIPTION
-\fBpgpool\fR is a connection pool server for PostgreSQL.
-\fBpgpool\fR runs between PostgreSQL's client and server.
-Any PostgreSQL client can connect to \fBpgpool\fR as if it's a real PostgreSQL server.
-\fBpgpool\fR caches the connection to the PostgreSQL server to reduce the overhead
-involved in establishing the connection to it.
-.P
-\fBpgpool\fR can also be
-used with two PostgreSQL servers for fail over purposes.  If the first
-server goes down, \fBpgpool\fR will automatically switch to the secondary server.
-.P
-\fBpgpool\fR is typically started and stopped via system initialization scripts.
-.
-.P
-.SH INVOCATION
-.TP
-\fBpgpool\fP [ \fIoptions...\fP ]
-Starts as a daemon in the background (unless \fB\-n\fR is given).
-.TP
-\fBpgpool\fP [ \fIoptions...\fP ] \fBstop\fP
-Shutdown.
-.TP
-\fBpgpool\fP [ \fIoptions...\fP ] \fBreload\fP
-Reloads the configuration.
-.
-.SH OPTIONS
-.TP
-\fB\-a\fR \fIpath\fR
-.P
-.B \--hba-file\fR \fIpath\fR
-Sets the path to the \fIpool_hba.conf\fR configuration file (default: \fI@sysconfdir@/pgpool_hba.conf\fR).
-.TP
-\fB\-c\fR
-.P
-.B \--clear-cache
-Clears the query cache.
-.TP
-\fB\-d\fR
-.P
-.B \--debug
-Print lots of debug messages.
-.TP
-\fB\-f\fR \fIpath\fR
-.P
-.B \--config-file\fR \fIpath\fR
-Sets the path to the \fIpgpool.conf\fR configuration file (default: \fI@sysconfdir@/pgpool.conf\fR).
-.TP
-\fB\-F\fR \fIpath\fR
-.P
-.B \--pcp-config-file\fR \fIpath\fR
-Sets the path to the \fIpcp.conf\fR configuration file (default: \fI@sysconfdir@/pcp.conf\fR).
-.TP
-\fB\-h\fR
-.P
-.B \--help
-Print a help message and exit.
-.TP
-\fB\-m\fR \fImode\fR
-.P
-.B \--mode\fR \fImode\fR
-Shutdown mode: 
-.B smart, fast, 
-or
-.BR immediate .
-.TP
-\fB\-n\fR
-.P
-.B \--no-daemon
-Foreground mode.
-Error messages go to stdout or stderr, which
-could be piped out to log processors such as
-.BR logger (1)
-or
-.BR rotatelogs (8).
-To daemonize, explicitly invoke 
-.B pgpool
-in background.
-.TP
-.B \-D
-.P
-.B \--discard-status
-Discard pgpool_status file and do not restore previous status.
-.TP
-.B \-v
-.P
-.B \--version
-Print version and exit.
-.
-.SH FILES
-.TP
-\fI@sysconfdir@/pgpool.conf\fR
-Default configuration file
-.TP
-\fI@sysconfdir@/pool_hba.conf\fR
-Host Based Access configuration file
-.TP
-\fI@sysconfdir@/pcp.conf\fR
-PCP commands configuration file
-.SH SEE ALSO
-.BR logger (1),
-.BR postmaster (1),
-.BR rotatelogs (8)
-.PP
-Additional information can be found in the \fBpgpool\fR \fIREADME\fR file.
diff --git a/doc/pgpool.css b/doc/pgpool.css
deleted file mode 100644
index fa8ff913b..000000000
--- a/doc/pgpool.css
+++ /dev/null
@@ -1,292 +0,0 @@
-ul#navlist
-	{
-	width: 158px>;
-	\width: 160px;
-	w\idth: 158px;
-	padding: 0px;
-	border: 1px solid #808080;
-	border-top: 0px;
-	margin: 0px;
-	font: bold 12px verdana,helvetica,arial,sans-serif;
-	background: #808080;
-	}
-	
-	ul#navlist li
-	{
-	list-style: none;
-	margin: 0px;
-	border: 0px;
-	border-top: 1px solid #808080;
-	font-size:7pt;
-	}
-	
-	ul#navlist li a
-	{
-	display: block;
-	width: 122px;
-	\width: 158px;
-	w\idth: 122px;
-	padding: 4px 8px 4px 8px;
-	border: 0px;
-	border-left: 20px solid #aaaabb;
-	background: #ccccdd;
-	text-decoration: none;
-	text-align: right;
-	
-	}
-	
-	ul#navlist li a:link { color: #666677; }
-	div#navcontainer li a:visited { color: #666677; }
-	
-	ul#navlist li a:hover
-	{
-	border-color: #ff9000;
-	color: #ffffff;
-	background: #000d33;
-	}
-
-	ul#navlist li > ul
-	{
-	margin-left: 0px;
-	padding-left: 0px;
-	}
-	ul#navlist li > ul li a {
-	border-left: 20px solid #B9B9CE;
-	background: #DEDEEF;
-	}
-	
-/* --------------------------- */
-#menu {
-	border-right:1px dotted #cccccc;
-	float: left;
-	padding-top: 20px;
-}
-#navcontainer {
-	margin-bottom: 20px;
-}
-#manual {
-	border-left:1px dotted #cccccc;
-	width: 800px;
-	float: left;
-}
-body {
-	font-family:Verdana, Arial, Helvetica, sans-serif;
-	font-size:9pt;
-	margin: 0px;
-	color: black;
-	border-left: 20px solid #ccc;
-}
-pre {
-	background-color:#f0f0f0;
-	color: brown;
-	padding: 5px;
-	margin-left:40px;
-	margin-right:30px;
- 	word-wrap: break-word;
- 	word-break: break-all;
-	overflow: auto;
-}
-h1 {
-	margin-top: 50px;
-	border-bottom: 2px solid #6699CC;
-	padding: 5px;
-	margin-left:10px;
-	background:#6699CC;
-	color: #ffffff;
-}
-h2 {
-	margin-top: 30px;
-	padding: 5px;
-	margin-left:30px;
-	background: #8CD8E2;
-}
-
-h3 {
-	margin-top: 30px;
-	border: 2px solid #8CD8E2;
-	border-left: 10px solid #8CD8E2;
-	padding: 5px;
-	margin-left:40px;
-	background: #F4F8F1;
-}
-
-h4 {
-	border-bottom: 2px solid #8CD8E2;
-	padding: 5px;
-	margin-left:40px;
-	background: #F4F8F1;
-}
-
-p {
-	margin: 3px 25px 3px 40px;
-	text-indent: 1em;
-}
-
-li p, dd p {
-	text-indent: 0em;
-	color: black;
-}
-
-ul, ol,dl {
-	margin-left:40px;
-	padding-right: 30px;
-}
-dt {
-	font-weight:bold;
-}
-
-ul li {
-	padding-right: 30px;
-	list-style:square;
-	color: #663333;
-}
-
-ul li ul li {
-	list-style: circle;
-}
-
-ul li ol li {
-	list-style: decimal;
-}
-
-
-ol li {
-	padding-right: 30px;
-	color: #663333;
-}
-
-
-table {
-	margin-left:40px;
-	border-collapse: collapse;
-	border: #666666 1px solid;
-	margin-bottom: 10px;
-}
-th, td {
-	padding: 5px;
-	font-size:10pt;
-}
-th {
-	font-weight: normal;
-	background-color: #eeeeee;
-}
-th.nodec {
-	text-align: left;
-	white-space: nowrap;
-}
-tr.header th {
-	font-weight: bold;
-	background-color: #cccccc;
-	border-bottom: double;
-}
-tr.center td {
-	text-align: center;
-}
-tr.footer {
-	border-top: double;
-}
-
-dd {
-	margin-left: 0px;
-}
-	a:link { color: blue; }
-	a:hover { color: red; }
-
-p.top_link {
-	text-align: right;
-}
-p.top_link a {
-	text-decoration: none;
-	border: #aaaaaa 1px solid;
-	border-radius: 3px;
-	background-color: #eeeeee;
-	padding: 1px 5px;
-	color: #666666;
-}
-.header_small {
-	font-size: 0.9em;
-	background-color: #f0f0f0;
-	
-}
-.header_text {
-	border-bottom: 2px solid #663366;
-	padding: 5px;
-	background-color: #E9F8F8;	
-	font-size: 2em;
-	font-weight:bold;
-	padding:25px;
-}
-
-.copyright {
-	padding: 5px;
-	padding:25px;
-	text-align:center;
-}
-.version {
-	font-size: smaller;
-	font-weight: bold;
-	border: 1px solid #B27F00;
-	background-color: orange;
-	padding: 1px 3px;
-	border-radius: 3px;
-	color: white;
-}
-h1 .version {
-	border-radius: 5px;
-	border-color: white;
-}
-.version_notice {
-	border-left: 7px solid orange;
-	border-right: 5px solid orange;
-	padding: 5px;
-}
-.caution {
-	font-weight: bold;
-	color: red;
-}
-dl.flat dt {
-	clear: both;
-	float: left;
-	width: 40px;
-	line-height: 150%;
-}
-dl.flat dd {
-	padding-left: 50px;
-	line-height: 150%;
-}
-dl.flat dd * {
-	margin-left: 0px;
-}
-dl.options {
-	margin: 10px 0px 10px 40px;
-}
-dl.options dt {
-	font-weight:normal;
-}
-dl.options dd {
-	margin: 10px 0px 10px 0px;
-}
-li dl dt {
-	font-weight: normal;
-	display: list-item;
-	list-style: square outside;
-}
-li dl dd {
-	margin-bottom: 10px;
-}
-ul.flat_ul {
-	margin: 0px;
-	list-style-type: none;
-}
-ul.flat_ul li {
-	display: inline-block;
-	border: 1px solid #666;
-	border-radius: 3px;
-	width: 100px;
-	margin: 3px;
-	padding: 0px;
-	text-align: center;
-}
-ul.flat_ul li a {
-	text-decoration: none;
-}
diff --git a/doc/pgpool_adm.odp b/doc/pgpool_adm.odp
deleted file mode 100644
index ef4877fd9..000000000
Binary files a/doc/pgpool_adm.odp and /dev/null differ
diff --git a/doc/pgpool_adm.png b/doc/pgpool_adm.png
deleted file mode 100644
index f9f265b3c..000000000
Binary files a/doc/pgpool_adm.png and /dev/null differ
diff --git a/doc/pgpool_remote_start b/doc/pgpool_remote_start
deleted file mode 100644
index afd0e61ad..000000000
--- a/doc/pgpool_remote_start
+++ /dev/null
@@ -1,13 +0,0 @@
-#! /bin/sh
-
-if [ $# -ne 2 ]
-then
-    echo "pgpool_remote_start remote_host remote_datadir"
-    exit 1
-fi
-
-DEST=$1
-DESTDIR=$2
-PGCTL=/usr/local/pgsql/bin/pg_ctl
-
-ssh -T $DEST $PGCTL -w -D $DESTDIR start 2>/dev/null 1>/dev/null < /dev/null &
diff --git a/doc/recovery.conf.sample b/doc/recovery.conf.sample
deleted file mode 100644
index 722c7d677..000000000
--- a/doc/recovery.conf.sample
+++ /dev/null
@@ -1,117 +0,0 @@
-# -------------------------------
-# PostgreSQL recovery config file
-# -------------------------------
-#
-# Edit this file to provide the parameters that PostgreSQL needs to
-# perform an archive recovery of a database, or to act as a log-streaming
-# replication standby.
-#
-# If "recovery.conf" is present in the PostgreSQL data directory, it is
-# read on postmaster startup.  After successful recovery, it is renamed
-# to "recovery.done" to ensure that we do not accidentally re-enter
-# archive recovery or standby mode.
-#
-# This file consists of lines of the form:
-#
-#   name = 'value'
-#
-# (The quotes around the value are NOT optional, but the "=" is.)
-#
-# Comments are introduced with '#'.
-#
-# The complete list of option names and allowed values can be found
-# in the PostgreSQL documentation.
-#
-#---------------------------------------------------------------------------
-# ARCHIVE RECOVERY PARAMETERS
-#---------------------------------------------------------------------------
-#
-# restore_command
-#
-# specifies the shell command that is executed to copy log files
-# back from archival storage.  The command string may contain %f,
-# which is replaced by the name of the desired log file, and %p,
-# which is replaced by the absolute path to copy the log file to.
-#
-# This parameter is *required* for an archive recovery, but optional
-# for streaming replication.
-#
-# It is important that the command return nonzero exit status on failure.
-# The command *will* be asked for log files that are not present in the
-# archive; it must return nonzero when so asked.
-#
-# NOTE that the basename of %p will be different from %f; do not
-# expect them to be interchangeable.
-#
-#restore_command = ''		# e.g. 'cp /mnt/server/archivedir/%f %p'
-#
-#
-# archive_cleanup_command
-#
-# specifies an optional shell command to execute at every restartpoint.
-# This can be useful for cleaning up the archive of a standby server.
-#
-#archive_cleanup_command = ''
-#
-# recovery_end_command
-#
-# specifies an optional shell command to execute at completion of recovery.
-# This can be useful for cleaning up after the restore_command.
-#
-#recovery_end_command = ''
-#
-#---------------------------------------------------------------------------
-# RECOVERY TARGET PARAMETERS
-#---------------------------------------------------------------------------
-#
-# By default, recovery will rollforward to the end of the WAL log.
-# If you want to stop rollforward at a specific point, you
-# must set a recovery target.
-#
-# You may set a recovery target either by transactionId, or
-# by timestamp. Recovery may either include or exclude the
-# transaction(s) with the recovery target value (ie, stop either
-# just after or just before the given target, respectively).
-#
-#recovery_target_time = ''	# e.g. '2004-07-14 22:39:00 EST'
-#
-#recovery_target_xid = ''
-#
-#recovery_target_inclusive = 'true'
-#
-#
-# If you want to recover into a timeline other than the "main line" shown in
-# pg_control, specify the timeline number here, or write 'latest' to get
-# the latest branch for which there's a history file.
-#
-#recovery_target_timeline = 'latest'
-#
-#---------------------------------------------------------------------------
-# STANDBY SERVER PARAMETERS
-#---------------------------------------------------------------------------
-#
-# When standby_mode is enabled, the PostgreSQL server will work as
-# a standby. It tries to connect to the primary according to the
-# connection settings primary_conninfo, and receives XLOG records
-# continuously.
-#
-#standby_mode = 'off'
-#
-#primary_conninfo = ''		# e.g. 'host=localhost port=5432'
-#
-#
-# By default, a standby server keeps streaming XLOG records from the
-# primary indefinitely. If you want to stop streaming and finish recovery,
-# opening up the system in read/write mode, specify path to a trigger file.
-# Server will poll the trigger file path periodically and stop streaming
-# when it's found.
-#
-#trigger_file = ''
-#
-#---------------------------------------------------------------------------
-# HOT STANDBY PARAMETERS
-#---------------------------------------------------------------------------
-#
-# Hot Standby related parameters are listed in postgresql.conf
-#
-#---------------------------------------------------------------------------
diff --git a/doc/tutorial-en.html b/doc/tutorial-en.html
deleted file mode 100644
index c446cc922..000000000
--- a/doc/tutorial-en.html
+++ /dev/null
@@ -1,707 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
-
-<html>
-
-<head>
-<title>pgpool-II Tutorial</title>
-<meta http-equiv="Content-Type" content="text/html" />
-<link href="pgpool.css" rel="stylesheet" type="text/css" />
-</head>
-
-<body>
-<h1>pgpool-II Tutorial</h1>
-<p>Welcome to the Tutorial for pgpool-II. From here, you can learn how
-to install, setup, and run parallel queries or do replication using
-pgpool-II. We assume that you already know basic PostreSQL operations,
-so please refer to the PostgreSQL document if neccesary.</p>
-
-<dl>
-  <dt><em>Table of Contents</em></dt>
-  <dt>1. <a href="#start">Let's Begin!</a></dt>
-  <dd>1.1. <a href="#install">Installing pgpool-II</a></dd>
-  <dd>1.2. <a href="#config">Configuration Files</a></dd>
-  <dd>1.3. <a href="#pcp-config">Configuring PCP commands</a></dd>
-  <dd>1.4. <a href="#db-node">Preparing Database Nodes</a></dd>
-  <dd>1.5. <a href="#start-shutdown">Starting/Stopping pgpool-II</a></dd>
-  <dt>2. <a href="#replication">Your First Replication</a></dt>
-  <dd>2.1. <a href="#replication-config">Configuring Replication</a></dd>
-  <dd>2.2. <a href="#replication-check">Checking Replication</a></dd>
-  <dt>3. <a href="#parallel">Your First Parallel Query</a></dt>
-  <dd>3.1. <a href="#parallel-config">Configuring Parallel Query</a></dd>
-  <dd>3.2. <a href="#system-db">Configuring the System Database</a></dd>
-  <dd>3.3. <a href="#dist-def">Partitioning Rule Definition</a></dd>
-  <dd>3.4. <a href="#replicate-def">Replication Rule Definition</a></dd>
-  <dd>3.5. <a href="#parallel-check">Checking Parallel Query</a></dd>
-</dl>
-
-
-<h2>1. <a name="start">Let's Begin!</a></h2>
-
-<p>First, we must learn how to install and configure pgpool-II and
-database nodes before using replication or parallel query.</p>
-
-<h3>1.1. <a name="install">Installing pgpool-II</a></h3>
-
-<p>Installing pgpool-II is very easy. In the directory which you have
-extracted the source tar ball, execute the following commands.</p>
-
-<pre>
-$ ./configure
-$ make
-$ make install
-</pre>
-
-<p><code>configure</code> script collects your system information
-and use it for the compilation procedure. You can pass command line
-arguments to <code>configure</code> script to change the default
-behavior, such as the installation directory. pgpool-II will be
-installed to <code>/usr/local</code> directory by default.</p>
-
-<p><code>make</code> command compiles the source code, and <code>make
-install</code> will install the executables. You must have write
-permission on the installation directory.</p>
-
-<p>In this tutorial, we will install pgpool-II in the default
-<code>/usr/local</code> directory.</p>
-
-<p><em>Note</em>: pgpool-II requires libpq library in PostgreSQL 7.4
-or later (version 3 protocol). If the <code>configure</code> script
-displays the following error message, the libpq library may not be
-installed, or it is not of version 3.</p>
-
-<pre>configure: error: libpq is not installed or libpq is old</pre>
-
-<p>If the library is version 3, but the above message is still displayed,
-your libpq library is probably not recognized by
-the <code>configure</code> script.</p>
-
-<p>The <code>configure</code> script searches for libpq library under
-<code>/usr/local/pgsql</code>. If you have installed
-PostgreSQL in a directory other than <code>/usr/local/pgsql</code>,
-use <code>--with-pgsql</code>, or <code>--with-pgsql-includedir</code>
-and <code>--with-pgsql-libdir</code> command line options when you
-execute <code>configure</code>.</p>
-
-<h3>1.2. <a name="config">Configuration Files</a></h3>
-
-<p>pgpool-II configuration parameters are saved in
-the <code>pgpool.conf</code> file. The file is in "<code>parameter =
-value</code>" per line format. When you install pgpool-II,
-<code>pgpool.conf.sample</code> is automatically created. We recommend
-copying and renaming it to <code>pgpool.conf</code>, and edit it as
-you like.</p>
-
-<pre>$ cp /usr/local/etc/pgpool.conf.sample /usr/local/etc/pgpool.conf</pre>
-
-<p>pgpool-II only accepts connections from the local host using port
-9999. If you wish to receive conenctions from other hosts, set
-<code>listen_addresses</code> to '*'.</code></p>
-
-<pre>
-listen_addresses = 'localhost'
-port = 9999
-</pre>
-
-<p>We will use the default parameters in thie tutorial.</p>
-
-<h3>1.3. <a name="pcp-config">Configuring PCP Commands</a></h3>
-
-<p>pgpool-II has an interface for administrative purpose to retrieve
-information on database nodes, shutdown pgpool-II, etc. via
-network. To use PCP commands, user authentication is required. This
-authentication is different from PostgreSQL's user authentication. A
-user name and password need to be defined in the <code>pcp.conf</code>
-file. In the file, a user name and password are listed as a pair on
-each line, and they are separated by a colon (:). Passwords are
-encrypted in md5 hash format.</p>
-
-<pre>postgres:e8a48653851e28c69d0506508fb27fc5</pre>
-<p>
-When you install pgpool-II, <code>pcp.conf.sample</code> is
-automatically created. We recommend copying and renaming it to
-<code>pcp.conf</code>, and edit it.
-</p>
-<pre>$ cp /usr/local/etc/pcp.conf.sample /usr/local/etc/pcp.conf</pre>
-
-<p>To encrypt your password into md5 hash format, use the pg_md5 command,
-which is installed as one of pgpool-II's
-executables. <code>pg_md5</code> takes text as a command line
-argument, and displays its md5-hashed text.</p>
-
-<p>For example, give "postgres" as the command line argument, and
-<code>pg_md5</code> displays md5-hashed text on its standard
-output.</p>
-
-<pre>
-$ /usr/bin/pg_md5 postgres
-e8a48653851e28c69d0506508fb27fc5
-</pre>
-
-<p>PCP commands are executed via network, so the port number must be
-configured with <code>pcp_port</code> parameter in
-<code>pgpool.conf</code> file.</p>
-
-<p>We will use the default 9898 for <code>pcp_port</code> in this tutorial.</p>
-
-<pre>pcp_port = 9898</pre>
-
-<h3>1.4. <a name="db-node">Preparing Database Nodes</a></h3>
-
-<p>Now, we need to set up backend PostgreSQL servers for
-pgpool-II. These servers can be placed within the same host as
-pgpool-II, or on separate machines. If you decide to place the servers
-on the same host, different port numbers must be assigned for each
-server. If the servers are placed on separate machines, they must be
-configured properly so that they can accept network connections from
-pgpool-II.</p>
-
-<p>In this tutorial, we will place three servers within the same host
-as pgpool-II, and assign 5432, 5433, 5434 port numbers
-respectively. To configure pgpool-II, edit <code>pgpool.conf</code> as
-follows.
-
-<pre>
-backend_hostname0 = 'localhost'
-backend_port0 = 5432
-backend_weight0 = 1
-backend_hostname1 = 'localhost'
-backend_port1 = 5433
-backend_weight1 = 1
-backend_hostname2 = 'localhost'
-backend_port2 = 5434
-backend_weight2 = 1
-</pre>
-
-<p>For <code>backend_hostname</code>, <code>backend_port</code>,
-<code>backend_weight</code>, set the node's hostname, port number, and
-ratio for load balancing. At the end of each parameter string, node ID
-must be specified by adding positive integers starting with 0 (i.e. 0,
-1, 2, &hellip;).</p>
-
-<p><code>backend_weight</code> parameters are all 1, meaning that
-SELECT queries are equally distributed among three servers.</p>
-
-<h3>1.5. <a name="start-shutdown">Starting/Stopping pgpool-II</a></h3>
-
-<p>To fire up pgpool-II, execute the following command on a terminal.</p>
-
-<pre>$ pgpool</pre>
-
-<p>The above command, however, prints no log messages because pgpool
-detaches the terminal. If you want to show pgpool log messages, you
-pass <code>-n</code> option to pgpool command so pgpool-II is executed
-as non-daemon process, and the terminal will not be detached.
-</p>
-
-<pre>
-$ pgpool -n &
-</pre>
-
-<p>
-The log messages are printed on the terminal, so the recommended
-options to use the following.
-</p>
-
-<pre>$ pgpool -n -d &gt; /tmp/pgpool.log 2&gt;&1 &</pre>
-
-<p>The <code>-d</code> option enables debug messages to be generated.</p>
-
-<p>
-The above command keeps appending log messages to /tmp/pgpool.log. If
-you need to rotate log files, pass the logs to a external command
-which has log rotation function. 
-
-For example, you can use rotatelogs from Apache2:
-<pre>
-$ pgpool -n 2>&1 | /usr/local/apache2/bin/rotatelogs \
-  -l -f /var/log/pgpool/pgpool.log.%A 86400 &
-</pre>
-This will generate a log file named "pgpool.log.Thursday" then
-rotate it 00:00 at midnight. Rotatelogs adds logs to a file if it already
-exists. To delete old log files before rotation, you could use cron:
-<pre>
-55 23 * * * /usr/bin/find /var/log/pgpool -type f -mtime +5 -exec /bin/rm -f '{}' \;
-</pre>
-Please note that rotatelogs may exist as /usr/sbin/rotatelogs2 in some
-distributions.
--f option generates a log file as soon as rotatelogs starts and is
-available in apache2 2.2.9 or greater.
-</p>
-<p>
-Also <a
-href="http://www.cronolog.org"><code>cronolog</code></a> can be used.
-</p>
-
-<pre>
-$ pgpool -n 2>&1 | /usr/sbin/cronolog \
-  --hardlink=/var/log/pgsql/pgpool.log \
-  '/var/log/pgsql/%Y-%m-%d-pgpool.log' &
-</pre>
-
-<p>To stop pgpool-II, execute the following command.</p>
-
-<pre>$ pgpool stop</pre>
-
-<p>If any client is still connected, pgpool-II waits for it to
-disconnect, and then terminates itself. Run the following command
-instead if you want to shutdown pgpool-II forcibly.
-
-<pre>$ pgpool -m fast stop</pre>
-
-<h2>2. <a name="replication">Your First Replication</a></h2>
-
-<p>Replication enables the same data to be copied to multiple database
-nodes.</p>
-
-<p>In this section, we'll use three database nodes, which we have
-already set up in section "1. <a href="#start">Let's Begin!</a>", and
-takes you step by step to create a database replication system. Sample
-data to be replicated will be generated by the pgbench benchmark
-program.</p>
-
-<h3>2.1. <a name="replication-config">Configuring Replication</a></h3>
-
-<p>To enable the database replication function, set
-<code>replication_mode</code> to true in <code>pgpool.conf</code>
-file.</p>
-
-<pre>replication_mode = true</pre>
-
-<p>When <code>replication_mode</code> is set to true, pgpool-II will send a
-copy of a received query to all the database nodes.</p>
-
-<p>When <code>load_balance_mode</code> is set to true, pgpool-II will
-distribute SELECT queries among the database nodes.</p>
-
-<pre>load_balance_mode = true</pre>
-
-<p>In this section, we enable both <code>replication_mode</code> and
-<code>load_balance_mode</code>.</p>
-
-<h3>2.2. <a name="replication-check">Checking Replication</a></h3>
-
-<p>To reflect the changes in <code>pgpool.conf</code>, pgpool-II must
-be restarted. Please refer to section "1.5 <a
-href="#start-shutdown">Starting/Stopping pgpool-II</a>".</p>
-
-<p>After configuring <code>pgpool.conf</code> and restarting
-pgpool-II, let's try the actual replication and see if everything is
-working.</p>
-
-<p>First, we need to create a database to be replicated. We will name
-it "bench_replication". This database needs to be created on all the
-nodes. Use the <code>createdb</code> commands through pgpool-II, and the
-database will be created on all the nodes.</p>
-
-<pre>$ createdb -p 9999 bench_replication</pre>
-
-<p>Then, we'll execute pgbench with <code>-i</code>
-option. <code>-i</code> option initializes the database with
-pre-defined tables and data.</p>
-
-<pre>$ pgbench -i -p 9999 bench_replication</pre>
-
-<p>The following table is the summary of tables and data, which will
-be created by <code>pgbench -i</code>. If, on all the nodes, the
-listed tables and data are created, replication is working correctly.
-
-<table border="1" align="center">
-<tr>
-<th>Table Name</th>
-<th>Number of Rows</th>
-</tr>
-<tr>
-<td>branches</td>
-<td>1</td>
-</tr>
-<tr>
-<td>tellers</td>
-<td>10</td>
-</tr>
-<tr>
-<td>accounts</td>
-<td>100000</td>
-</tr>
-<tr>
-<td>history</td>
-<td>0</td>
-</tr>
-</table>
-
-<p>Let's use a simple shell script to check the above on all the
-nodes. The following script will display the number of rows in
-branches, tellers, accounts, and history tables on all the nodes (5432,
-5433, 5434).</p>
-
-<pre>$ for port in 5432 5433 5434; do
-&gt;     echo $port
-&gt;     for table_name in branches tellers accounts history; do
-&gt;         echo $table_name
-&gt;         psql -c &quot;SELECT count(*) FROM $table_name&quot; -p $port bench_replication
-&gt;     done
-&gt; done
-</pre>
-
-<h2>3. <a name="parallel">Your First Parallel Query</a></h2>
-<p>
-Data within the range is stored in two or more data base nodes in a parallel Query. This is called a partitioning. 
-Moreover you could replicate some of tables among database nodes even
-in parallel query mode.
-</p>
-
-<p>To enable parallel query in pgpool-II, you must set up another
-database called "System Database" (we will denote it as SystemDB from
-this point).</p>
-
-<p>SystemDB holds the user-defined rules to decide what data will be
-saved in which database node. Another use of SystemDB is to merge
-results sent back from the database nodes using dblink.</p>
-
-<p>In this section, we will use three database nodes which we have set
-up in section "1. <a href="#start">Let's Begin!</a>", and takes you
-step by step to create a parallel query database system. We will use
-pgbench again to create sample data.</p>
-
-<h3>3.1. <a name="parallel-config">Configuring Parallel Query</a></h3>
-
-<p>To enable the parallel query function, set <code>parallel_mode</code> to true in <code>pgpool.conf</code> file.</p>
-
-<pre>parallel_mode = true</pre>
-
-<p>Setting <code>paralle_mode</code> to true does not start parallel
-query automatically. pgpool-II needs SystemDB and the rules
-to know how to distribute data to the database nodes.</p>
-
-<p>Also, dblink used by SystemDB makes connections to
-pgpool-II. Therefore, <code>listen_addresses</code> needs to be
-configured so that pgpool-II accepts those connections.</p>
-
-<pre>listen_addresses = '*'</pre>
-
-<p>
-Attention: The replication is not done for the table that does the partitioning
-though a parallel Query and the replication can be made effective at the same time. 
-
-<p>
-Attention: You can have both partitioned tables and replicated
-tables. However a table cannot be a partioned and replicated at
-the same time. Because the data structure of partioned tables and
-replicated tables is different, "bench_replication" database created
-in section "2. <a href="#replication">Your First Replication</a>"
-cannot be reused in parallel query mode.</p>
-
-<pre>
-replication_mode = true
-load_balance_mode = false
-</pre>
-<p>
-OR
-</p>
-<pre>
-replication_mode = false
-load_balance_mode = true
-</pre>
-
-<p>In this section, we will set <code>parallel_mode and load_balance_mode</code> to true,
-<code>listen_addresses</code> to '*', <code>replication_mode</code>to false.</p>
-
-<h3>3.2. <a name="system-db">Configuring SystemDB</a></h3>
-
-<p> "System database" is just an ordinaly database. The only
-requirement is that dblink functions and the dist_def table, which
-describes partioning rule, must be installed in the system
-database. You could have a system database on a database node, or you
-could have multiple nodes having system database by using cascade
-configuration in pgpool-II.  </p>
-
-<p>In this section, we will create SystemDB on the 5432 port
-node. The following list is the configuration parameters for
-SystemDB</p>
-
-<pre>
-system_db_hostname = 'localhost'
-system_db_port = 5432
-system_db_dbname = 'pgpool'
-system_db_schema = 'pgpool_catalog'
-system_db_user = 'pgpool'
-system_db_password = ''
-</pre>
-
-<p>Actually, the above are the default settings of
-<code>pgpool.conf</code>. Now, we must create a user called "pgpool",
-and a database called "pgpool" owned by user "pgpool".</p>
-
-<pre>
-$ createuser -p 5432 pgpool
-$ createdb -p 5432 -O pgpool pgpool
-</pre>
-
-<h4><p>3.2.1. Installing dblink</p></h4>
-
-<p>Next, we must install dblink into "pgpool" database. dblink is one
-of the tools included in the <code>contrib</code> directory in the
-PostgreSQL source code.</p>
-
-<p>To install dblink to your system, execute the following commands.</p>
-
-<pre>
-$ USE_PGXS=1 make -C contrib/dblink
-$ USE_PGXS=1 make -C contrib/dblink install
-</pre>
-
-<p>After dblink has been installed into your system, we will define
-dblink functions in the "pgpool" database. If PostgreSQL is installed in
-<code>/usr/local/pgsql</code>, <code>dblink.sql</code> (a file with
-function definitions) should have been installed in
-<code>/usr/local/pgsql/share/contrib</code>. Now, execute the
-following command to define dblink functions.</p>
-
-<pre>$ psql -f /usr/local/pgsql/share/contrib/dblink.sql -p 5432 pgpool</pre>
-
-<h4><p>3.2.2. Defining dist_def table</p></h4>
-<p>
-Define a table called "dist_def", which has the partitioning rule, in
-database called "pgpool".
-After installing pgpool-II, you will have <code>system_db.sql</code>,
-which is the <code>psql</code> script to generate the system database.
-</p>
-<pre>
-$ psql -f /usr/local/share/system_db.sql -p 5432 -U pgpool pgpool
-</pre>
-<p>
-dist_def table is created in pgpool_catalog schema.
-If you have configured
-<code>system_db_schema</code> to use other schema, you need to edit
-<code>system_db.sql</code> accordingly.</p>
-
-<p>The definition for "dist_def" is as shown here, and the table name
-cannot be changed.</p>
-
-<pre>
-CREATE TABLE pgpool_catalog.dist_def (
-    dbname text, -- database name
-    schema_name text, -- schema name
-    table_name text, -- table name
-    col_name text NOT NULL CHECK (col_name = ANY (col_list)), -- distribution key-column
-    col_list text[] NOT NULL, -- list of column names
-    type_list text[] NOT NULL, -- list of column types
-    dist_def_func text NOT NULL, -- distribution function name
-    PRIMARY KEY (dbname, schema_name, table_name)
-);
-</pre>
-
-<p>A tuple stored in "dist_def" can be classified into two types.</p>
-
-<ul>
-<li>Distribution Rule (col_name, dist_def_func)</li>
-<li>Table's meta-information (dbname, schema_name, table_name, col_list, type_list)</li>
-</ul>
-
-<p>A distribution rule decides how to distribute data to a
-particular node. Data will be distributed depending on the value of
-the "col_name" column. "dist_def_func" is a function that takes the value
-of "col_name" as its argument, and returns an integer which
-points to the appropriate database node ID where the data should be
-stored.</p>
-
-<p>A meta-information is used to rewrite queries. Parallel query
-must rewrite queries so that the results sent back from the backend
-nodes can be merged into one result.</p>
-
-<h4><p>3.2.3. Defining replicate_def table</p></h4>
-<p>
-If you want to use replicated tables in SELECT in parallel mode, you
-need to register information about such tables(replication rule) to a table
-called replicate_def.
-The replicate_def table has already been made when making it from the 
-system_db.sql file when dist_def is defined. 
-The replicate_def table is defined as follows.
-</p>
-<pre>
-CREATE TABLE pgpool_catalog.replicate_def (
-    dbname text, -- database name
-    schema_name text, -- schema name
-    table_name text, -- table name
-    col_list text[] NOT NULL, -- list of column names
-    type_list text[] NOT NULL, -- list of column types
-    PRIMARY KEY (dbname, schema_name, table_name)
-);
-</pre>
-<p>
-replicate_def includes table's meta data information(dbname, schema_name, table_name, col_list, type_list).
-</p>
-<p>
-All the query analysis and query rewriting process are dependent on the
-information (table, column and type) stored in dist_def and/or
-replicate_def table.  If the information is not correct, analysis and
-query rewriting process will produce wrong results.
-</p>
-
-<h3>3.3. <a name="dist-def">Defining Distribution Rules</a></h3>
-
-<p>In this tutorial, we will define rules to distribute pgbench's
-sample data into three database nodes. The sample data will be created
-by "pgbench -i -s 3" (i.e. scale factor of 3). We will create a new
-database called "bench_parallel" for this section.</p>
-
-<p>In pgpool-II's source code, you can find the
-<code>dist_def_pgbench.sql</code> file in <code>sample</code>
-directoy. We will use this sample file here to create distribution
-rules for pgbench. Execute the following command in extracted
-pgpool-II source code directory.</p>
-
-<pre>$ psql -f sample/dist_def_pgbench.sql -p 5432 pgpool</pre>
-
-<p>Here is the explanation of <code>dist_def_pgbench.sql</code>.</p>
-
-<p>Inside <code>dist_def_pgbench.sql</code>, we are inserting one
-row into "dist_def" table. There is a distribution
-function for accounts table. 
-For the key-column, aid is defined for accounts respectively (which is the primary keys)</p>
-
-<pre>
-INSERT INTO pgpool_catalog.dist_def VALUES (
-    'bench_parallel',
-    'public',
-    'accounts',
-    'aid',
-    ARRAY['aid', 'bid', 'abalance', 'filler'],
-    ARRAY['integer', 'integer', 'integer', 'character(84)'],
-    'pgpool_catalog.dist_def_accounts'
-);
-</pre>
-
-<p>Now, we must define the distribution function for the accounts table. Note
-that you can use the same function from different tables. Also, you
-can define functions using languages other than SQL (e.g. PL/pgSQL,
-PL/Tcl, etc.).</p>
-
-<p>
-The accounts table when data is initialized specifying 3 scale factor,
-The value of the aid is 1 to 300000.
-The function is defined so that data is evenly distributed to three data base nodes. 
-</p>
-<p>
-An SQL function will be defined as the return of the number of the data base node. 
-</p>
-
-</p>
-<pre>CREATE OR REPLACE FUNCTION pgpool_catalog.dist_def_branches(anyelement)
-RETURNS integer AS $$
-    SELECT CASE WHEN $1 &gt; 0 AND $1 &lt;= 1 THEN 0
-        WHEN $1 &gt; 1 AND $1 &lt;= 2 THEN 1
-        ELSE 2
-    END;
-$$ LANGUAGE sql;
-</pre>
-
-<h3>3.4. <a name="replicate-def">Defining Replication Rules</a></h3>
-<p>
-The replication rule is the one that which table decides the replication whether to be done. 
-</p>
-
-<p>
-Here, it is made with pgbench With the branches table and  tellers  table are registered.
-
-As a result, the accounts table and the inquiry that uses the branches table 
-and the tellers table become possible. 
-</p>
-<pre>
-INSERT INTO pgpool_catalog.replicate_def VALUES (
-    'bench_parallel',
-    'public',
-    'branches',
-    ARRAY['bid', 'bbalance', 'filler'],
-    ARRAY['integer', 'integer', 'character(88)']
-);
-
-INSERT INTO pgpool_catalog.replicate_def VALUES (
-    'bench_parallel',
-    'public',
-    'tellers',
-    ARRAY['tid', 'bid', 'tbalance', 'filler'],
-    ARRAY['integer', 'integer', 'integer', 'character(84)']
-);
-</pre>
-<p>
-Replicate_def_pgbench.sql is prepared in sample directory.
-
-In the directory that progresses the source code to define a replicate rule by using this as follows The psql command is executed. 
-</p>
-<pre>
-$ psql -f sample/replicate_def_pgbench.sql -p 5432 pgpool
-</pre>
-
-<h3>3.5. <a name="parallel-check">Checking Parallel Query</a></h3>
-
-<p>To reflect the changes in <code>pgpool.conf</code>, pgpool-II must
-be restarted. Please refer to section "1.5 <a
-href="#start-shutdown">Starting/Stopping pgpool-II</a>".</p>
-
-<p>After configuring <code>pgpool.conf</code> and restarting
-pgpool-II, let's try and see if parallel query is working.</p>
-
-<p>First, we need to create a database to be distributed. We will name
-it "bench_parallel". This database needs to be created on all the
-nodes. Use the <code>createdb</code> commands through pgpool-II, and the
-databases will be created on all the nodes.</p>
-
-<pre>$ createdb -p 9999 bench_parallel</pre>
-
-<p>Then, we'll execute pgbench with <code>-i -s 3</code>
-options. <code>-i</code> option initializes the database with
-pre-defined tables and data. <code>-s</code> option specifies the
-scale factor for initialization.</p>
-
-<pre>$ pgbench -i -s 3 -p 9999 bench_parallel</pre>
-
-<p>The tables and data created are shown in "3.3. <a
-href="#dist-def">Defining Distribution Rules</a>".</p>
-
-<p>One way to check if the data have been distributed correctly is to
-execute a SELECT query via pgpool-II and directly on the backend, and
-compare two results. If everything is configured right,
-"bench_parallel" should be distributed as follows.</p>
-
-<table border="1" align ="center">
-<tr>
-<th >Table Name</th>
-<th >the number of lines</th>
-</tr>
-<tr>
-		<td>branches</td>
-		<td>3</td>
-</tr>
-<tr>
-		<td>tellers</td>
-		<td>30</td>
-</tr>
-<tr>
-		<td>accounts</td>
-		<td>300000</td>
-</tr>
-<tr>
-		<td>history</td>
-		<td>0</td>
-</tr>
-</table>
-
-<p>Let's use a simple shell script to check the above on all the nodes
-and via pgpool-II. The following script will display the minimum and
-maximum values in accounts table using port 5432, 5433, 5434, and
-9999.</p>
-
-<pre>$ for port in 5432 5433 5434 9999; do
-&gt;     echo $port
-&gt;     psql -c &quot;SELECT min(aid), max(aid) FROM accounts&quot; -p $port bench_parallel
-&gt; done
-</pre>
-
-<div class="copyright">
-<hr>
-<copyright>
-Copyright &copy; 2003 &ndash; 2011 pgpool Global Development Group
-</copyright>
-</div>
-</body>
-</html>
diff --git a/doc/tutorial-ja.html b/doc/tutorial-ja.html
deleted file mode 100644
index d71e21463..000000000
--- a/doc/tutorial-ja.html
+++ /dev/null
@@ -1,422 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
-<html>
-<head>
-<title>pgpool-II $B%A%e!<%H%j%"%k(B</title>
-<meta http-equiv="Content-Type" content="text/html; charset=iso-2022-jp" />
-<link href="pgpool.css" rel="stylesheet" type="text/css" />
-</head>
-<body>
-<h1>pgpool-II $B%A%e!<%H%j%"%k(B</h1>
-<p>pgpool-II $B$N%A%e!<%H%j%"%k$K$h$&$3$=!#(B
-$B$3$3$G$O!"(Bpgpool-II $B$N%$%s%9%H!<%k$+$i4pK\E*$J@_Dj!"%l%W%j%1!<%7%g%s$*$h$S%Q%i%l%k%/%(%j$N<B9T$r9T$&$^$G$N<j=g$K$D$$$F@bL@$7$^$9!#(B
-$B$^$?!"(BPostgreSQL $B$N4pK\E*$JA`:n$K4X$9$k@bL@$O9T$$$^$;$s$N$G!"I,MW$G$"$l$P(B PostgreSQL $B$N%I%-%e%a%s%H$r;2>H$7$F$/$@$5$$!#(B</p>
-<dl>
-<dt><em>$BL\<!(B</em></dt>
-<dt>1. <a href="#start">$B$5$";O$a$^$7$g$&(B</a></dt>
-<dd>1.1. <a href="#install">pgpool-II $B$N%$%s%9%H!<%k(B</a></dd>
-<dd>1.2. <a href="#config">$B@_Dj%U%!%$%k$N:n@.(B</a></dd>
-<dd>1.3. <a href="#pcp-config">PCP $B%3%^%s%I$N@_Dj(B</a></dd>
-<dd>1.4. <a href="#db-node">$B%G!<%?%Y!<%9%N!<%I$N=`Hw(B</a></dd>
-<dd>1.5. <a href="#start-shutdown">pgpool-II $B$N5/F0$HDd;_(B</a></dd>
-<dt>2. <a href="#replication">$B=i$a$F$N%l%W%j%1!<%7%g%s(B</a></dt>
-<dd>2.1. <a href="#replication-config">$B%l%W%j%1!<%7%g%s$N@_Dj(B</a></dd>
-<dd>2.2. <a href="#replication-check">$B%l%W%j%1!<%7%g%s$N3NG'(B</a></dd>
-<dt>3. <a href="#parallel">$B%Q%i%l%k%/%(%j$r;H$C$F$_$h$&(B</a></dt>
-<dd>3.1. <a href="#parallel-config">$B%Q%i%l%k%/%(%j$N@_Dj(B</a></dd>
-<dd>3.2. <a href="#system-db">$B%7%9%F%`%G!<%?%Y!<%9$N:n@.(B</a></dd>
-<dd>3.3. <a href="#dist-def">$BJ,;6%k!<%k$NDj5A(B</a></dd>
-<dd>3.4. <a href="#replicate-def">$BJ#@=%k!<%k$N3NG'(B</a></dd>
-<dd>3.5. <a href="#parallel-check">$B%Q%i%l%k%/%(%j$N3NG'(B</a></dd>
-</dl>
-<h2>1. <a name="start">$B$5$";O$a$^$7$g$&(B</a></h2>
-<p>$B$3$3$G$O!"%l%W%j%1!<%7%g%s$*$h$S%Q%i%l%k%/%(%j$N<B9T$r9T$&$?$a$N=`Hw$H$7$F!"(Bpgpool-II $B$N%$%s%9%H!<%k$d@_Dj!"%G!<%?%Y!<%9%N!<%I$N=`Hw$K$D$$$F@bL@$7$^$9!#(B</p>
-<h3>1.1. <a name="install">pgpool-II $B$N%$%s%9%H!<%k(B</a></h3>
-<p>pgpool-II $B$r%$%s%9%H!<%k$9$k$K$O%=!<%9%3!<%I$rE83+$7$?%G%#%l%/%H%j$G0J2<$N$h$&$K%3%^%s%I$r<B9T$7$^$9!#(B</p>
-<pre>$ ./configure
-$ make
-$ make install</pre>
-<p><code>configure</code> $B%9%/%j%W%H$G$O(B pgpool-II $B$r%$%s%9%H!<%k$9$k4D6-$K9g$o$;$?@_Dj$,9T$o$l$^$9!#(B
-$B$^$?!"(B<code>configure</code> $B%9%/%j%W%H$r<B9T$9$k:]$K%3%^%s%I%i%$%s0z?t$r;XDj$9$k$3$H$K$h$j!"(Bpgpool-II $B$N%$%s%9%H!<%k@h$NJQ99$J$I$r9T$&$3$H$,$G$-$^$9!#(B
-$B%3%^%s%I%i%$%s0z?t$r;XDj$7$J$1$l$P!"(Bpgpool-II $B$O(B <code>/usr/local</code> $B%G%#%l%/%H%j0J2<$K%$%s%9%H!<%k$5$l$^$9!#(B</p>
-<p><code>make</code> $B%3%^%s%I$r<B9T$9$k$H(B pgpool-II $B$N%=!<%9%3!<%I$,%3%s%Q%$%k$5$l!"(B<code>make install</code> $B%3%^%s%I$G$O<B:]$K%$%s%9%H!<%k$5$l$^$9!#(B
-$B$J$*!"(B<code>make install</code> $B%3%^%s%I$r<B9T$9$k:]$K(B pgpool-II $B$r%$%s%9%H!<%k$9$k%G%#%l%/%H%j$X$N=q$-9~$_8"8B$,I,MW$G$9!#(B</p>
-<p>$B$3$3$G$O!"(Bpgpool-II $B$r(B <code>/usr/local</code> $B%G%#%l%/%H%j0J2<$K%$%s%9%H!<%k$7$^$9!#(B</p>
-<p><em>$BCm0U(B</em>: pgpool-II $B$N%=!<%9%3!<%I$r%3%s%Q%$%k$9$k$K$O(B PostgreSQL 7.4 $B0J9_$G<BAu$5$l$?(B libpq $B%i%$%V%i%j(B (3.0 $B%W%m%H%3%k(B) $B$,I,MW$G$9!#(B
-<code>configure</code> $B%9%/%j%W%H$r<B9T$7$?:]$K0J2<$N%(%i!<%a%C%;!<%8$,I=<($5$l$?>l9g!"(Blibpq $B%i%$%V%i%j$,%$%s%9%H!<%k$5$l$F$$$J$$$+!"%$%s%9%H!<%k$5$l$F$$$F$b%W%m%H%3%k$N%P!<%8%g%s$,(B 3.0 $B$G$J$$2DG=@-$,$"$j$^$9!#(B</p>
-<pre>configure: error: libpq is not installed or libpq is old</pre>
-<p>$B$^$?!"%W%m%H%3%k$N%P!<%8%g%s$,(B 3.0 $B$N(B libpq $B%i%$%V%i%j$,%$%s%9%H!<%k$5$l$F$$$k$K$b78$o$i$:!">e5-$N%(%i!<%a%C%;!<%8$,I=<($5$l$k>l9g!"(B<code>configure</code> $B%9%/%j%W%H$r<B9T$7$?:]$K(B libpq $B%i%$%V%i%j$,G'<1$5$l$F$$$J$$2DG=@-$,$"$j$^$9!#(B</p>
-<p><code>configure</code> $B%9%/%j%W%H$OI8=`$G$O(B <code>/usr/local/pgsql</code> $B%G%#%l%/%H%j0J2<$+$i%X%C%@%U%!%$%k$d(B libpq $B%i%$%V%i%j$r8!:w$7$^$9!#(B
-PostgreSQL $B$N%$%s%9%H!<%k@h$,(B <code>/usr/local/pgsql</code> $B%G%#%l%/%H%j0J2<$G$J$1$l$P!"(B<code>configure</code> $B%9%/%j%W%H$r<B9T$9$k:]$K%3%^%s%I%i%$%s0z?t$H$7$F(B <code>--with-pgsql</code> $B$d(B <code>--with-pgsql-includedir</code>$B!"(B<code>--with-pgsql-libdir</code> $B%*%W%7%g%s$r;XDj$7$F$/$@$5$$!#(B</p>
-<h3>1.2. <a name="config">$B@_Dj%U%!%$%k$N:n@.(B</a></h3>
-<p>pgpool-II $B$K$D$$$F$N@_Dj$O(B <code>pgpool.conf</code> $B%U%!%$%k$K5-=R$7$^$9!#(B
-<code>pgpool.conf</code> $B%U%!%$%k$N=q<0$O(B 1 $B9T$4$H$K%Q%i%a!<%?L>$HCM$r(B = $B$G6h@Z$C$?$b$N$G$9!#(B
-pgpool-II $B$r%$%s%9%H!<%k$9$k$H%5%s%W%k$H$7$F(B <code>pgpool.conf.sample</code> $B%U%!%$%k$,:n@.$5$l$k$N$G!"$=$l$r(B <code>pgpool.conf</code> $B$H$$$&%U%!%$%kL>$K%3%T!<$7$F$+$iJT=8$9$k$H$$$$$G$7$g$&!#(B</p>
-<pre>$ cp /usr/local/etc/pgpool.conf.sample /usr/local/etc/pgpool.conf</pre>
-<p><code>pgpool.conf</code> $B%U%!%$%k$N=i4|@_Dj$G$O!"(Bpgpool-II $B$O(B pgpool-II $B$HF1$8%[%9%H$+$i$N%]!<%HHV9f(B 9999 $B$X$N@\B3$r<u$1IU$1$^$9!#(B
-pgpool-II $B$H0[$J$k%[%9%H$+$i$N@\B3$r<u$1IU$1$k>l9g$O(B <code>listen_addresses</code> $B%Q%i%a!<%?$K(B * $B$r@_Dj$7$^$9!#(B</p>
-<pre>listen_addresses = 'localhost'
-port = 9999</pre>
-<p>$B$3$3$G$O!"(B<code>pgpool.conf</code> $B%U%!%$%k$N=i4|@_Dj$r$=$N$^$^;HMQ$7$^$9!#(B</p>
-<h3>1.3. <a name="pcp-config">PCP $B%3%^%s%I$N@_Dj(B</a></h3>
-<p>pgpool-II $B$G$O(B PCP $B%3%^%s%I$H8F$P$l$k%$%s%?%U%'!<%9$rDL$7$F(B pgpool-II $B$NDd;_$d%G!<%?%Y!<%9%N!<%I$K4X$9$k>pJs$NI=<($r9T$$$^$9!#(B
-PCP $B%3%^%s%I$r;HMQ$9$k$K$O%f!<%6G'>Z$,I,MW$K$J$k$N$G!"%f!<%6L>$H%Q%9%o!<%I$r(B <code>pcp.conf</code> $B%U%!%$%k$K@_Dj$7$^$9!#(B
-<code>pcp.conf</code> $B%U%!%$%k$N=q<0$O0J2<$N$h$&$K(B 1 $B9T$4$H$K%f!<%6L>$H(B MD5 $B%O%C%7%e$KJQ49$5$l$?%Q%9%o!<%I$r(B : $B$G6h@Z$C$?$b$N$G$9!#(B</p>
-<pre>postgres:e8a48653851e28c69d0506508fb27fc5</pre>
-<p>pgpool-II $B$r%$%s%9%H!<%k$9$k$H%5%s%W%k$H$7$F(B <code>pcp.conf.sample</code> $B%U%!%$%k$,:n@.$5$l$k$N$G!"$=$l$r(B <code>pcp.conf</code> $B$H$$$&%U%!%$%kL>$K%3%T!<$7$F$+$iJT=8$9$k$H$$$$$G$7$g$&!#(B</p>
-<pre>$ cp /usr/local/etc/pcp.conf.sample /usr/local/etc/pcp.conf</pre>
-<p>$B$J$*!"%Q%9%o!<%I$r(B MD5 $B%O%C%7%e$KJQ49$9$k:]$K$O(B pgpool-II $B$H$H$b$K%$%s%9%H!<%k$5$l$k(B <code>pg_md5</code> $B%3%^%s%I$r;HMQ$7$^$9!#(B
-<code>pg_md5</code> $B%3%^%s%I$O!"%3%^%s%I%i%$%s0z?t$H$7$F%Q%9%o!<%I$r;XDj$9$k$H!"$=$l$r(B MD5 $B%O%C%7%e$KJQ49$7$?$b$N$rI=<($7$^$9!#(B</p>
-<p>$BNc$($P!"0J2<$N$h$&$K(B <code>pg_md5</code> $B%3%^%s%I$N%3%^%s%I%i%$%s0z?t$H$7$F(B postgres $B$r;XDj$7$F<B9T$9$k$H!"(Bpostgres $B$r(B MD5 $B%O%C%7%e$KJQ49$7$?$b$N$,I=<($5$l$^$9!#(B</p>
-<pre>$ /usr/bin/pg_md5 postgres
-e8a48653851e28c69d0506508fb27fc5</pre>
-<p>$B$^$?!"(BPCP $B%3%^%s%I$O%M%C%H%o!<%/$rDL$7$F<B9T$5$l$k$N$G!"(Bpgpool-II $B$,(B PCP $B%3%^%s%I$r<u$1IU$1$k%]!<%HHV9f$r(B <code>pgpool.conf</code> $B%U%!%$%k$N(B <code>pcp_port</code> $B%Q%i%a!<%?$K@_Dj$7$^$9!#(B</p>
-<p>$B$3$3$G$O!"(B<code>pcp_port</code> $B%Q%i%a!<%?$K:G=i$+$i@_Dj$5$l$F$$$k%]!<%HHV9f(B 9898 $B$r$=$N$^$^;HMQ$7$^$9!#(B</p>
-<pre>pcp_port = 9898</pre>
-<h3>1.4. <a name="db-node">$B%G!<%?%Y!<%9%N!<%I$N=`Hw(B</a></h3>
-<p>$B%G!<%?%Y!<%9%N!<%I$H$7$F;HMQ$9$k%G!<%?%Y!<%9%5!<%P$r=`Hw$7$^$9!#(B
-$B%G!<%?%Y!<%9%5!<%P$O!"(Bpgpool-II $B$HF1$8%[%9%H$G5/F0$7$F$b!"0[$J$k%[%9%H$G$"$C$F$b9=$$$^$;$s!#(B
-$B$b$A$m$s!"(Bpgpool-II $B$HF1$8%[%9%H$G5/F0$9$k>l9g$O0[$J$k%]!<%HHV9f$r3d$j9g$F!"0[$J$k%[%9%H$G5/F0$9$k>l9g$O(B pgpool-II $B$,5/F0$9$k%[%9%H$+$i%G!<%?%Y!<%9%5!<%P$K@\B3$G$-$k$h$&$K@_Dj$9$kI,MW$,$"$j$^$9!#(B
-pgpool-II $B$G$O%G!<%?%Y!<%9%5!<%P$4$H$K%l%W%j%1!<%7%g%s$r9T$&$N$G!"%A%e!<%H%j%"%k$N$?$a$N%G!<%?%Y!<%9%/%i%9%?$r:n@.$7$?$[$&$,$$$$$G$7$g$&!#(B</p>
-<p>$B$3$3$G$O!"(B3 $BBf$N%G!<%?%Y!<%9%5!<%P$r(B pgpool-II $B$HF1$8%[%9%H$N0[$J$k%]!<%HHV9f(B 5432$B!"(B5433$B!"(B5434 $B$G5/F0$7$^$9!#(B
-$B%G!<%?%Y!<%9%5!<%P$r%G!<%?%Y!<%9%N!<%I$H$7$F;HMQ$9$k$K$O!"(B<code>pgpool.conf</code> $B%U%!%$%k$K0J2<$N$h$&$K%Q%i%a!<%?$r@_Dj$7$^$9!#(B</p>
-<pre>backend_hostname0 = 'localhost'
-backend_port0 = 5432
-backend_weight0 = 1
-backend_hostname1 = 'localhost'
-backend_port1 = 5433
-backend_weight1 = 1
-backend_hostname2 = 'localhost'
-backend_port2 = 5434
-backend_weight2 = 1</pre>
-<p><code>backend_hostname</code>$B!"(B<code>backend_port</code>$B!"(B<code>backend_weight</code> $B%Q%i%a!<%?$K$O!"%G!<%?%Y!<%9%N!<%I$N%[%9%HL>!"%]!<%HHV9f!"Ii2YJ,;6$9$k:]$N=E$_IU$1$r@_Dj$7$^$9!#(B
-$B%Q%i%a!<%?L>$N8e$m$K$O(B 0$B!"(B1$B!"(B2$B!"(B&hellip; $B$H$$$&$h$&$KJ#?t$N%G!<%?%Y!<%9%N!<%I$r6hJL$9$k$?$a$N?t;z$r;XDj$7$^$9!#(B
-<code>backend_weight</code> $B%Q%i%a!<%?$O!"J#?t$N%G!<%?%Y!<%9%N!<%I$KLd$$9g$o$;$rIi2YJ,;6$9$k:]!"$I$N%G!<%?%Y!<%9%N!<%I$K$I$N$/$i$$$N3d9g$GLd$$9g$o$;$r9T$&$+$H$$$&$3$H$r@_Dj$9$k%Q%i%a!<%?$G$9!#(B
-$B$3$3$G$O!"(B3 $BBf$N%G!<%?%Y!<%9%N!<%I$N=E$_IU$1$,$9$Y$F(B 1 $B$K@_Dj$7$F$"$k$N$G!"Ld$$9g$o$;$O(B 1 $BBP(B 1 $BBP(B 1 $B$N3d$j9g$$$GIi2YJ,;6$5$l$k$3$H$K$J$j$^$9!#(B</p>
-<h3>1.5. <a name="start-shutdown">pgpool-II $B$N5/F0$HDd;_(B</a></h3>
-<p>pgpool-II $B$r5/F0$9$k$K$O0J2<$N$h$&$K(B <code>pgpool</code> $B%3%^%s%I$r<B9T$7$^$9!#(B</p>
-<pre>$ pgpool</pre>
-<p>
-$B$?$@$7!"$3$N$^$^$G$O(B <code>pgpool</code> $B%W%m%;%9$O@)8fC<Kv$r@Z$jN%(B
-$B$9$?$a!"%m%0$,=PNO$5$l$J$/$J$j$^$9(B($B%(%i!<$OI8=`%(%i!<$K=PNO$5$l$^$9(B)$B!#(B
-$B@)8fC<Kv$r@Z$jN%$5$J$$$G5/F0$9$k>l9g$O(B <code>-n</code> $B%*%W%7%g%s$r;XDj$7$^$9!#(B
-</p>
-
-<pre>
-$ pgpool -n &
-</pre>
-
-<p>
-$B%3%^%s%I$r<B9T$7$?C<Kv$K%m%0%a%C%;!<%8$,I=<($5$l$k$N$G!"0J2<$N$h$&$K%m%0%a%C%;!<%8$r%U%!%$%k$KJ]B8$9$k$h$&$K<B9T$9$k$3$H$r$*4+$a$7$^$9!#(B</p>
-<pre>$ pgpool -n -d &gt; /var/log/pgpool/pgpool.log 2&gt;&1 &</pre>
-<p><code>-d</code> $B%*%W%7%g%s$O%G%P%C%0%a%C%;!<%8$N=PNO$rM-8z$K$7$^$9!#(B</p>
-<p>
-$B>e5-$NNc$O%U%!%$%k$K%j%@%$%l%/%H$5$;$F$$$k$?$a!"%m%0$,DI2C$5$lB3$1$^$9!#(B
-$B%m%0$r%m!<%F!<%H$5$;$?$$>l9g$O!"%m!<%F!<%H5!G=$r;}$C$?%3%^%s%I$K%m%0$r(B
-$BEO$7$F$/$@$5$$!#(B
-
-$B$?$H$($P!"(BApache2$B$KIUB0$9$k(Brotatelogs$B$r;H$&$N$G$"$l$P!"(B
-
-<pre>
-$ pgpool -n 2>&1 | /usr/local/apache2/bin/rotatelogs \
-  -l -f /var/log/pgpool/pgpool.log.%A 86400 &
-</pre>
-
-$B$H$9$l$PKhF|LkCf$N(B0$B;~$K%m%0$,%m!<%F!<%H$5$l!"(Bpgpool.log.Thursday $B$N$h$&$JL>A0$N%m%0%U%!%$%k$,KhF|:n@.$5$l$^$9!#(B
-$B$?$@$7!"$9$G$KF1$8L>A0$N%U%!%$%k$,$"$k>l9g$K$O%m%0$,$=$N%U%!%$%k$KDI2C$5$l$F$7$^$&$N$G!"(Bcron$B$r;H$C$F8E$$%m%0%U%!%$%k$r>C5n$9$k@_Dj$rJ;$;$F9T$C$F$*$/J}$,NI$$$G$7$g$&!#(B
-$BNc$r<($7$^$9!#(B
-<pre>
-55 23 * * * /usr/bin/find /var/log/pgpool -type f -mtime +5 -exec /bin/rm -f '{}' \;
-</pre>
-</p>
-<p>
-<em>$BCm0U(B</em>: Linux$B%G%#%9%H%j%S%e!<%7%g%s$K$h$C$F$O!"(Brotatelogs $B$O(B /usr/sbin/rotatelogs2 $B$N$h$&$JL>A0$G%$%s%9%H!<%k$5$l$F$$$k$+$bCN$l$^$;$s!#(B
--f $B%*%W%7%g%s$O(B rotatelogs $B$,5/F0$5$l$?D>8e$KD>$A$K%m%0%U%!%$%k$r:n$k%*%W%7%g%s$G!"(Bapache2 2.2.9 $B0J9_$G$N$_M-8z$G$9!#(B
-</p>
-
-<p>
-<a href="http://www.cronolog.org/"><code>cronolog</code></a> $B$r;H$&>l9g$G$"$l$P!"0J2<$N$h$&$K%Q%$%W$G%m%0%a%C%;!<%8$rEO$7$F$/$@$5$$!#(B
-
-<pre>
-$ pgpool -n 2>&1 | /usr/sbin/cronolog \
-  --hardlink=/var/log/pgpool/pgpool.log \
-  '/var/log/pgpool/%Y-%m-%d-pgpool.log' &
-</pre>
-</p>
-
-<p>pgpool-II $B$rDd;_$9$k$K$O0J2<$N$h$&$K(B <code>pgpool</code> $B%3%^%s%I$r<B9T$7$^$9!#(B</p>
-<pre>$ pgpool stop</pre>
-<p>pgpool-II $B$rDd;_$9$k:]$K%/%i%$%"%s%H$,@\B3$7$F$$$k>l9g!"$=$N@\B3$,@ZCG$5$l$k$^$GBT$C$F$+$iDd;_$7$^$9!#(B
-$B%/%i%$%"%s%H$N@\B3$,@ZCG$5$l$k$^$GBT$?$:$KDd;_$9$k$K$O0J2<$N$h$&$K(B <code>pgpool</code> $B%3%^%s%I$r<B9T$7$^$9!#(B</p>
-<pre>$ pgpool -m fast stop</pre>
-<h2>2. <a name="replication">$B=i$a$F$N%l%W%j%1!<%7%g%s(B</a></h2>
-<p>$B%l%W%j%1!<%7%g%s$G$OJ#?t$N%G!<%?%Y!<%9%N!<%I$KF1$8%G!<%?$rJ#@=$7$F3JG<$7$^$9!#(B</p>
-<p>$B$3$3$G$O!"!V(B1. <a href="#start">$B$5$";O$a$^$7$g$&(B</a>$B!W$G=`Hw$7$?(B 3 $BBf$N%G!<%?%Y!<%9%N!<%I$r;HMQ$7!"(Bpgbench $B$,:n@.$9$k%G!<%?%Y!<%9$N%l%W%j%1!<%7%g%s$r9T$&$^$G$N<j=g$K$D$$$F@bL@$7$^$9!#(B</p>
-<h3>2.1. <a name="replication-config">$B%l%W%j%1!<%7%g%s$N@_Dj(B</a></h3>
-<p>$B%G!<%?%Y!<%9%N!<%I$N%l%W%j%1!<%7%g%s$rM-8z$K$9$k$K$O!"(B<code>pgpool.conf</code> $B%U%!%$%k$N(B <code>replication_mode</code> $B%Q%i%a!<%?$r(B true $B$K@_Dj$7$^$9!#(B</p>
-<pre>replication_mode = true</pre>
-<p>$B>e5-$N$h$&$K(B <code>replication_mode</code> $B%Q%i%a!<%?$r(B true $B$K@_Dj$9$k$3$H$K$h$j!"(Bpgpool-II $B$X$NLd$$9g$o$;$,$9$Y$F$N%G!<%?%Y!<%9%N!<%I$KBP$7$F<B9T$5$l!"F1$8%G!<%?$,J#@=$5$l$F3JG<$5$l$k$h$&$K$J$j$^$9!#(B
-<p>$B$5$i$K!"(B<code>load_balance_mode</code> $B%Q%i%a!<%?$r(B true $B$K@_Dj$9$k$3$H$K$h$j!"(Bpgpool-II $B$KBP$9$k(B SELECT $BJ8$rJ#?t$N%G!<%?%Y!<%9%N!<%I$KBP$7$F?6$jJ,$1!"Ii2YJ,;6$r9T$&$3$H$,$G$-$^$9!#(B</p>
-<pre>load_balance_mode = true</pre>
-<p>$B$3$3$G$O!"(B<code>replication_mode</code>$B!"(B<code>load_balance_mode</code> $B%Q%i%a!<%?$r(B true $B$K@_Dj$7$^$9!#(B</p>
-<h3>2.2. <a name="replication-check">$B%l%W%j%1!<%7%g%s$N3NG'(B</a></h3>
-<p>$B%l%W%j%1!<%7%g%s$N@_Dj$r(B pgpool-II $B$KH?1G$5$;$k$K$O(B pgpool-II $B$r:F5/F0$9$kI,MW$,$"$j$^$9!#(B
-pgpool-II $B$N:F5/F0$K$D$$$F$O!V(B1.5. <a href="#start-shutdown">pgpool-II $B$N5/F0$HDd;_(B</a>$B!W$r;2>H$7$F$/$@$5$$!#(B</p>
-<p>$B%l%W%j%1!<%7%g%s$rM-8z$K$7$F(B pgpool-II $B$r5/F0$G$-$?$i!"<B:]$K(B pgbench $B$r;HMQ$7$F%l%W%j%1!<%7%g%s$,9T$o$l$F$$$k$3$H$r3NG'$7$^$7$g$&!#(B</p>
-<p>$B$^$:!"(Bpgbench $B$,;HMQ$9$k%G!<%?%Y!<%9(B bench_replication $B$r:n@.$7$^$9!#(B
-<code>createdb</code> $B%3%^%s%I$r(B pgpool-II $B$KBP$7$F<B9T$9$k$H!"$9$Y$F$N%G!<%?%Y!<%9%N!<%I$KBP$7$F%G!<%?%Y!<%9(B bench_replication $B$,:n@.$5$l$^$9!#(B</p>
-<pre>$ createdb -p 9999 bench_replication</pre>
-<p>$B$=$7$F!"(B<code>pgbench</code> $B%3%^%s%I$K(B <code>-i</code> $B%*%W%7%g%s$r;XDj$7$F<B9T$9$k$3$H$K$h$j!"%G!<%?%Y!<%9(B bench_replication $B$KBP$7$F(B pgbench $B$G;HMQ$9$k%F!<%V%k$r:n@.$7!"%G!<%?$r=i4|2=$7$^$9!#(B</p>
-<pre>$ pgbench -i -p 9999 bench_replication</pre>
-<p><code>pgbench</code> $B%3%^%s%I$K(B <code>-i</code> $B%*%W%7%g%s$r;XDj$7$F<B9T$7$?:]$K:n@.$5$l$k%F!<%V%k$H$=$l$>$l$N%F!<%V%k$N9T?t$O0J2<$N$H$*$j$G$9!#(B
-$B$9$Y$F$N%G!<%?%Y!<%9%N!<%I$N%G!<%?%Y!<%9(B bench_replication $B$K0J2<$N9T?t$N%G!<%?$,3JG<$5$l$F$$$l$P!"@5>o$K%l%W%j%1!<%7%g%s$,9T$o$l$F$$$k$3$H$K$J$j$^$9!#(B</p>
-
-<center>
-<table border>
-<tr>
-<th>$B%F!<%V%kL>(B</th>
-<th>$B9T?t(B</th>
-</tr>
-<tr>
-<td>branches</td>
-<td>1</td>
-</tr>
-<tr>
-<td>tellers</td>
-<td>10</td>
-</tr>
-<tr>
-<td>accounts</td>
-<td>100000</td>
-</tr>
-<tr>
-<td>history</td>
-<td>0</td>
-</tr>
-</table>
-</center>
-<p>$BNc$($P!"0J2<$N$h$&$K%3%^%s%I$r<B9T$9$k$H!"$9$Y$F$N%G!<%?%Y!<%9%N!<%I(B ($B%]!<%HHV9f(B 5432$B!"(B5433$B!"(B5434) $B$N%G!<%?%Y!<%9(B bench_replication $B$K4^$^$l$k%F!<%V%k(B branches$B!"(Btellers$B!"(Baccounts$B!"(Bhistory $B$N9T?t$,I=<($5$l$^$9!#(B</p>
-<pre>$ for port in 5432 5433 5434; do
-&gt;     echo $port
-&gt;     for table_name in branches tellers accounts history; do
-&gt;         echo $table_name
-&gt;         psql -c &quot;SELECT count(*) FROM $table_name&quot; -p $port bench_replication
-&gt;     done
-&gt; done
-</pre>
-<h2>3. <a name="parallel">$B%Q%i%l%k%/%(%j$r;H$C$F$_$h$&(B</a></h2>
-<p>$B%Q%i%l%k%/%(%j$G$OJ#?t$N%G!<%?%Y!<%9%N!<%I$K0[$J$kHO0O$N%G!<%?$r3JG<$7$^$9!#$3$l$r%Q!<%F%#%7%g%K%s%0$H8F$S$^$9!#$^$?%Q!<%F%#%7%g%s%K%s%0$H6&$KJ#?t$N%G!<%?%Y!<%9%N!<%I$KF1$8%G!<%?$rJ#@=$9$k$3$H$b$G$-$^$9!#$D$^$j%Q!<%F%#%7%g%K%s%0$7$F$$$k%F!<%V%k$H%l%W%j%1!<%7%g%s$7$F$$$k%F!<%V%k$r6&B8$5$;$k$3$H$,$G$-$^$9!#(B</p>
-<p>$B%Q%i%l%k%/%(%j$r;HMQ$9$k$K$O%7%9%F%`%G!<%?%Y!<%9$H8F$P$l$kFCJL$J%G!<%?%Y!<%9$,I,MW$G$9!#(B</p>
-<p>$B%7%9%F%`%G!<%?%Y!<%9$G$O!"$I$N%G!<%?%Y!<%9%N!<%I$KBP$7$F$I$N%G!<%?$r3JG<$9$k$+$H$$$&J,;6%k!<%k$r3JG<$7$F$*$j!"$=$l$K$h$C$F%G!<%?$rJ#?t$N%G!<%?%Y!<%9%N!<%I$KJ,;6$5$;$^$9!#(B
-$B$^$?!"%7%9%F%`%G!<%?%Y!<%9$O!"(Bdblink $B$r;HMQ$9$k$3$H$K$h$C$FJ#?t$N%G!<%?%Y!<%9%N!<%I$KLd$$9g$o$;$r?6$jJ,$1!"$=$l$>$l$N%G!<%?%Y!<%9%N!<%I$G<B9T$5$l$?7k2L$r(B 1 $B$D$K$^$H$a$^$9!#(B</p>
-<p>$B$3$3$G$O!"!V(B1. <a href="#start">$B$5$";O$a$^$7$g$&(B</a>$B!W$G=`Hw$7$?(B 3 $BBf$N%G!<%?%Y!<%9%N!<%I$r;HMQ$7!"(Bpgbench $B$,:n@.$9$k%G!<%?%Y!<%9$KBP$7$F%Q%i%l%k%/%(%j$r<B9T$9$k$^$G$N<j=g$K$D$$$F@bL@$7$^$9!#(B</p>
-<h3>3.1. <a name="parallel-config">$B%Q%i%l%k%/%(%j$N@_Dj(B</a></h3>
-<p>$B%Q%i%l%k%/%(%j$rM-8z$K$9$k$K$O(B <code>pgpool.conf</code> $B%U%!%$%k$N(B <code>parallel_mode</code> $B%Q%i%a!<%?$r(B true $B$K@_Dj$7$^$9!#(B</p>
-<pre>parallel_mode = true</pre>
-<p>$B$?$@$7!">e5-$N$h$&$K(B <code>parallel_mode</code> $B%Q%i%a!<%?$r(B true $B$K@_Dj$7$?$@$1$G$O!"J#?t$N%G!<%?%Y!<%9%N!<%I$KBP$7$F%G!<%?$rJ,;6$G$-$^$;$s!#(B
-$B$5$i$K!"%7%9%F%`%G!<%?%Y!<%9$r:n@.$7!"J,;6%k!<%k$NDj5A$HEPO?$r9T$&I,MW$,$"$j$^$9!#(B</p>
-<p>$B$^$?!"(Bdblink $B$G$O%7%9%F%`%G!<%?%Y!<%9$+$i(B pgpool-II $B$X$N(B TCP/IP $B@\B3$,9T$o$l$k$?$a!"(B<code>listen_addresses</code> $B%Q%i%a!<%?$rE,@Z$K@_Dj$9$kI,MW$,$"$j$^$9!#(B</p>
-<pre>listen_addresses = '*'</pre>
-<p><em>$BCm0U(B</em>: $B%Q%i%l%k%/%(%j$H%l%W%j%1!<%7%g%s$rF1;~$KM-8z$K$9$k$3$H$,$G$-$^$9$,!"%Q!<%F%#%7%g%K%s%0$7$F$$$k%F!<%V%k$KBP$7$F$O!"%l%W%j%1!<%7%g%s$5$l$^$;$s!#(B
-$B$^$?!"%Q%i%l%k%/%(%j$H%l%W%j%1!<%7%g%s$G$O%G!<%?%Y!<%9$K3JG<$5$l$k%G!<%?$N9=@.$,0[$J$k$?$a!"!V(B2. <a href="#replication">$B=i$a$F$N%l%W%j%1!<%7%g%s(B</a>$B!W$G:n@.$7$?%G!<%?%Y!<%9(B bench_replication $B$r$=$N$^$^;HMQ$9$k$3$H$O$G$-$^$;$s!#(B</p>
-<pre>replication_mode = true
-load_balance_mode = false</pre>
-<p>$B$^$?$O!"(B</p>
-<pre>replication_mode = false
-load_balance_mode = true</pre>
-<p>$B$3$3$G$O!"(B<code>parallel_mode</code> $B%Q%i%a!<%?$r(B true $B$K!"(B<code>listen_addresses</code> $B%Q%i%a!<%?$r(B * $B$K!"(B<code>replication_mode</code>$B!"(B<code>load_balance_mode</code> $B%Q%i%a!<%?$r(B false $B$K@_Dj$7$^$9!#(B</p>
-<h3>3.2. <a name="system-db">$B%7%9%F%`%G!<%?%Y!<%9$N:n@.(B</a></h3>
-<p>$B%7%9%F%`%G!<%?%Y!<%9$HDL>o$N%G!<%?%Y!<%9$K0c$$$O$"$j$^$;$s!#(B
-$B$?$@$7!"%7%9%F%`%G!<%?%Y!<%9$K$O!"(Bdblink $B$N4X?t$,Dj5A$5$l$F$*$j!"J,;6%k!<%k$r3JG<$9$k%F!<%V%k(B dist_def $B$,Dj5A$5$l$F$$$kI,MW$,$"$j$^$9!#(B
-$B$^$?!"%G!<%?%Y!<%9%N!<%I$N(B 1 $BBf$K%7%9%F%`%G!<%?%Y!<%9$r:n@.$9$k$3$H$b$G$-$^$9$7!"(Bpgpool-II$B$r%+%9%1!<%I@\B3$9$k$3$H$GIi2YJ,;6$9$k$3$H$b$G$-$^$9!#(B</p>
-<p>$B$3$3$G$O!"0J2<$N(B <code>pgpool.conf</code> $B%U%!%$%k$N=i4|@_Dj$K=>$C$F%7%9%F%`%G!<%?%Y!<%9$r:n@.$7$^$9!#(B</p>
-<pre>system_db_hostname = 'localhost'
-system_db_port = 5432
-system_db_dbname = 'pgpool'
-system_db_schema = 'pgpool_catalog'
-system_db_user = 'pgpool'
-system_db_password = ''</pre>
-<p><code>pgpool.conf</code> $B%U%!%$%k$N=i4|@_Dj$G$O!"%7%9%F%`%G!<%?%Y!<%9$O(B pgpool-II $B$HF1$8%[%9%H$N%]!<%HHV9f(B 5432 $B$G5/F0$9$k%G!<%?%Y!<%9%5!<%P!"$D$^$j!"(B1 $BBfL\$N%G!<%?%Y!<%9%N!<%I$K:n@.$9$k$3$H$K$J$j$^$9!#(B
-$B$^$?!"%7%9%F%`%G!<%?%Y!<%9$N%G!<%?%Y!<%9L>$O(B pgpool $B$K!"%7%9%F%`%G!<%?%Y!<%9$K@\B3$9$k%f!<%6L>$b(B pgpool $B$K@_Dj$5$l$F$$$k$N$G!"(Bpgpool $B$H$$$&%f!<%6$r:n@.$7$F$+$i%f!<%6(B pgpool $B$r=jM-<T$H$7$F%G!<%?%Y!<%9(B pgpool $B$r:n@.$7$^$9!#(B
-</p>
-<pre>$ createuser -p 5432 pgpool
-$ createdb -p 5432 -O pgpool pgpool</pre>
-<h4><p>3.2.1. dblink $B$N%$%s%9%H!<%k(B</p></h4>
-<p>$B%7%9%F%`%G!<%?%Y!<%9$H$7$F%G!<%?%Y!<%9(B pgpool $B$,:n@.$G$-$?$i!"(Bdblink $B$r%$%s%9%H!<%k$7$^$9!#(B
-dblink $B$O(B PostgreSQL $B$N%=!<%9%3!<%I$N(B <code>contrib</code> $B%G%#%l%/%H%j$K4^$^$l$k%D!<%k$N(B 1 $B$D$G$9!#(B</p>
-<p>dblink $B$r%$%s%9%H!<%k$9$k$K$O(B PostgreSQL $B$N%=!<%9%3!<%I$rE83+$7$?%G%#%l%/%H%j$G0J2<$N$h$&$K%3%^%s%I$r<B9T$7$^$9!#(B</p>
-<pre>$ USE_PGXS=1 make -C contrib/dblink
-$ USE_PGXS=1 make -C contrib/dblink install</pre>
-<p>$B%G!<%?%Y!<%9(B pgpool $B$KBP$7$F(B dblink $B$N4X?t$rDj5A$7$^$9!#(B
-PostgreSQL  $B$N%$%s%9%H!<%k@h$,(B <code>/usr/local/pgsql</code> $B%G%#%l%/%H%j0J2<$G$"$l$P!"(B<code>/usr/local/pgsql/share/contrib</code> $B%G%#%l%/%H%j$K(B dblink $B$N4X?t$rDj5A$9$k$?$a$N(B <code>dblink.sql</code> $B%U%!%$%k$,B8:_$7$^$9!#(B
-$B$=$l$r;HMQ$7$F0J2<$N$h$&$K(B <code>psql</code> $B%3%^%s%I$r<B9T$7$^$9!#(B</p>
-<pre>$ psql -f /usr/local/pgsql/share/contrib/dblink.sql -p 5432 pgpool</pre>
-<h4><p>3.2.2. $B%F!<%V%k(B dist_def $B$NDj5A(B</p></h4>
-<p>$BJ,;6%k!<%k$r3JG<$9$k%F!<%V%k(B dist_def $B$r%7%9%F%`%G!<%?%Y!<%9(B pgpool $B$KDj5A$7$^$9!#(B
-pgpool-II $B$r%$%s%9%H!<%k$9$k$H%F!<%V%k(B dist_def $B$r4^$a$F%7%9%F%`%G!<%?%Y!<%9$r:n@.$9$k$?$a$N(B <code>system_db.sql</code> $B%U%!%$%k$,:n@.$5$l$k$N$G!"$=$l$r;HMQ$7$F0J2<$N$h$&$K(B <code>psql</code> $B%3%^%s%I$r<B9T$7$^$9!#(B</p>
-<pre>$ psql -f /usr/local/share/system_db.sql -p 5432 -U pgpool pgpool</pre>
-<p><code>system_db.sql</code> $B%U%!%$%k$G$O!"%9%-!<%^(B pgpool_catalog $B$K%F!<%V%k(B dist_def $B$J$I$rDj5A$7$F$$$^$9!#(B
-$B=>$C$F!"(B<code>pgpool.conf</code> $B%U%!%$%k$N(B <code>system_db_schema</code> $B%Q%i%a!<%?$G(B pgpool_catalog $B$G$J$$%9%-!<%^L>$r;XDj$7$F$$$k>l9g!"(B<code>system_db.sql</code> $B%U%!%$%k$rJT=8$7$F%9%-!<%^L>$rJQ99$9$kI,MW$,$"$j$^$9!#(B</p>
-<p>$B%F!<%V%k(B dist_def $B$O0J2<$N$h$&$KDj5A$5$l$F$*$j!"%F!<%V%kL>$rJQ99$9$k$3$H$O$G$-$^$;$s!#(B</p>
-<pre>CREATE TABLE pgpool_catalog.dist_def (
-    dbname text, -- $B%G!<%?%Y!<%9L>(B
-    schema_name text, -- $B%9%-!<%^L>(B
-    table_name text, -- $B%F!<%V%kL>(B
-    col_name text NOT NULL CHECK (col_name = ANY (col_list)), -- $BJ,;6%-!<NsL>(B
-    col_list text[] NOT NULL, -- $B%F!<%V%k$NNsL>(B
-    type_list text[] NOT NULL, -- $B%F!<%V%k$N%G!<%?7?L>(B
-    dist_def_func text NOT NULL, -- $BJ,;6%k!<%k4X?t(B
-    PRIMARY KEY (dbname, schema_name, table_name)
-);</pre>
-<p>$B%F!<%V%k(B dist_def $B$K3JG<$5$l$k%G!<%?$OBg$-$/J,$1$F0J2<$N(B 2 $B$D$G$9!#(B</p>
-<ul>
-<li>$BJ,;6%k!<%k(B (col_name$B!"(Bdist_def_func)</li>
-<li>$B%F!<%V%k$N%a%?>pJs(B (dbname$B!"(Bschema_name$B!"(Btable_name$B!"(Bcol_list$B!"(Btype_list)</li>
-</ul>
-<p>$B$^$:!"J,;6%k!<%k$O$I$N%G!<%?$r$I$N%G!<%?%Y!<%9%N!<%I$K3JG<$9$k$+$H$$$&$3$H$r7hDj$9$k$?$a$N%G!<%?$G$9!#(B
-col_name $BNs$K$O%F!<%V%k$N$I$NNs$NCM$K$h$C$F3JG<$9$k%G!<%?%Y!<%9%N!<%I$r7hDj$9$k$+$H$$$&$3$H$r;XDj$7$^$9!#(B
-dist_def_func $BNs$K$O!"(Bcol_name $BNs$K;XDj$5$l$?Ns$NCM$r0z?t$H$7$F<u$1<h$j!"%G!<%?%Y!<%9%N!<%I$NHV9f$rJV$94X?t$r;XDj$7$^$9!#(B</p>
-<p>$B%F!<%V%k$N%a%?>pJs$OLd$$9g$o$;$N=q$-49$($r9T$&:]$K;HMQ$5$l$k%G!<%?$G$9!#(B
-$B%Q%i%l%k%/%(%j$G$O!"Ld$$9g$o$;$rJ#?t$N%G!<%?%Y!<%9%N!<%I$K?6$jJ,$1!"$=$l$>$l$N%G!<%?%Y!<%9%N!<%I$G<B9T$5$l$?7k2L$r(B 1 $B$D$K$^$H$a$k$?$a!"Ld$$9g$o$;$N=q$-49$($r9T$$$^$9!#(B</p>
-
-
-<h4><p>3.2.3. $B%F!<%V%k(B replicate_def $B$NDj5A(B</p></h4>
-<p>
-$B0l$D$N(BSQL$BJ8$K%F!<%V%k$N7k9gEy$G(Bdist_def$B$KEPO?$7$?%F!<%V%k$H6&$K%l%W%j%1!<%7%g%s$r9T$&%F!<%V%k$r;XDj$9$k>l9g$K$O!"(B
-$B%l%W%j%1!<%7%g%s$r9T$&%F!<%V%k$N>pJs(B($BJ#@=%k!<%k(B)$B$r$"$i$+$8$a!"(Breplicate_def $B$H$$$&%F!<%V%k$KEPO?$7$F$*$-$^$9!#(B
-$B%F!<%V%k(B dist_def $B$NDj5A$N:]$K!"(Bsystem_db.sql$B%U%!%$%k$+$i:n@.$7$?>l9g$K$O!"$9$G$K(Breplicate_def$B%F!<%V%k$,:n@.$5$l$F$$$^$9!#(B
-replicate_def$B%F!<%V%k$O0J2<$N$h$&$KDj5A$5$l$F$$$^$9!#(B
-<pre>
-CREATE TABLE pgpool_catalog.replicate_def(
-  dbname TEXT, -- $B%G!<%?%Y!<%9L>(B
-  schema_name TEXT, -- $B%9%-!<%^L>(B
-  table_name TEXT, -- $B%F!<%V%kL>(B
-  col_list TEXT[] NOT NULL, -- $B%F!<%V%k$NNsL>(B
-  type_list TEXT[] NOT NULL, -- $B%F!<%V%k$N%G!<%?7?L>(B
-  PRIMARY KEY (dbname,schema_name,table_name)
-);
-</pre>
-</p>
-<p>
-$B%F!<%V%k(B replicate_def $B$K3JG<$5$l$k%G!<%?$O%F!<%V%k$N%a%?>pJs(B(dbname$B!"(Bschema_name$B!"(Btable_name$B!"(Bcol_list$B!"(Btype_list)$B$H$J$j$^$9!#(B
-</p>
-
-<p>
-pgpool-ll $B$O!"%/%(%j$K;H$o$l$F$$$k!"$9$Y$F$N%F!<%V%k!"%+%i%`!"7?>pJs$r(Bdist_def$B$^$?$O!"(Breplicate_def$B%F!<%V%k$KEPO?$7$F$$$k>pJs(B
-$B$rMQ$$$F!"%/%(%j$N2r@O$H%/%(%j$N=q$-49$($r9T$$$^$9!#$=$N$?$a(B replicate_def$B%F!<%V%k$K@5$7$$>pJs$rEPO?$7$F$*$+$J$$$H!"@5$7$$<B9T(B
-$B7k2L$,F@$i$l$J$$2DG=@-$,$"$j$^$9!#(B
-</p>
-
-<h3>3.3. <a name="dist-def">$BJ,;6%k!<%k$NDj5A(B</a></h3>
-<p>$BJ,;6%k!<%k$O$I$N%G!<%?$r$I$N%G!<%?%Y!<%9%N!<%I$K3JG<$9$k$+$H$$$&$3$H$r7hDj$9$k$b$N$G$9!#(B</p>
-<p>$B$3$3$G$O!"%9%1!<%k%U%!%/%?!<(B 3 $B$r;XDj$7$F%G!<%?$r=i4|2=$7$?(B pgbench $B$N%F!<%V%k$r(B 3 $BBf$N%G!<%?%Y!<%9%N!<%I$K?6$jJ,$1$k$?$a$NJ,;6%k!<%k$rDj5A$7$^$9!#(B
-$B$J$*!"%G!<%?%Y!<%9$O!V(B2. <a href="#replication">$B=i$a$F$N%l%W%j%1!<%7%g%s(B</a>$B!W$G;HMQ$7$?%G!<%?%Y!<%9(B bench_replication $B$H$OJL$K%G!<%?%Y!<%9(B bench_parallel $B$r:n@.$9$k$3$H$K$7$^$9!#(B</p>
-<p>$B$J$*!"%=!<%9%3!<%I$N(B <code>sample</code> $B%G%#%l%/%H%j$K$O0J2<$N@bL@$G;HMQ$9$kJ,;6%k!<%k$,Dj5A$5$l$?%U%!%$%k(B <code>dist_def_pgbench.sql</code> $B$,=`Hw$5$l$F$$$^$9!#(B
-$B$3$l$r;HMQ$7$FJ,;6%k!<%k$rDj5A$9$k$K$O%=!<%9%3!<%I$rE83+$7$?%G%#%l%/%H%j$G0J2<$N$h$&$K(B psql $B%3%^%s%I$r<B9T$7$^$9!#(B</p>
-<pre>$ psql -f sample/dist_def_pgbench.sql -p 5432 pgpool</pre>
-<p>$B$^$:!"J,;6%k!<%k$H%F!<%V%k$N%a%?>pJs$r%7%9%F%`%G!<%?%Y!<%9(B pgpool $B$N%F!<%V%k(B dist_def $B$K3JG<$7$^$9!#(B
-$B$3$3$G$O(Baccounts$B%F!<%V%k$r3F%G!<%?%Y!<%9%N!<%I$KBP$7$F%G!<%?J,3d$r9T$$$^$9!#(B
-$BJ,;6%-!<NsL>$O!"(Baccounts $B$K$D$$$F$O%W%i%$%^%j%-!<@)Ls$,;XDj$5$l$?Ns(B aid $B$K;XDj$7$^$9!#(B</p>
-<pre>
-INSERT INTO pgpool_catalog.dist_def VALUES (
-    'bench_parallel',
-    'public',
-    'accounts',
-    'aid',
-    ARRAY['aid', 'bid', 'abalance', 'filler'],
-    ARRAY['integer', 'integer', 'integer', 'character(84)'],
-    'pgpool_catalog.dist_def_accounts'
-);
-</pre>
-<p>$B<!$K!"J,;6%k!<%k4X?t$r%F!<%V%k$4$H$K%7%9%F%`%G!<%?%Y!<%9(B pgpool $B$KDj5A$7$^$9!#(B
-$BJ,;6%k!<%k4X?t$O!"I,$:$7$b%F!<%V%k$4$H$K:n@.$9$kI,MW$O$J$/!"FbIt4X?t$r;HMQ$9$k$3$H$b$G$-$^$9!#(B
-$B$^$?!"J,;6%k!<%k4X?t$O(B SQL $B$G$J$/$H$b(B PL/pgSQL $B$d(B PL/Tcl $B$G:n@.$7$F$b9=$$$^$;$s!#(B</p>
-<p>$B%9%1!<%k%U%!%/%?!<(B 3 $B$r;XDj$7$F%G!<%?$r=i4|2=$7$?>l9g!"(Baccounts $B%F!<%V%k$N(B aid $BNs$NCM$O(B 1 $B$+$i(B 300000 $B$^$G$K$J$k$N$G!"$3$l$i$NCM$r$b$H$K(B 3 $BBf$N%G!<%?%Y!<%9%N!<%I$KBP$7$F%G!<%?$,6QEy$KJ,;6$5$l$k$h$&$K4X?t$rDj5A$7$^$9!#(B</p>
-<p>$B$3$3$G$O!"0z?t$H$7$F<u$1<h$C$?CM$+$i(B WHEN $B<0$K$h$C$F(B 0 $B$+$i(B 2 $B$^$G$N%G!<%?%Y!<%9%N!<%I$NHV9f$rJV$9C1=c$J(B SQL $B4X?t$rDj5A$9$k$3$H$K$7$^$9!#(B</p>
-<pre>
-CREATE OR REPLACE FUNCTION pgpool_catalog.dist_def_accounts(anyelement)
-RETURNS integer AS $$
-    SELECT CASE WHEN $1 &gt; 0 AND $1 &lt;= 100000 THEN 0
-        WHEN $1 &gt; 100000 AND $1 &lt;= 200000 THEN 1
-        ELSE 2
-    END;
-$$ LANGUAGE sql;
-</pre>
-
-<h3>3.4 <a name="replicate-def">$BJ#@=%k!<%k$NDj5A(B</a></h3>
-<p>$BJ#@=%k!<%k$O$I$N%F!<%V%k$,%l%W%j%1!<%7%g%s$5$l$F$$$k$+$I$&$+$r7hDj$9$k$b$N$G$9!#(B</p>
-<p>$B$3$3$G$O!"(Bpgbench$B$G:n@.$5$l$k!!(Bbranches $B%F!<%V%k$H(B tellers $B$rEPO?$7$F$*$-$^$9!#$3$l$K$h$j!"(Baccounts$B%F!<%V%k!"(Bbranches$B%F!<%V%k$H(Btellers$B%F!<%V%k$r(B
-$B;H$C$?Ld$$9g$o$;$,2DG=$H$J$j$^$9!#(B
-<pre>
-INSERT INTO pgpool_catalog.replicate_def VALUES (
-    'bench_parallel',
-    'public',
-    'branches',
-    ARRAY['bid', 'bbalance', 'filler'],
-    ARRAY['integer', 'integer', 'character(88)']
-);
-
-INSERT INTO pgpool_catalog.replicate_def VALUES (
-    'bench_parallel',
-    'public',
-    'tellers',
-    ARRAY['tid', 'bid', 'tbalance', 'filler'],
-    ARRAY['integer', 'integer', 'integer', 'character(84)']
-);
-</pre>
-<p>$B$J$*!"%=!<%9%3!<%I$N(B <code>sample</code> $B%G%#%l%/%H%j$K$O>e5-$N@bL@$G;HMQ$9$kJ#@=%k!<%k$,Dj5A$5$l$?%U%!%$%k(B <code>replicate_def_pgbench.sql</code> $B$,=`Hw$5$l$F$$$^$9!#(B
-$B$3$l$r;HMQ$7$FJ,;6%k!<%k$rDj5A$9$k$K$O%=!<%9%3!<%I$rE83+$7$?%G%#%l%/%H%j$G0J2<$N$h$&$K(B psql $B%3%^%s%I$r<B9T$7$^$9!#(B</p>
-<pre>
-$ psql -f sample/replicate_def_pgbench.sql -p 5432 pgpool
-</pre>
-
-
-<h3>3.5. <a name="parallel-check">$B%Q%i%l%k%/%(%j$N3NG'(B</a></h3>
-<p>$B%Q%i%l%k%/%(%j$N@_Dj$r(B pgpool-II $B$KH?1G$5$;$k$K$O(B pgpool-II $B$r:F5/F0$9$kI,MW$,$"$j$^$9!#$J$*!"%F!<%V%k(B dist_def$B!"(Breplicate_def $B$r99?7$7$?>l9g$b(B pgpool-II $B$N:F5/F0$,I,MW$G$9!#(B
-pgpool-II $B$N:F5/F0$K$D$$$F$O!V(B1.5. <a href="#start-shutdown">pgpool-II $B$N5/F0$HDd;_(B</a>$B!W$r;2>H$7$F$/$@$5$$!#(B</p>
-<p>$B%Q%i%l%k%/%(%j$rM-8z$K$7$F(B pgpool-II $B$r5/F0$G$-$?$i!"<B:]$K(B pgbench $B$r;HMQ$7$F%Q%i%l%k%/%(%j$,<B9T$5$l$k$3$H$r3NG'$7$^$7$g$&!#(B</p>
-<p>$B$^$:!"(Bpgbench $B$,;HMQ$9$k%G!<%?%Y!<%9(B bench_parallel $B$r:n@.$7$^$9!#(B
-<code>createdb</code> $B%3%^%s%I$r(B pgpool-II $B$KBP$7$F<B9T$9$k$H!"$9$Y$F$N%G!<%?%Y!<%9%N!<%I$KBP$7$F%G!<%?%Y!<%9(B bench_parallel $B$,:n@.$5$l$^$9!#(B</p>
-<pre>$ createdb -p 9999 bench_parallel</pre>
-<p>$B$=$7$F!"0J2<$N$h$&$K%9%1!<%k%U%!%/%?!<(B 3 $B$r;XDj$7$F(B pgbench $B$G;HMQ$9$k%F!<%V%k$r:n@.$7!"%G!<%?$r=i4|2=$7$^$9!#(B</p>
-<pre>$ pgbench -i -p 9999 -s 3 bench_parallel</pre>
-<p>$B%9%1!<%k%U%!%/%?!<(B 3 $B$r;XDj$7$F%G!<%?$r=i4|2=$7$?(B pgbench $B$N%F!<%V%k$H$=$l$>$l$N9T?t$O0J2<$N$H$*$j$G$9!#(B
-$B%G!<%?$r=i4|2=$9$k$3$H$K$h$C$F3JG<$5$l$k%G!<%?$O!"%F!<%V%k(B dist_def $B$KEPO?$5$l$F$$$k%F!<%V%k$KBP$7$F$OJ,;6%k!<%k$K=>$C$F(B 3 $BBf$N%G!<%?%Y!<%9%N!<%I$KJ,;6$5$l$^$9!#(B</p>
-<center>
-<table border="1">
-<tr>
-<th>$B%F!<%V%kL>(B</th>
-<th>$B9T?t(B</th>
-</tr>
-<tr>
-<td>branches</td>
-<td>3</td>
-</tr>
-<tr>
-<td>tellers</td>
-<td>30</td>
-</tr>
-<tr>
-<td>accounts</td>
-<td>300000</td>
-</tr>
-<tr>
-<td>history</td>
-<td>0</td>
-</tr>
-</table>
-</center>
-<p>$B%G!<%?$,(B 3 $BBf$N%G!<%?%Y!<%9%N!<%I$KJ,;6$5$l$F$$$k$3$H$O!"(Bpgpool-II $B$KBP$7$FLd$$9g$o$;$r<B9T$7$?7k2L$H%G!<%?%Y!<%9%N!<%I$KD>@\Ld$$9g$o$;$r<B9T$7$?7k2L$rHf3S$9$l$P3NG'$G$-$^$9!#(B
-$BNc$($P!"0J2<$N$h$&$K%3%^%s%I$r<B9T$9$k$H!"$9$Y$F$N%G!<%?%Y!<%9%N!<%I(B ($B%]!<%HHV9f(B 5432$B!"(B5433$B!"(B5434$B!"(B9999) $B$N%G!<%?%Y!<%9(B bench_parallel $B$N%F!<%V%k(B accounts $B$N:G>.CM!":GBgCM$,I=<($5$l$^$9!#(B</p>
-<pre>$ for port in 5432 5433 5434 9999; do
-&gt;     echo $port
-&gt;     psql -c &quot;SELECT min(aid), max(aid) FROM accounts&quot; -p $port bench_parallel
-&gt; done
-</pre>
-<div class="copyright">
-<hr>
-<copyright>
-Copyright &copy; 2003 &ndash; 2013 pgpool Global Development Group
-</copyright>
-</div>
-</body>
-</html>
diff --git a/doc/tutorial-memqcache-en.html b/doc/tutorial-memqcache-en.html
deleted file mode 100644
index 93c757419..000000000
--- a/doc/tutorial-memqcache-en.html
+++ /dev/null
@@ -1,325 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
-<html><head>
-<title>pgpool-II Tutorial [ On Memory Query Cache ]</title>
-<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
-<link href="pgpool.css" rel="stylesheet" type="text/css">
-</head>
-<body bgcolor="#ffffff">
-
-
-<div id="top" class="header_text">pgpool-II Tutrial [ On Memory Query Cache ]</div>
-
-<div id="menu">
-    <div id="navcontainer">
-      <ul id="navlist">
-      <li><a href="#thisis">About this document</a></li>
-      <li><a href="#basic">On memory query cache</a>
-          <ul>
-          <li><a href="#memqcache_config">Config pgpool.conf</a></li>
-          <li><a href="#basic_start">Start pgpool</a></li>
-          <li><a href="#basic_try">Try query cache</a></li>
-          </ul>
-      </li>
-      <li><a href="start#more">More</a>
-          <ul>
-          <li><a href="#invalidation">Auto invalidation</a></li>
-          <li><a href="#white_and_black_list">White list and black list</a></li>
-          <li><a href="#cache_or_not">Other</a></li>
-          </ul>
-      </li>
-      </ul>
-    </div>
-
-    <div class="header_small" align="center">
-    [<a href="tutrial-memqcache-ja.html">Japanese page</a>]
-    </div>
-</div>
-
-<div id="manual">
-
-<!-- ================================================================================ -->
-
-<h1 id="thisis">About this document</h1>
-
-<p>In this Tutrial, I explain a simple way to try "On memory query cache" with shared memory.</p>
-<p>What you need is a Linux box in which PostgreSQL and pgpool-II are installed.
-You can use on memory query cache with pgpool in any mode: replication mode, master/slave mode and raw mode.</p>
-
-<p class="top_link"><a href="#Top">back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1 id="basic">On memory query cache</h1>
-
-<h2 id="memqcache_config">Configuring pgpool.conf</h2>
-
-<h3>Basic parameters</h3>
-
-<p>Set "memory_cache_enabled" on to enable the functionality of on memory query cache.</p>
-<pre># If on, use the memory cache functionality, off by default
-memory_cache_enabled = <b>on</b>
-</pre>
-
-<p>Pgpool creates "OID map" files which indicates that each cache are for which database and table.
-Specify the directory for it as you like.</p>
-<pre># Temporary work directory to record table oids
-memqcache_oiddir = '/var/log/pgpool/oiddir'
-</pre>
-
-<h3 id="config_shmem">About shared mamory</h3>
-
-<p>The parameter "memqcache_method" is the choice of the cache storage, and it defaults to "shmem".</p>
-<pre># Cache storage method. either 'shmem'(shared memory) or 'memcached'. 'shmem' by default
-memqcache_method = '<b>shmem</b>'
-</pre>
-
-<h3>About log</h3>
-<p>The parameter "log_per_node_statement" helps you to know in which backend node a query is executed.
-Set this parameter on.</p>
-<pre>log_per_node_statement = on
-                                   # Log all statements
-                                   # with node and backend informations
-</pre>
-
-<h2 id="basic_start">Starting pgpool</h2>
-
-<p>Start pgpool-II with "-n" (which means not-daemon mode) and redirect log messages into pgpool.log.</p>
-<pre>$ {installed_dir}/bin/pgpool -n -f {installed_dir}/etc/pgpool.conf &gt; pgpool.log 2&gt;&amp;1
-</pre>
-
-<p>Create a database and a table.</p>
-<pre>$ createdb -p 9999 test
-
-$ psql -p 9999 test
-test=&gt; CREATE TABLE table_cache_ok (a INT);
-CREATE TABLE
-
-test=&gt; INSERT INTO table_cache_ok VALUES (1), (2), (3);
-INSERT 0 3
-
-test=&gt; SELECT * FROM table_cache_ok ORDER BY a;
- a
----
- 1
- 2
- 3
-(3 rows)
-</pre>
-
-<!-- -------------------------------------------------------------------------------- -->
-
-<h2 id="basic_try">Trying out query cache</h2>
-
-<p>Execute a SELECT.</p>
-<pre>test=&gt; SELECT * FROM table_cache_ok WHERE a = 1;
- a
----
- 1
-(1 row)
-</pre>
-
-<p>The output of log_per_node_statement shows that the SELECT is executed exactly.</p>
-<pre>LOG:   DB node id: 0 backend pid: 11203 statement: SELECT * FROM table_cache_ok WHERE a = 1;
-</pre>
-
-<p>Execute the same SELECT.</p>
-<pre>test=&gt; SELECT * FROM table_cache_ok WHERE a = 1;
- a
----
- 1
-(1 row)
-</pre>
-
-<p>This time the log message shows that the result of SELECT is from caches.</p>
-<pre>LOG:   <b>query result fetched from cache.</b> statement: SELECT * FROM table_cache_ok WHERE a = 1;
-</pre>
-
-<p class="top_link"><a href="#Top">back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1 id="more">More fun with query cache</h1>
-
-<h2 id="invalidation">Auto invalidation</h2>
-
-<h3 id="invalidation_when_update">When a table is updated</h3>
-<p>When a table is updated, the cached results of SELECT from the table can be outdated.
-Pgpool discards all the cache of that table automatically by default.</p>
-
-<h4 id="invalidation_config">Configuration</h4>
-<p>Specify the action by "memqcache_auto_cache_invalidation". It's set "on" by default.</p>
-<pre># If on, invalidation of query cache is triggered by corresponding
-# DDL/DML/DCL(and memqcache_expire).  If off, it is only triggered
-# by memqcache_expire.  on by default.
-memqcache_auto_cache_invalidation = on
-</pre>
-
-<p>Restart pgpool after changing the parameter's value.</p>
-
-<h4 id="invalidation_try">Trying the cache invalidation</h4>
-<p>Confirm that you can get the result of a SELECT from cache.</p>
-<pre>test=&gt; SELECT * FROM table_cache_ok WHERE a = 1;
-LOG:   <b>query result fetched from cache.</b> statement: SELECT * FROM table_cache_ok WHERE a = 1;
-</pre>
-
-<p>Execute INSERT INTO the table.</p>
-<pre>test=&gt; INSERT INTO table_cache_ok VALUES (5);
-INSERT 0 1
-</pre>
-
-<p>Execute the same SELECT, and the SELECT is executed exactly.</p>
-<pre>test=&gt; SELECT * FROM table_cache_ok WHERE a = 1;
-LOG:   DB node id: 0 backend pid: 11203 statement: SELECT * FROM table_cache_ok WHERE a = 1;
-</pre>
-
-<h3 id="expire">Cache expiration</h3>
-<p>Pgpool discards caches older than the specified expiration period.</p>
-
-<h4 id="expire_config">Configuration</h4>
-<p>Specify the expiration period by "memqcache_expire".
-Default is 0 seconds, but set 5 seconds to confirm for trial this time.</p>
-<pre># Memory cache entry life time specified in seconds.
-# 0 means infinite life time. 0 by default.
-memqcache_expire = 5
-</pre>
-
-<p>Restart pgpool after changing the parameter's value.</p>
-
-<h4 id="expire_try">Try</h4>
-
-<p>Confirm that you can get the result of a SELECT from cache.</p>
-<pre>test=&gt; SELECT * FROM table_cache_ok WHERE a = 1;
-LOG:   <b>query result fetched from cache.</b> statement: SELECT * FROM table_cache_ok WHERE a = 1;
-</pre>
-
-<p>Wait in 5 seconds...</p>
-
-<p>Execute the same SELECT, and the SELECT is executed exactly.</p>
-<pre>test=&gt; SELECT * FROM table_cache_ok WHERE a = 1;
-LOG:   DB node id: 0 backend pid: 11203 statement: SELECT * FROM table_cache_ok WHERE a = 1;
-</pre>
-
-<!-- -------------------------------------------------------------------------------- -->
-
-<h2 id="white_and_black_list">White list and black list</h2>
-<h3 id="whitelist">Cache the result of some tables only</h3>
-
-<h4 id="whitelist_config">Configuration</h4>
-<p>If you want to cache the result of only some tabeles, specify the tables by "white_memqcache_table_list".</p>
-<p>You can use regular expression (to which added automatically ^ and $).</p>
-<pre>white_memqcache_table_list = '.*_cache_ok'
-                                   # Comma separated list of table names to memcache
-                                   # that don't write to database
-                                   # Regexp are accepted
-</pre>
-
-<p>Reload pgpool after changing the parameter's value.</p>
-<pre>$ {installed_dir}/bin/pgpool reload
-</pre>
-
-<h4 id="whitelist_try">Try</h4>
-<p>Create a table not to cache.</p>
-<pre>$ psql -p 9999 test
-test=&gt; CREATE TABLE table_cache_ng (a INT);
-CREATE TABLE
-
-test=&gt; INSERT INTO table_cache_ng VALUES (1), (2), (3);
-INSERT 0 3
-</pre>
-
-<p>Confirm if the SELECT FROM a table in white_memqcache_table_list is cached.</p>
-<pre>test=&gt; SELECT * FROM table_cache_ok WHERE a = 1;
-LOG:   DB node id: 0 backend pid: 11203 statement: SELECT oid FROM pg_database WHERE datname = 'test'
-
-test=&gt; SELECT * FROM table_cache_ok WHERE a = 1;
-LOG:   <b>query result fetched from cache.</b> statement: SELECT * FROM table_cache_ok WHERE a = 1;
-</pre>
-
-<p>Confirm if the SELECT FROM a table NOT in white_memqcache_table_list is NOT cached.</p>
-<pre>test=&gt; SELECT * FROM table_cache_ng WHERE a = 1;
-LOG:   DB node id: 0 backend pid: 11203 statement: SELECT * FROM table_cache_ok WHERE a = 1;
-
-test=&gt; SELECT * FROM table_cache_ng WHERE a = 1;
-LOG:   DB node id: 0 backend pid: 11203 statement: SELECT * FROM table_cache_ok WHERE a = 1;
-</pre>
-
-<h3 id="blacklist">Not cache the result of some tables</h3>
-<h4 id="blacklist_config">Config</h4>
-<p>If you don't want to cache the result of some tabeles, specify the tables by "black_memqcache_table_list".</p>
-<p>You can use regular expression (to which added automatically ^ and $).</p>
-<pre>black_memqcache_table_list = '.*_cache_ng'
-                                   # Comma separated list of table names not to memcache
-                                   # that don't write to database
-                                   # Regexp are accepted
-</pre>
-
-<p>Reload pgpool after changing the parameter's value.</p>
-<pre>$ {installed_dir}/bin/pgpool reload
-</pre>
-
-<h4 id="blacklist_try">Try</h4>
-<p>Confirm if the SELECT FROM a table in black_memqcache_table_list is NOT cached.</p>
-<pre>test=&gt; SELECT * FROM table_cache_ng WHERE a = 1;
-LOG:   DB node id: 0 backend pid: 11203 statement: SELECT * FROM table_cache_ok WHERE a = 1;
-
-test=&gt; SELECT * FROM table_cache_ng WHERE a = 1;
-LOG:   DB node id: 0 backend pid: 11203 statement: SELECT * FROM table_cache_ok WHERE a = 1;
-</pre>
-
-<p>Confirm if the SELECT FROM a table NOT in black_memqcache_table_list is cached.</p>
-<pre>test=&gt; SELECT * FROM table_cache_ok WHERE a = 1;
-LOG:   DB node id: 0 backend pid: 11203 statement: SELECT oid FROM pg_database WHERE datname = 'test'
-
-test=&gt; SELECT * FROM table_cache_ok WHERE a = 1;
-LOG:   <b>query result fetched from cache.</b> statement: SELECT * FROM table_cache_ok WHERE a = 1;
-</pre>
-
-<!-- -------------------------------------------------------------------------------- -->
-
-<h2 id="cache_or_not">What else?</h2>
-
-<h3 id="maxcacge">Too big results</h3>
-<p>The size of each SELECT result is limited by "memqcache_maxcache".</p>
-<pre># Maximum SELECT result size in bytes.
-# Must be smaller than memqcache_cache_block_size. Defaults to 400KB.
-memqcache_maxcache = 409600
-</pre>
-
-<p>If a result is bigger than memqcache_maxcache, the log message tells us that.
-This is an example when memqcache_maxcache is set 1024 byte and SELECTed table is bigger than 10 MB.</p>
-<pre>LOG:   DB node id: 0 backend pid: 17749 statement: SELECT * FROM pgbench_accounts ;
-LOG:   pool_add_temp_query_cache: <b>data size exceeds memqcache_maxcache</b>.
-                                  current:983 requested:110 memq_maxcache:1024
-</pre>
-
-<h3 id="no_query_cache">Specify each query not to cache</h3>
-<p>If white list and black list are not enough for you,
-put the text "/* NO QUERY CACHE */" at the head of the queries.</p>
-
-<pre>LOG:   statement: SELECT * FROM table_cache_ok WHERE a = 1;
-LOG:   query result fetched from cache. statement: SELECT * FROM table_cache_ok WHERE a = 1;
-
-LOG:   statement: /* NO QUERY CACHE */ SELECT * FROM table_cache_ok WHERE a = 1;
-LOG:   DB node id: 0 backend pid: 18070 statement: /* NO QUERY CACHE */ SELECT * FROM table_cache_ok WHERE a = 1;
-LOG:   statement: /* NO QUERY CACHE */ SELECT * FROM table_cache_ok WHERE a = 1;
-LOG:   DB node id: 0 backend pid: 18070 statement: /* NO QUERY CACHE */ SELECT * FROM table_cache_ok WHERE a = 1;
-</pre>
-
-<p>This way requires to change your program of course.</p>
-
-<p class="top_link"><a href="#Top">back to top</a></p>
-
-<!-- ================================================================================ -->
-
-</div>
-
-<div class="copyright" style="clear: both">
-<hr>
-<copyright>
-Copyright © 2003 – 2013 pgpool Global Development Group
-</copyright>
-</div>
-
-
-
-</body></html>
diff --git a/doc/tutorial-memqcache-ja.html b/doc/tutorial-memqcache-ja.html
deleted file mode 100644
index d6307c12c..000000000
--- a/doc/tutorial-memqcache-ja.html
+++ /dev/null
@@ -1,370 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
-<html>
-<head>
-<title>pgpool-II オンメモリクエリキャッシュ チュートリアル</title>
-<meta http-equiv="Content-Type" content="text/html; charset=utf8" />
-<link href="pgpool.css" rel="stylesheet" type="text/css" />
-</head>
-<body>
-
-<body bgcolor="#ffffff">
-<div id="top" class="header_text">pgpool-II オンメモリクエリキャッシュ チュートリアル</div>
-
-<div id="menu">
-    <div id="navcontainer">
-      <ul id="navlist">
-      <li><a href="#thisis">チュートリアルの概要</a>
-          <ul>
-          <li><a href="#memqcache_config">共有メモリに関する設定</a></li>
-          </ul>
-      </li>
-      <li><a href="#basic">簡単なクエリキャッシュ</a>
-          <ul>
-          <li><a href="#memqcache_config">pgpool.conf の設定</a></li>
-          <li><a href="#basic_start">pgpool-II の起動</a></li>
-          <li><a href="#basic_try">クエリキャッシュ</a></li>
-          </ul>
-      </li>
-      <li><a href="start#more">応用</a>
-          <ul>
-          <li><a href="#invalidation">キャッシュの無効化</a></li>
-          <li><a href="#white_and_black_list">ホワイトリスト / ブラックリスト</a></li>
-          <li><a href="#cache_or_not">キャッシュ可否の制御</a></li>
-          </ul>
-      </li>
-      </ul>
-    </div>
-
-    <div class="header_small" align="center">
-    [<a href="tutrial-memqcache-en.html">English page</a>]
-    </div>
-</div>
-
-<div id="manual">
-
-<!-- ================================================================================ -->
-
-<h1 id="thisis">チュートリアルの概要</h1>
-
-<p>このチュートリアルでは、共有メモリを使ったオンメモリクエリキャッシュを試す方法を説明します。</p>
-<p>必要なのは、Linux マシン 1 台で、PostgreSQL と pgpool-II がインストールされているものとします。
-なお、pgpool-II はどのモードで稼働していても、オンメモリクエリキャッシュを利用することができます。</p>
-
-<p class="top_link"><a href="#Top">△ back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1 id="basic">簡単なクエリキャッシュ</h1>
-
-<h2 id="memqcache_config">pgpool.conf の設定</h2>
-
-<h3>クエリキャッシュの基本設定</h3>
-
-<p>オンメモリクエリキャッシュ機能を有効にする「memory_cache_enabled」を on にします。</p>
-<pre>
-# If on, use the memory cache functionality, off by default
-memory_cache_enabled = <b>on</b>
-</pre>
-
-<p>メモリキャッシュでは、どの DB のどのテーブルのどのキャッシュ、という情報をファイルに保存していて、
-これを「OID マップ」と呼んでいます。
-このファイル群を配置するディレクトリを「memqcache_oiddir」で指定します。</p>
-<pre>
-# Temporary work directory to record table oids
-memqcache_oiddir = '/var/log/pgpool/oiddir'
-</pre>
-
-<h3 id="config_shmem">共有メモリに関する設定</h3>
-
-<p>
-キャッシュを記録する先を指定する「memqcache_method」は、デフォルトのまま
-shmem（共有メモリ）を指定します。</p>
-<pre>
-# Cache storage method. either 'shmem'(shared memory) or 'memcached'. 'shmem' by default
-memqcache_method = '<b>shmem</b>'
-</pre>
-
-<h3>ログ出力</h3>
-<p>オンメモリクエリキャッシュの動作確認に便利なため、どのバックエンドノードでどんなクエリが実行されたかを
-出力するフラグ「log_per_node_statement」を on にします。</p>
-<pre>
-log_per_node_statement = on
-                                   # Log all statements
-                                   # with node and backend informations
-</pre>
-
-<h2 id="basic_start">pgpool-II の起動</h2>
-
-<p>pgpool-II を起動します。
-なお、ログで動作確認するため、-n オプションをつけて非デーモンモードで起動し、
-出力されるログメッセージを pgpool.log ファイルにリダイレクトします。</p>
-<pre>
-$ {installed_dir}/bin/pgpool -n -f {installed_dir}/etc/pgpool.conf &gt; pgpool.log 2&gt;&amp;1
-</pre>
-
-<p>データベース、テーブルを作成します。</p>
-<pre>
-$ createdb -p 9999 test
-
-$ psql -p 9999 test
-test=&gt; CREATE TABLE table_cache_ok (a INT);
-CREATE TABLE
-
-test=&gt; INSERT INTO table_cache_ok VALUES (1), (2), (3);
-INSERT 0 3
-
-test=&gt; SELECT * FROM table_cache_ok ORDER BY a;
- a
----
- 1
- 2
- 3
-(3 rows)
-</pre>
-
-<!-- -------------------------------------------------------------------------------- -->
-
-<h2 id="basic_try">クエリキャッシュ</h2>
-
-<p>SELECT を実行してみます。</p>
-<pre>
-test=&gt; SELECT * FROM table_cache_ok WHERE a = 1;
- a
----
- 1
-(1 row)
-</pre>
-
-<p>ログの log_per_node_statement の出力から、SELECT が実行されていることがわかります。</p>
-<pre>
-LOG:   DB node id: 0 backend pid: 11203 statement: SELECT * FROM table_cache_ok WHERE a = 1;
-</pre>
-
-<p>では、もう一度同じ SELECT を実行します。</p>
-<pre>
-test=&gt; SELECT * FROM table_cache_ok WHERE a = 1;
- a
----
- 1
-(1 row)
-</pre>
-
-<p>ログを見ると今度は以下のメッセージがあり、キャッシュから結果を取得してきたことがわかります。</p>
-<pre>
-LOG:   <b>query result fetched from cache.</b> statement: SELECT * FROM table_cache_ok WHERE a = 1;
-</pre>
-
-<p class="top_link"><a href="#Top">△ back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1 id="more">応用</h1>
-
-<h2 id="invalidation">キャッシュの無効化</h2>
-
-<h3 id="invalidation_when_update">テーブルが更新されたとき</h3>
-<p>キャッシュした SELECT 結果は、そのテーブルが INSERT/UPDATE/DELETE されたとき、
-その SELECT 結果が古くなる可能性があります。
-デフォルトでは、INSERT/UPDATE/DELETE が行なわれたら、そのテーブルのキャッシュを削除します。
-<p>ここではその動作を確認します。</p>
-
-<h4 id="invalidation_config">設定</h4>
-<p>「memqcache_auto_cache_invalidation」で指定します。デフォルトでは on になっています。</p>
-<pre>
-# If on, invalidation of query cache is triggered by corresponding
-# DDL/DML/DCL(and memqcache_expire).  If off, it is only triggered
-# by memqcache_expire.  on by default.
-memqcache_auto_cache_invalidation = on
-</pre>
-
-<p>設定を変更した場合は、pgpool-II を再起動します。</p>
-
-<h4 id="invalidation_try">動作確認</h4>
-<p>SELECT がキャッシュされていることを確認します。</p>
-<pre>
-test=&gt; SELECT * FROM table_cache_ok WHERE a = 1;
-LOG:   <b>query result fetched from cache.</b> statement: SELECT * FROM table_cache_ok WHERE a = 1;
-</pre>
-
-<p>テーブルに INSERT を実行します。</p>
-<pre>
-test=&gt; INSERT INTO table_cache_ok VALUES (5);
-INSERT 0 1
-</pre>
-
-<p>再度 SELECT を実行し、キャッシュから取得されず、実際に SELECT が実行されることを確認します。</p>
-<pre>
-test=&gt; SELECT * FROM table_cache_ok WHERE a = 1;
-LOG:   DB node id: 0 backend pid: 11203 statement: SELECT * FROM table_cache_ok WHERE a = 1;
-</pre>
-
-<h3 id="expire">一定秒数経過したとき</h3>
-<p>そのほか、一定秒数が経過したキャッシュも、自動的に削除します。</p>
-
-<h4 id="expire_config">設定</h4>
-<p>「memqcache_expire」パラメータでその秒数を指定します。
-デフォルトは 0 秒ですが、ここでは動作確認のため 5 秒にしてみます。</p>
-<pre>
-# Memory cache entry life time specified in seconds.
-# 0 means infinite life time. 0 by default.
-memqcache_expire = 5
-</pre>
-
-<p>設定を変更したら、pgpool-II を再起動します。</p>
-
-<h4 id="expire_try">動作確認</h4>
-
-<p>SELECT がキャッシュされていることを確認します。</p>
-<pre>
-test=&gt; SELECT * FROM table_cache_ok WHERE a = 1;
-LOG:   <b>query result fetched from cache.</b> statement: SELECT * FROM table_cache_ok WHERE a = 1;
-</pre>
-
-<p>そのまま 5 秒以上待ちます。</p>
-
-<p>再度 SELECT を実行し、キャッシュから取得されず、実際に SELECT が実行されることを確認します。</p>
-<pre>
-test=&gt; SELECT * FROM table_cache_ok WHERE a = 1;
-LOG:   DB node id: 0 backend pid: 11203 statement: SELECT * FROM table_cache_ok WHERE a = 1;
-</pre>
-
-<!-- -------------------------------------------------------------------------------- -->
-
-<h2 id="white_and_black_list">ホワイトリスト / ブラックリスト</h2>
-<h3 id="whitelist">一部テーブルだけキャッシュする</h3>
-
-<h4 id="whitelist_config">設定</h4>
-<p>一部テーブルだけキャッシュしたい場合、「white_memqcache_table_list」にそのテーブルを指定します。
-TEMP テーブルや UNLOGGED テーブルも、ここに指定すればキャッシュされるようになります。</p>
-<p>テーブルの名前を直接指定することも、正規表現を使う（^ と $ が補完されて使われる）こともできます。</p>
-<pre>
-white_memqcache_table_list = '.*_cache_ok'
-                                   # Comma separated list of table names to memcache
-                                   # that don't write to database
-                                   # Regexp are accepted
-</pre>
-<p>設定を変更したら、pgpool-II をリロードします。</p>
-<pre>
-$ {installed_dir}/bin/pgpool reload
-</pre>
-
-<h4 id="whitelist_try">動作確認</h4>
-<p>キャッシュ不可とするテーブルを作成します。</p>
-<pre>
-$ psql -p 9999 test
-test=&gt; CREATE TABLE table_cache_ng (a INT);
-CREATE TABLE
-
-test=&gt; INSERT INTO table_cache_ng VALUES (1), (2), (3);
-INSERT 0 3
-</pre>
-
-<p>ホワイトリストに指定したテーブルの SELECT が、キャッシュされることを確認します。</p>
-<pre>
-test=&gt; SELECT * FROM table_cache_ok WHERE a = 1;
-LOG:   DB node id: 0 backend pid: 11203 statement: SELECT oid FROM pg_database WHERE datname = 'test'
-
-test=&gt; SELECT * FROM table_cache_ok WHERE a = 1;
-LOG:   <b>query result fetched from cache.</b> statement: SELECT * FROM table_cache_ok WHERE a = 1;
-</pre>
-
-<p>ホワイトリストに指定していないテーブル の SELECT が、キャッシュされないことを確認します。</p>
-<pre>
-test=&gt; SELECT * FROM table_cache_ng WHERE a = 1;
-LOG:   DB node id: 0 backend pid: 11203 statement: SELECT * FROM table_cache_ok WHERE a = 1;
-
-test=&gt; SELECT * FROM table_cache_ng WHERE a = 1;
-LOG:   DB node id: 0 backend pid: 11203 statement: SELECT * FROM table_cache_ok WHERE a = 1;
-</pre>
-
-<h3 id="blacklist">一部テーブルをキャッシュしない</h3>
-<h4 id="blacklist_config">設定</h4>
-<p>一部テーブルだけキャッシュしたくない場合、「black_memqcache_table_list」にそのテーブルを指定します。
-TEMP テーブルや UNLOGGED テーブルも、ここに指定したもの以外がキャッシュされるようになります。</p>
-<p>テーブルの名前を直接指定することも、正規表現を使う（^ と $ が補完されて使われる）こともできます。</p>
-<pre>
-black_memqcache_table_list = '.*_cache_ng'
-                                   # Comma separated list of table names not to memcache
-                                   # that don't write to database
-                                   # Regexp are accepted
-</pre>
-<p>設定を変更したら、pgpool-II をリロードします。</p>
-<pre>
-$ {installed_dir}/bin/pgpool reload
-</pre>
-
-<h4 id="blacklist_try">動作確認</h4>
-<p>ブラックリストに指定したテーブルの SELECT が、キャッシュされないことを確認します。</p>
-<pre>
-test=&gt; SELECT * FROM table_cache_ng WHERE a = 1;
-LOG:   DB node id: 0 backend pid: 11203 statement: SELECT * FROM table_cache_ok WHERE a = 1;
-
-test=&gt; SELECT * FROM table_cache_ng WHERE a = 1;
-LOG:   DB node id: 0 backend pid: 11203 statement: SELECT * FROM table_cache_ok WHERE a = 1;
-</pre>
-
-<p>ブラックリストに指定していないテーブル の SELECT が、キャッシュされることを確認します。</p>
-<pre>
-test=&gt; SELECT * FROM table_cache_ok WHERE a = 1;
-LOG:   DB node id: 0 backend pid: 11203 statement: SELECT oid FROM pg_database WHERE datname = 'test'
-
-test=&gt; SELECT * FROM table_cache_ok WHERE a = 1;
-LOG:   <b>query result fetched from cache.</b> statement: SELECT * FROM table_cache_ok WHERE a = 1;
-</pre>
-
-<!-- -------------------------------------------------------------------------------- -->
-
-<h2 id="cache_or_not">キャッシュ可否の制御</h2>
-
-<h3 id="maxcacge">結果が大きい SELECT がキャッシュされない</h3>
-<p>キャッシュできる SELECT 結果のサイズには限界があります。
-これを指定しているのが「memqcache_maxcache」パラメータです。</p>
-<pre>
-# Maximum SELECT result size in bytes.
-# Must be smaller than memqcache_cache_block_size. Defaults to 400KB.
-memqcache_maxcache = 409600
-</pre>
-
-<p>このサイズを超過しているときは、以下のログメッセージが出力されます。
-これは、「memqcache_maxcache」を 1024 バイトと非常に小さくして、10 MB 以上のテーブルを全件 SELECT した例です。</p>
-<pre>
-LOG:   DB node id: 0 backend pid: 17749 statement: SELECT * FROM pgbench_accounts ;
-LOG:   pool_add_temp_query_cache: <b>data size exceeds memqcache_maxcache</b>.
-                                  current:983 requested:110 memq_maxcache:1024
-</pre>
-
-<h3 id="no_query_cache">特定の SELECT をキャッシュしたくない</h3>
-<p>SELECT の可否をテーブルごとの指定ではなく、より細かく指定したい場合には、
-クエリの頭に「/* NO QUERY CACHE */」という接頭辞をつけることで対処することができます。</p>
-
-<p>例えば、以下のようにキャッシュされている SELECT でも、</p>
-<pre>
-LOG:   statement: SELECT * FROM table_cache_ok WHERE a = 1;
-LOG:   query result fetched from cache. statement: SELECT * FROM table_cache_ok WHERE a = 1;
-</pre>
-
-<p>「/* NO QUERY CACHE */」をつけて実行すると、キャッシュされないようになります。</p>
-<pre>
-LOG:   statement: /* NO QUERY CACHE */ SELECT * FROM table_cache_ok WHERE a = 1;
-LOG:   DB node id: 0 backend pid: 18070 statement: /* NO QUERY CACHE */ SELECT * FROM table_cache_ok WHERE a = 1;
-LOG:   statement: /* NO QUERY CACHE */ SELECT * FROM table_cache_ok WHERE a = 1;
-LOG:   DB node id: 0 backend pid: 18070 statement: /* NO QUERY CACHE */ SELECT * FROM table_cache_ok WHERE a = 1;
-</pre>
-
-<p>なおこれは、現実的にはアプリケーションに手を入れることになるでしょう。</p>
-
-<p class="top_link"><a href="#Top">△ back to top</a></p>
-
-<!-- ================================================================================ -->
-
-</div>
-
-<div class="copyright" style="clear: both">
-<hr>
-<copyright>
-Copyright &copy; 2003 &ndash; 2013 pgpool Global Development Group
-</copyright>
-</div>
-
-</body>
-</html>
diff --git a/doc/tutorial-memqcache-zh_cn.html b/doc/tutorial-memqcache-zh_cn.html
deleted file mode 100644
index 4ebea442a..000000000
--- a/doc/tutorial-memqcache-zh_cn.html
+++ /dev/null
@@ -1,322 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
-<html><head>
-<title>pgpool-II 入门教程 [ 基于内存的查询缓存 ]</title>
-<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
-<link href="pgpool.css" rel="stylesheet" type="text/css">
-</head>
-<body bgcolor="#ffffff">
-
-
-<div id="top" class="header_text">pgpool-II 入门教程 [ 基于内存的查询缓存 ]</div>
-
-<div id="menu">
-    <div id="navcontainer">
-      <ul id="navlist">
-      <li><a href="#thisis">关于本文档</a></li>
-      <li><a href="#basic">基于内存的查询缓存</a>
-          <ul>
-          <li><a href="#memqcache_config">配置 pgpool.conf</a></li>
-          <li><a href="#basic_start">启动 pgpool</a></li>
-          <li><a href="#basic_try">试用查询缓存</a></li>
-          </ul>
-      </li>
-      <li><a href="#more">更多内容</a>
-          <ul>
-          <li><a href="#invalidation">自动失效</a></li>
-          <li><a href="#white_and_black_list">白名单和黑名单</a></li>
-          <li><a href="#cache_or_not">其他内容</a></li>
-          </ul>
-      </li>
-      </ul>
-    </div>
-
-    <div class="header_small" align="center">
-    [<a href="tutrial-memqcache-en.html">英文页面</a>]
-    </div>
-</div>
-
-<div id="manual">
-
-<!-- ================================================================================ -->
-
-<h1 id="thisis">关于本文档</h1>
-
-<p>在本教程中，将讲解一个简单的方法来在共享内存中试用“基于内存的查询缓存”。</p>
-<p>你需要的是一个安装有 PostgreSQL 和 pgpool-II 的 Linux 测试环境。你可以在任何模式中使用
-基于内存的查询缓存：复制模式，主/备模式和原始模式。</p>
-
-<p class="top_link"><a href="#Top">返回顶部</a></p>
-
-<!-- ================================================================================ -->
-
-<h1 id="basic">基于内存的查询缓存</h1>
-
-<h2 id="memqcache_config">配置 pgpool.conf</h2>
-
-<h3>基本参数</h3>
-
-<p>设置 "memory_cache_enabled" 为 on 以启用基于内存的查询缓存功能。</p>
-<pre># If on, use the memory cache functionality, off by default
-memory_cache_enabled = <b>on</b>
-</pre>
-
-<p>pgpool 会建立“OID 映射”文件，它用于指明哪个缓存用于哪个数据库和表。指定你希望用于这个用途的目录。</p>
-<pre># Temporary work directory to record table oids
-memqcache_oiddir = '/var/log/pgpool/oiddir'
-</pre>
-
-<h3 id="config_shmem">关于共享内存</h3>
-
-<p>参数 "memqcache_method" 用于选择缓存的存储类型，默认为 "shmem"。</p>
-<pre># Cache storage method. either 'shmem'(shared memory) or 'memcached'. 'shmem' by default
-memqcache_method = '<b>shmem</b>'
-</pre>
-
-<h3>关于日志</h3>
-<p>参数 "log_per_node_statement" 可以帮助你了解某个查询是在哪个后端上执行。设置本参数为 on。</p>
-<pre>log_per_node_statement = on
-                                   # Log all statements
-                                   # with node and backend informations
-</pre>
-
-<h2 id="basic_start">启动 pgpool</h2>
-
-<p>使用 "-n" 参数（表示以非守护进程模式）启动 pgpool-II 并重定向日志消息到 pgpool.log 中。</p>
-<pre>$ {installed_dir}/bin/pgpool -n -f {installed_dir}/etc/pgpool.conf &gt; pgpool.log 2&gt;&amp;1
-</pre>
-
-<p>建立数据库和表。</p>
-<pre>$ createdb -p 9999 test
-
-$ psql -p 9999 test
-test=&gt; CREATE TABLE table_cache_ok (a INT);
-CREATE TABLE
-
-test=&gt; INSERT INTO table_cache_ok VALUES (1), (2), (3);
-INSERT 0 3
-
-test=&gt; SELECT * FROM table_cache_ok ORDER BY a;
- a
----
- 1
- 2
- 3
-(3 rows)
-</pre>
-
-<!-- -------------------------------------------------------------------------------- -->
-
-<h2 id="basic_try">试用查询缓存</h2>
-
-<p>执行一个 SELECT 语句。</p>
-<pre>test=&gt; SELECT * FROM table_cache_ok WHERE a = 1;
- a
----
- 1
-(1 row)
-</pre>
-
-<p>log_per_node_statement 的输出显示 SELECT 语句被实际执行了。</p>
-<pre>LOG:   DB node id: 0 backend pid: 11203 statement: SELECT * FROM table_cache_ok WHERE a = 1;
-</pre>
-
-<p>再次执行相同的 SELECT 语句。</p>
-<pre>test=&gt; SELECT * FROM table_cache_ok WHERE a = 1;
- a
----
- 1
-(1 row)
-</pre>
-
-<p>这次日志消息显示 SELECT 语句的结果来源于缓存。</p>
-<pre>LOG:   <b>query result fetched from cache.</b> statement: SELECT * FROM table_cache_ok WHERE a = 1;
-</pre>
-
-<p class="top_link"><a href="#Top">返回顶部</a></p>
-
-<!-- ================================================================================ -->
-
-<h1 id="more">查询缓存的更多内容</h1>
-
-<h2 id="invalidation">自动失效</h2>
-
-<h3 id="invalidation_when_update">当一个表被更新</h3>
-<p>当一个表被更新，这个表中缓存的 SELECT 的结果会过期。
-pgpool 默认情况下会自动忽略那个表上的所有缓存。</p>
-
-<h4 id="invalidation_config">配置</h4>
-<p>通过 "memqcache_auto_cache_invalidation" 指定动作。它的默认值是 "on"。</p>
-<pre># If on, invalidation of query cache is triggered by corresponding
-# DDL/DML/DCL(and memqcache_expire).  If off, it is only triggered
-# by memqcache_expire.  on by default.
-memqcache_auto_cache_invalidation = on
-</pre>
-
-<p>修改这个参数的值后，重启 pgpool。</p>
-
-<h4 id="invalidation_try">尝试自动失效的效果</h4>
-<p>确认你可以从缓存中获得 SELECT 语句的结果。</p>
-<pre>test=&gt; SELECT * FROM table_cache_ok WHERE a = 1;
-LOG:   <b>query result fetched from cache.</b> statement: SELECT * FROM table_cache_ok WHERE a = 1;
-</pre>
-
-<p>在这个表中执行 INSERT INTO 。</p>
-<pre>test=&gt; INSERT INTO table_cache_ok VALUES (5);
-INSERT 0 1
-</pre>
-
-<p>再次执行相同的 SELECT 语句，这条 SELECT 语句被实际执行。</p>
-<pre>test=&gt; SELECT * FROM table_cache_ok WHERE a = 1;
-LOG:   DB node id: 0 backend pid: 11203 statement: SELECT * FROM table_cache_ok WHERE a = 1;
-</pre>
-
-<h3 id="expire">缓存过期</h3>
-<p>pgpool 会忽略比指定过期周期更旧的缓存。</p>
-
-<h4 id="expire_config">配置</h4>
-<p>通过 "memqcache_expire" 指定过期周期。默认为 0 秒，不过为了测试我们在这里设置为 5 秒。</p>
-<pre># Memory cache entry life time specified in seconds.
-# 0 means infinite life time. 0 by default.
-memqcache_expire = 5
-</pre>
-
-<p>修改这个参数的值后，重启 pgpool。</p>
-
-<h4 id="expire_try">Try</h4>
-
-<p>确认你可以从缓存中获得 SELECT 语句的结果。</p>
-<pre>test=&gt; SELECT * FROM table_cache_ok WHERE a = 1;
-LOG:   <b>query result fetched from cache.</b> statement: SELECT * FROM table_cache_ok WHERE a = 1;
-</pre>
-
-<p>等 5 秒钟...</p>
-
-<p>再次执行相同的 SELECT 语句，这条 SELECT 语句被实际执行。</p>
-<pre>test=&gt; SELECT * FROM table_cache_ok WHERE a = 1;
-LOG:   DB node id: 0 backend pid: 11203 statement: SELECT * FROM table_cache_ok WHERE a = 1;
-</pre>
-
-<!-- -------------------------------------------------------------------------------- -->
-
-<h2 id="white_and_black_list">白名单和黑名单</h2>
-<h3 id="whitelist">只缓存某些表的结果</h3>
-
-<h4 id="whitelist_config">配置</h4>
-<p>如果你只想缓存某些表的结果，可以通过 "white_memqcache_table_list" 指定。</p>
-<p>可以使用正则表达式（会自动添加 ^ 和 $）。</p>
-<pre>white_memqcache_table_list = '.*_cache_ok'
-                                   # Comma separated list of table names to memcache
-                                   # that don't write to database
-                                   # Regexp are accepted
-</pre>
-
-<p>修改这个参数的值后，重新加载配置文件。</p>
-<pre>$ {installed_dir}/bin/pgpool reload
-</pre>
-
-<h4 id="whitelist_try">尝试</h4>
-<p>建立一个不需要缓存的表</p>
-<pre>$ psql -p 9999 test
-test=&gt; CREATE TABLE table_cache_ng (a INT);
-CREATE TABLE
-
-test=&gt; INSERT INTO table_cache_ng VALUES (1), (2), (3);
-INSERT 0 3
-</pre>
-
-<p>确认是否 SELECT FROM 在 white_memqcache_table_list 中的表被缓存。</p>
-<pre>test=&gt; SELECT * FROM table_cache_ok WHERE a = 1;
-LOG:   DB node id: 0 backend pid: 11203 statement: SELECT oid FROM pg_database WHERE datname = 'test'
-
-test=&gt; SELECT * FROM table_cache_ok WHERE a = 1;
-LOG:   <b>query result fetched from cache.</b> statement: SELECT * FROM table_cache_ok WHERE a = 1;
-</pre>
-
-<p>确认是否 SELECT FROM 不在 white_memqcache_table_list 中的表不被缓存。</p>
-<pre>test=&gt; SELECT * FROM table_cache_ng WHERE a = 1;
-LOG:   DB node id: 0 backend pid: 11203 statement: SELECT * FROM table_cache_ok WHERE a = 1;
-
-test=&gt; SELECT * FROM table_cache_ng WHERE a = 1;
-LOG:   DB node id: 0 backend pid: 11203 statement: SELECT * FROM table_cache_ok WHERE a = 1;
-</pre>
-
-<h3 id="blacklist">不缓存某些表的结果</h3>
-<h4 id="blacklist_config">Config</h4>
-<p>如果你不想缓存某些表的结果，可以通过 "black_memqcache_table_list" 指定。</p>
-<p>可以使用正则表达式（会自动添加 ^ 和 $）。</p>
-<pre>black_memqcache_table_list = '.*_cache_ng'
-                                   # Comma separated list of table names not to memcache
-                                   # that don't write to database
-                                   # Regexp are accepted
-</pre>
-
-<p>修改这个参数的值后，重新加载配置文件。</p>
-<pre>$ {installed_dir}/bin/pgpool reload
-</pre>
-
-<h4 id="blacklist_try">Try</h4>
-<p>确认是否 SELECT FROM 在 black_memqcache_table_list 中的表不被缓存。</p>
-<pre>test=&gt; SELECT * FROM table_cache_ng WHERE a = 1;
-LOG:   DB node id: 0 backend pid: 11203 statement: SELECT * FROM table_cache_ok WHERE a = 1;
-
-test=&gt; SELECT * FROM table_cache_ng WHERE a = 1;
-LOG:   DB node id: 0 backend pid: 11203 statement: SELECT * FROM table_cache_ok WHERE a = 1;
-</pre>
-
-<p>确认是否 SELECT FROM 不在 black_memqcache_table_list 中的表被缓存。</p>
-<pre>test=&gt; SELECT * FROM table_cache_ok WHERE a = 1;
-LOG:   DB node id: 0 backend pid: 11203 statement: SELECT oid FROM pg_database WHERE datname = 'test'
-
-test=&gt; SELECT * FROM table_cache_ok WHERE a = 1;
-LOG:   <b>query result fetched from cache.</b> statement: SELECT * FROM table_cache_ok WHERE a = 1;
-</pre>
-
-<!-- -------------------------------------------------------------------------------- -->
-
-<h2 id="cache_or_not">还有什么内容？</h2>
-
-<h3 id="maxcacge">太大的结果集</h3>
-<p>SELECT 的结果集的大小会受限于 "memqcache_maxcache"。</p>
-<pre># Maximum SELECT result size in bytes.
-# Must be smaller than memqcache_cache_block_size. Defaults to 400KB.
-memqcache_maxcache = 409600
-</pre>
-
-<p>如果结果集大于 memqcache_maxcache，日志信息会告诉我们。
-以下是一个示例，memqcache_maxcache 被设置为 1024 字节而 SELECT 出来的表的大小超过 10 MB。</p>
-<pre>LOG:   DB node id: 0 backend pid: 17749 statement: SELECT * FROM pgbench_accounts ;
-LOG:   pool_add_temp_query_cache: <b>data size exceeds memqcache_maxcache</b>.
-                                  current:983 requested:110 memq_maxcache:1024
-</pre>
-
-<h3 id="no_query_cache">指定某个查询不需要缓存</h3>
-<p>如果白名单和黑名单还不够用，可以在查询最开始的地方
-put the text "/* NO QUERY CACHE */" at the head of the queries.</p>
-
-<pre>LOG:   statement: SELECT * FROM table_cache_ok WHERE a = 1;
-LOG:   query result fetched from cache. statement: SELECT * FROM table_cache_ok WHERE a = 1;
-
-LOG:   statement: /* NO QUERY CACHE */ SELECT * FROM table_cache_ok WHERE a = 1;
-LOG:   DB node id: 0 backend pid: 18070 statement: /* NO QUERY CACHE */ SELECT * FROM table_cache_ok WHERE a = 1;
-LOG:   statement: /* NO QUERY CACHE */ SELECT * FROM table_cache_ok WHERE a = 1;
-LOG:   DB node id: 0 backend pid: 18070 statement: /* NO QUERY CACHE */ SELECT * FROM table_cache_ok WHERE a = 1;
-</pre>
-
-<p>当然，这种方法需要修改你的程序。</p>
-
-<p class="top_link"><a href="#Top">返回顶部</a></p>
-
-<!-- ================================================================================ -->
-
-</div>
-
-<div class="copyright" style="clear: both">
-<hr>
-<copyright>
-Copyright © 2003 – 2013 pgpool Global Development Group
-</copyright>
-</div>
-
-
-
-</body></html>
diff --git a/doc/tutorial-watchdog-en.html b/doc/tutorial-watchdog-en.html
deleted file mode 100644
index 544fef454..000000000
--- a/doc/tutorial-watchdog-en.html
+++ /dev/null
@@ -1,306 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
-<html><head>
-<title>pgpool-II Tutorial [ Watchdog ]</title>
-<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
-<link href="pgpool.css" rel="stylesheet" type="text/css">
-
-<style type="text/css">
-img {
-    border: 1px solid black;
-    padding: 10px;
-    margin-top: 15px;
-    margin-bottom: 15px;
-}
-</style>
-
-</head>
-<body bgcolor="#ffffff">
-
-
-<div id="top" class="header_text">pgpool-II Tutorial [ Watchdog ]</div>
-
-<div id="menu">
-    <div id="navcontainer">
-      <ul id="navlist">
-      <li><a href="#thisis">About this document</a></li>
-      <li><a href="#basic">Basic configs</a>
-          <ul>
-          <li><a href="#basic_config">pgpool.conf</a></li>
-          <li><a href="#basic_start">Start pgpool</a></li>
-          </ul>
-      </li>
-      <li><a href="#try">Try watchdog</a>
-          <ul>
-          <li><a href="#try_vip">Connection to virtual IP</a></li>
-          <li><a href="#try_switch">Switching virtual IP</a></li>
-          </ul>
-      </li>
-      <li><a href="start#more">More</a>
-          <ul>
-          <li><a href="#more_lifecheck">Lifecheck</a></li>
-          <li><a href="#more_switch">Virtual IP</a></li>
-          </ul>
-      </li>
-      </ul>
-    </div>
-
-    <div class="header_small" align="center">
-    [<a href="tutorial-watchdog-ja.html">Japanese page</a>]
-    </div>
-</div>
-
-<div id="manual">
-
-<!-- ================================================================================ -->
-
-<h1 id="thisis">About this document</h1>
-
-<p>In this tutrial, I explain the simple way to try "Watchdog".</p>
-<p>What you need is 2 Linux boxes in which pgpool-II is installed and
-a PostgreSQL in the same machine or in the other one.
-it is enough that 1 node for backend exists.
-</p>
-<p>You can use on memory query cache with pgpool in any mode: replication mode, master/slave mode and raw mode.</p>
-
-<p>I use "osspc16" as an Active node and "osspc20" as a Standby node.
-"Someserver" means one of them.</p>
-
-<p><img src="watchdog.png" alt=""></p>
-
-<p class="top_link"><a href="#Top">back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1 id="basic">Basic configs</h1>
-
-<h2 id="basic_config">pgpool.conf</h2>
-
-<h3>In both of Active and Standby</h3>
-<p>Set the parameters in both of active and standby nodes.</p>
-
-<h4 id="basic_config_ebable">Enabling watchdog</h4>
-<p>First of all, set the flag to enable watchdog "use_watchdog" on.</p>
-<pre>use_watchdog = <b>on</b>
-                                    # Activates watchdog
-</pre>
-
-<h4 id="basic_config_upper">Up stream servers</h4>
-<p>Specify up stream servers (e.g. application servers). To be blank is OK.</p>
-<pre>trusted_servers = ''
-                                    # trusted server list which are used
-                                    # to confirm network connection
-                                    # (hostA,hostB,hostC,...)
-</pre>
-
-<h4 id="basic_config_watchdog">watchdog</h4>
-<p>Specify the port of watchdog. </p>
-<pre>wd_port = 9000
-                                    # port number for watchdog service
-</pre>
-
-<h4 id="basic_config_vip">Virtual IP</h4>
-<p>Specify the IP address for virtual IP address in "delegate_IP" which must not not be used by someone else.</p>
-<pre>delegate_IP = '<b>133.137.177.143</b>'
-                                    # delegate IP address
-</pre>
-
-<h3 id="basic_config_lifecheck">Monitoring</h3>
-<p>Next, set parameters for each pgpool.</p>
-<p>Specify "other_pgpool_hostname0", "other_pgpool_port0" and "other_wd_port0"
-where pgpool and watchdog to monitor.</p>
-<p>[*] Other_pgpool_hostname0 must be the value returned by hostname command.</p>
-
-<h4>Active (osspc16)</h4>
-<pre>other_pgpool_hostname0 = '<b>osspc20</b>'
-                                    # Host name or IP address to connect to for other pgpool 0
-other_pgpool_port0 = 9999
-                                    # Port number for othet pgpool 0
-other_wd_port0 = 9000
-                                    # Port number for othet watchdog 0
-</pre>
-
-<h4>Standby (osspc20)</h4>
-<pre>other_pgpool_hostname0 = '<b>osspc16</b>'
-                                    # Host name or IP address to connect to for other pgpool 0
-other_pgpool_port0 = 9999
-                                    # Port number for othet pgpool 0
-other_wd_port0 = 9000
-                                    # Port number for othet watchdog 0
-</pre>
-
-<!-- -------------------------------------------------------------------------------- -->
-
-<h2 id="basic_start">Starting pgpool</h2>
-
-<p>Start pgpool in each servers as root
-with "-n" (which means not-daemon mode) and redirect log messages into pgpool.log.
-</p>
-
-<h3>Starting pgpool in Active server (osspc16)</h3>
-<p>Start pgpool in an Active server.</p>
-<pre>[user@osspc16]$ su -
-[root@osspc16]# {installed_dir}/bin/pgpool -n -f {installed_dir}/etc/pgpool.conf &gt; pgpool.log 2&gt;&amp;1
-</pre>
-
-<p>Log messages show that pgpool has the virtual IP address and starts watchdog process.</p>
-<pre>ERROR: wd_create_send_socket: connect() is failed(Connection refused)
-LOG:   wd_escalation: eslcalated to master pgpool
-ERROR: wd_create_send_socket: connect() is failed(Connection refused)
-LOG:   wd_escalation:  <b>escaleted to delegate_IP holder</b>
-LOG:   wd_init: <b>start watchdog</b>
-LOG:   pgpool-II successfully started. version 3.2beta1 (namameboshi)
-</pre>
-
-<h3>Starting pgpool in Standby server (osspc20)</h3>
-<p>Start pgpool in Standby server.</p>
-<pre>[user@osspc20]$ su -
-[root@osspc20]# {installed_dir}/bin/pgpool -n -f {installed_dir}/etc/pgpool.conf &gt; pgpool.log 2&gt;&amp;1
-</pre>
-
-<p>When the all watchdog listed in other_pgpool_hostname get started, lifecheck starts.
-In this case osspc16 is the only other watchdog besides myself, lifecheck has started now.</p>
-<pre>LOG:   wd_init: start watchdog
-LOG:   pgpool-II successfully started. version 3.2beta1 (namameboshi)
-LOG:   watchdog: <b>lifecheck started</b>
-</pre>
-
-<p>And in an Active, lifecheck has started.</p>
-<pre>LOG:   watchdog: <b>lifecheck started</b>
-</pre>
-
-<p class="top_link"><a href="#Top">back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1 id="try">Try</h1>
-
-<h2 id="try_vip">Connecting to virtual IP</h2>
-<p>Confirm to ping to the virtual IP address.</p>
-<pre>[user@someserver]$ ping 133.137.177.142
-PING 133.137.177.143 (133.137.177.143) 56(84) bytes of data.
-64 bytes from 133.137.177.143: icmp_seq=1 ttl=64 time=0.328 ms
-64 bytes from 133.137.177.143: icmp_seq=2 ttl=64 time=0.264 ms
-64 bytes from 133.137.177.143: icmp_seq=3 ttl=64 time=0.412 ms
-</pre>
-
-<p>Confirm if the Active server which started at first has the virtual IP address.</p>
-<pre>[root@osspc16]# ifconfig
-eth0      ...
-
-<b>eth0:0</b>    inet addr:133.137.177.143 ...
-
-lo        ...
-</pre>
-
-<p>Confirm if the Standby server which started not at first doesn't have the virtual IP address.</p>
-<pre>[root@osspc20]# ifconfig
-eth0      ...
-
-lo        ...
-</pre>
-
-<p>Try to connect PostgreSQL by "psql -h delegate_IP -p port".</p>
-<pre>[user@someserver]$ psql -h 133.137.177.142 -p 9999 -l
-</pre>
-
-<!-- -------------------------------------------------------------------------------- -->
-
-<h2 id="try_switch">Switching virtual IP</h2>
-
-<p>Confirm how the Standby server works when the Active server can't provide its service.</p>
-
-<p>Stop pgpool in the Active server.</p>
-<pre>[root@osspc16]# {installed_dir}/bin/pgpool stop
-</pre>
-
-<p>Then, the Standby server starts to use the virtual IP address. Log shows:</p>
-<pre>LOG:   wd_escalation: <b>eslcalated to master pgpool</b>
-ERROR: wd_create_send_socket: connect() is failed(Connection refused)
-LOG:   wd_escalation:  escaleted to delegate_IP holder
-</pre>
-
-<p>Confirm to ping to the virtual IP address.</p>
-<pre>[user@someserver]$ ping 133.137.177.142
-PING 133.137.177.143 (133.137.177.143) 56(84) bytes of data.
-64 bytes from 133.137.177.143: icmp_seq=1 ttl=64 time=0.328 ms
-64 bytes from 133.137.177.143: icmp_seq=2 ttl=64 time=0.264 ms
-64 bytes from 133.137.177.143: icmp_seq=3 ttl=64 time=0.412 ms
-</pre>
-
-<p>Confirm that the Active server doesn't use the virtual IP address any more.</p>
-<pre>[root@osspc16]# ifconfig
-eth0      ...
-
-lo        ...
-</pre>
-
-<p>Confirm that the Standby server uses the virtual IP address.</p>
-<pre>[root@osspc20]# ifconfig
-eth0      ...
-
-<b>eth0:0</b>    inet addr:133.137.177.143 ...
-
-lo        ...
-</pre>
-
-<p>Try to connect PostgreSQL by "psql -h delegate_IP -p port".</p>
-<pre>[user@someserver]$ psql -h 133.137.177.142 -p 9999 -l
-</pre>
-
-<p class="top_link"><a href="#Top">back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1 id="more">More</h1>
-
-<h2 id="more_lifecheck">Lifecheck</h2>
-
-<p>There are the parameters about watchdog's monitoring.</p>
-
-<p>Specify the interval to check "wd_interval", the count to retry "wd_life_point",
-the qyery to check "wd_lifecheck_query".</p>
-<pre>wd_interval = 10
-                                    # lifecheck interval (sec) &gt; 0
-wd_life_point = 3
-                                    # lifecheck retry times
-wd_lifecheck_query = 'SELECT 1'
-                                    # lifecheck query to pgpool from watchdog
-</pre>
-
-<!-- -------------------------------------------------------------------------------- -->
-
-<h2 id="more_switch">Switching virtual IP address</h2>
-
-<p>There are the parameters for switching the virtual IP address.</p>
-
-<p>Specify switching commands "if_up_cmd", "if_down_cmd", the path to them "ifconfig_path",
-the command executed after switching to send ARP request"arping_cmd" and the path to it "arping_path".</p>
-
-<pre>ifconfig_path = '/sbin'
-                                    # ifconfig command path
-if_up_cmd = 'ifconfig eth0:0 inet $_IP_$ netmask 255.255.255.0'
-                                    # startup delegate IP command
-if_down_cmd = 'ifconfig eth0:0 down'
-                                    # shutdown delegate IP command
-
-arping_path = '/usr/sbin'           # arping command path
-
-arping_cmd = 'arping -U $_IP_$ -w 1'
-</pre>
-
-<p class="top_link"><a href="#Top">back to top</a></p>
-
-</div>
-
-<!-- ================================================================================ -->
-
-<div class="copyright" style="clear: both">
-<hr>
-<copyright>
-Copyright © 2003 – 2012 pgpool Global Development Group
-</copyright>
-</div>
-
-
-
-</body></html>
diff --git a/doc/tutorial-watchdog-ja.html b/doc/tutorial-watchdog-ja.html
deleted file mode 100644
index 1d105d2f0..000000000
--- a/doc/tutorial-watchdog-ja.html
+++ /dev/null
@@ -1,343 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
-<html>
-<head>
-<title>pgpool-II watchdog チュートリアル</title>
-<meta http-equiv="Content-Type" content="text/html; charset=utf8" />
-<link href="pgpool.css" rel="stylesheet" type="text/css" />
-
-<style type="text/css">
-img {
-    border: 1px solid black;
-    padding: 10px;
-    margin-top: 15px;
-    margin-bottom: 15px;
-}
-</style>
-
-</head>
-<body>
-
-<body bgcolor="#ffffff">
-<div id="top" class="header_text">pgpool-II watchdog チュートリアル</div>
-
-<div id="menu">
-    <div id="navcontainer">
-      <ul id="navlist">
-      <li><a href="#thisis">チュートリアルの概要</a></li>
-      <li><a href="#basic">基本設定</a>
-          <ul>
-          <li><a href="#basic_config">pgpool.conf 設定</a></li>
-          <li><a href="#basic_start">pgpool-II の起動</a></li>
-          </ul>
-      </li>
-      <li><a href="#try">簡単な watchdog 動作確認</a>
-          <ul>
-          <li><a href="#try_vip">仮想 IP アドレスへの接続</a></li>
-          <li><a href="#try_switch">仮想 IP アドレスの切り替え</a></li>
-          </ul>
-      </li>
-      <li><a href="start#more">応用</a>
-          <ul>
-          <li><a href="#more_lifecheck">監視についての設定</a></li>
-          <li><a href="#more_switch">仮想 IP アドレス切り替えについての設定</a></li>
-          </ul>
-      </li>
-      </ul>
-    </div>
-
-    <div class="header_small" align="center">
-    [<a href="tutorial-watchdog-en.html">English page</a>]
-    </div>
-</div>
-
-<div id="manual">
-
-<!-- ================================================================================ -->
-
-<h1 id="thisis">チュートリアルの概要</h1>
-
-<p>このチュートリアルでは、watchdog 機能を試す方法を説明します。</p>
-<p>Linux マシン 2 台にそれぞれ pgpool-II がインストールされているものとします。
-また、いずれかのマシンか第 3 のマシンに、PostgreSQL がインストールされて稼働しているものとします
-（backend ノードは 1 台でかまいません）。
-なお、pgpool-II はどのモードで稼働していても、watchdog を利用することができます。</p>
-<p>この文書では、Active を「osspc16」、Standby を「osspc20」とします。
-また psql などを実行するサーバを便宜上「someserver」と表記していますが、Active、Standby のサーバで構いません。</p>
-
-<p><img src="watchdog.png" alt="" /></p>
-
-<p class="top_link"><a href="#Top">△ back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1 id="basic">基本設定</h1>
-
-<h2 id="basic_config">pgpool.conf 設定</h2>
-
-<h3>Active / Standby 共通</h3>
-<p>2 台の pgpool-II でそれぞれ設定します。</p>
-
-<h4 id="basic_config_ebable">watchdog の有効化</h4>
-<p>まず、watchdog 機能を有効にするフラグ「use_watchdog」を on にします。</p>
-<pre>
-use_watchdog = <b>on</b>
-                                    # Activates watchdog
-</pre>
-
-<h4 id="basic_config_upper">上位サーバ</h4>
-<p>アプリケーションサーバなど上位のサーバを指定する「trusted_servers」を記述します。
-<p>ここでは空欄にしておきます。</p>
-<pre>
-trusted_servers = ''
-                                    # trusted server list which are used
-                                    # to confirm network connection
-                                    # (hostA,hostB,hostC,...)
-</pre>
-
-<h4 id="basic_config_watchdog">watchdog</h4>
-<p>watchdog を起動するポートを「wd_port」」を指定します。</p>
-<p>ここではデフォルトのままにしておきます。</p>
-<pre>
-wd_port = 9000
-                                    # port number for watchdog service
-</pre>
-
-<h4 id="basic_config_vip">仮想 IP</h4>
-<p>仮想 IP を「delegate_IP」に指定します。まだ使われてない IP アドレスを記述します。</p>
-<pre>
-delegate_IP = '<b>133.137.177.143</b>'
-                                    # delegate IP address
-</pre>
-
-<h3 id="basic_config_lifecheck">監視対象サーバ関連</h3>
-<p>以下は、それぞれの pgpool-II で設定します。</p>
-<p>監視対象とする pgpool-II が稼働する  ホスト名「other_pgpool_hostname0」、
-その pgpool-II のポート番号「other_pgpool_port0」、
-その watchdog のポート番号「other_wd_port0」を、それぞれで記述します。
-</p>
-<p>なお、ホスト名は hostname コマンドの実行結果どおりのものを記述します。</p>
-<h4>Active (osspc16)</h4>
-<pre>
-other_pgpool_hostname0 = '<b>osspc20</b>'
-                                    # Host name or IP address to connect to for other pgpool 0
-other_pgpool_port0 = 9999
-                                    # Port number for othet pgpool 0
-other_wd_port0 = 9000
-                                    # Port number for othet watchdog 0
-</pre>
-
-<h4>Standby (osspc20)</h4>
-<pre>
-other_pgpool_hostname0 = '<b>osspc16</b>'
-                                    # Host name or IP address to connect to for other pgpool 0
-other_pgpool_port0 = 9999
-                                    # Port number for othet pgpool 0
-other_wd_port0 = 9000
-                                    # Port number for othet watchdog 0
-</pre>
-
-<!-- -------------------------------------------------------------------------------- -->
-
-<h2 id="basic_start">pgpool-II の起動</h2>
-
-<p>両方のサーバで pgpool-II を root で起動します。
-なお、ログで動作確認するため、-n オプションをつけて非デーモンモードで起動し、
-出力されるログメッセージを pgpool.log ファイルにリダイレクトします。</p>
-</p>
-
-<h3>Active サーバの pgpool-II の起動 (osspc16)</h3>
-<p>Active サーバで pgpool-II を起動します。</p>
-<pre>
-[user@osspc16]$ su -
-[root@osspc16]# {installed_dir}/bin/pgpool -n -f {installed_dir}/etc/pgpool.conf &gt; pgpool.log 2&gt;&amp;1
-</pre>
-
-<p>ログから、仮想 IP アドレスを使用し、また watchdog プロセス起動したことが確認できます。
-（なおこのログでの ERROR は、まだ起動していない Standby サーバの watchdog に接続しようとして失敗した、
-というものなので、無視して構いません。）</p>
-<pre>
-ERROR: wd_create_send_socket: connect() is failed(Connection refused)
-LOG:   wd_escalation: eslcalated to master pgpool
-ERROR: wd_create_send_socket: connect() is failed(Connection refused)
-LOG:   wd_escalation:  <b>escaleted to delegate_IP holder</b>
-LOG:   wd_init: <b>start watchdog</b>
-LOG:   pgpool-II successfully started. version 3.2beta1 (namameboshi)
-</pre>
-
-<h3>Standby サーバの pgpool-II の起動 (osspc20)</h3>
-<p>Standby サーバで pgpool-II を起動します。</p>
-<pre>
-[user@osspc20]$ su -
-[root@osspc20]# {installed_dir}/bin/pgpool -n -f {installed_dir}/etc/pgpool.conf &gt; pgpool.log 2&gt;&amp;1
-</pre>
-
-<p>「other_pgpool_hostname*」等に指定したすべての watchdog が起動していると、
-死活監視（lifecheck）が開始します。
-ここでは osspc16 しか指定していないので、この時点で開始したことがログからわかります。</p>
-<pre>
-LOG:   wd_init: start watchdog
-LOG:   pgpool-II successfully started. version 3.2beta1 (namameboshi)
-LOG:   watchdog: <b>lifecheck started</b>
-</pre>
-
-<p>すると、Active でも、死活監視を始めたというログメッセージが出力されます。</p>
-<pre>
-LOG:   watchdog: <b>lifecheck started</b>
-</pre>
-
-<p class="top_link"><a href="#Top">△ back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1 id="try">簡単な watchdog 動作確認</h1>
-
-<h2 id="try_vip">仮想 IP アドレスへの接続</h2>
-<p>「delegate_IP」に指定した仮想 IP アドレスに、ping が通ることを確認します。</p>
-<pre>
-[user@someserver]$ ping 133.137.177.142
-PING 133.137.177.143 (133.137.177.143) 56(84) bytes of data.
-64 bytes from 133.137.177.143: icmp_seq=1 ttl=64 time=0.328 ms
-64 bytes from 133.137.177.143: icmp_seq=2 ttl=64 time=0.264 ms
-64 bytes from 133.137.177.143: icmp_seq=3 ttl=64 time=0.412 ms
-</pre>
-
-<p>先に pgpool-II を立ち上げた Active サーバが、仮想 IP アドレスを使っていることを確認します。</p>
-<pre>
-[root@osspc16]# ifconfig
-eth0      ...
-
-<b>eth0:0</b>    inet addr:133.137.177.143 ...
-
-lo        ...
-</pre>
-
-<p>あとから pgpool-II を立ち上げた Standby サーバで、仮想 IP アドレスを使っていないことを確認します。</p>
-<pre>
-[root@osspc20]# ifconfig
-eth0      ...
-
-lo        ...
-</pre>
-
-<p>仮想 IP アドレスを使って、PostgreSQL に接続できることを確認します。
--h オプションには「delegate_IP」の IP アドレスを、-p オプションには「port」のポート番号を指定します。</p>
-<pre>
-[user@someserver]$ psql -h 133.137.177.142 -p 9999 -l
-</pre>
-
-<!-- -------------------------------------------------------------------------------- -->
-
-<h2 id="try_switch">仮想 IP アドレスの切り替え</h2>
-
-<p>Active サーバがサービス供給不可な状態になったときに、Standby がそれを引き継ぐのを確認します。</p>
-
-<p>Active サーバで pgpool-II が停止してしまったのを想定し、意図的に停止します。</p>
-<pre>
-[root@osspc16]# {installed_dir}/bin/pgpool stop
-</pre>
-
-<p>すると Standby サーバで、仮想 IP アドレスを使用しはじめたというログメッセージが出力されます。</p>
-<pre>
-LOG:   wd_escalation: <b>eslcalated to master pgpool</b>
-ERROR: wd_create_send_socket: connect() is failed(Connection refused)
-LOG:   wd_escalation:  escaleted to delegate_IP holder
-</pre>
-
-<p>また、Standby サーバでも死活監視が開始します。</p>
-<pre>
-LOG:   watchdog: lifecheck started
-</pre>
-
-<p>「delegate_IP」に指定した仮想 IP アドレスに、ping が通ることを確認します。</p>
-<pre>
-[user@someserver]$ ping 133.137.177.142
-PING 133.137.177.143 (133.137.177.143) 56(84) bytes of data.
-64 bytes from 133.137.177.143: icmp_seq=1 ttl=64 time=0.328 ms
-64 bytes from 133.137.177.143: icmp_seq=2 ttl=64 time=0.264 ms
-64 bytes from 133.137.177.143: icmp_seq=3 ttl=64 time=0.412 ms
-</pre>
-
-<p>Active で仮想 IP アドレスが使われなくなったのを確認します。</p>
-<pre>
-[root@osspc16]# ifconfig
-eth0      ...
-
-lo        ...
-</pre>
-
-<p>今度は Standby で仮想 IP アドレスが使われるようになったのを確認します。</p>
-<pre>
-[root@osspc20]# ifconfig
-eth0      ...
-
-<b>eth0:0</b>    inet addr:133.137.177.143 ...
-
-lo        ...
-</pre>
-
-<p>仮想 IP アドレスを使って、PostgreSQL に接続できることを確認します。</p>
-<pre>
-[user@someserver]$ psql -h 133.137.177.142 -p 9999 -l
-</pre>
-
-<p class="top_link"><a href="#Top">△ back to top</a></p>
-
-<!-- ================================================================================ -->
-
-<h1 id="more">応用</h1>
-
-<h2 id="more_lifecheck">監視についての設定</h2>
-
-<p>watchdog の監視方法について設定するパラメータがあります。</p>
-
-<p>監視間隔秒を指定する「wd_interval」、リトライ回数を指定する「wd_life_point」、
-監視に使うクエリを指定する「wd_lifecheck_query」を記述します。</p>
-<pre>
-wd_interval = 10
-                                    # lifecheck interval (sec) &gt; 0
-wd_life_point = 3
-                                    # lifecheck retry times
-wd_lifecheck_query = 'SELECT 1'
-                                    # lifecheck query to pgpool from watchdog
-</pre>
-
-<!-- -------------------------------------------------------------------------------- -->
-
-<h2 id="more_switch">仮想 IP アドレス切り替えについての設定</h2>
-
-<p>仮想 IP アドレスの切り替えコマンドについて設定するパラメータがあります。</p>
-
-<p>仮想 IP を切り替える際に使うコマンドとして「if_up_cmd」「if_down_cmd」、
-そのパスを指定する「ifconfig_path」を記述します。
-また、仮想 IP 切り替え後の ARP リクエスト送信コマンドを指定する「arping_cmd」、
-そのパスを指定する「arping_path」を記述します。</p>
-<p>なお通常は、デフォルト値のまま変更する必要はありません。</p>
-
-<pre>
-ifconfig_path = '/sbin'
-                                    # ifconfig command path
-if_up_cmd = 'ifconfig eth0:0 inet $_IP_$ netmask 255.255.255.0'
-                                    # startup delegate IP command
-if_down_cmd = 'ifconfig eth0:0 down'
-                                    # shutdown delegate IP command
-
-arping_path = '/usr/sbin'           # arping command path
-
-arping_cmd = 'arping -U $_IP_$ -w 1'
-</pre>
-
-<p class="top_link"><a href="#Top">△ back to top</a></p>
-
-</div>
-
-<!-- ================================================================================ -->
-
-<div class="copyright" style="clear: both">
-<hr>
-<copyright>
-Copyright &copy; 2003 &ndash; 2012 pgpool Global Development Group
-</copyright>
-</div>
-
-</body>
-</html>
diff --git a/doc/tutorial-watchdog-zh_cn.html b/doc/tutorial-watchdog-zh_cn.html
deleted file mode 100644
index 93a1d127f..000000000
--- a/doc/tutorial-watchdog-zh_cn.html
+++ /dev/null
@@ -1,301 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
-<html><head>
-<title>pgpool-II 入门教程 [ 看门狗 ]</title>
-<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
-<link href="pgpool.css" rel="stylesheet" type="text/css">
-
-<style type="text/css">
-img {
-    border: 1px solid black;
-    padding: 10px;
-    margin-top: 15px;
-    margin-bottom: 15px;
-}
-</style>
-
-</head>
-<body bgcolor="#ffffff">
-
-
-<div id="top" class="header_text">pgpool-II 入门教程 [ 看门狗 ]</div>
-
-<div id="menu">
-    <div id="navcontainer">
-      <ul id="navlist">
-      <li><a href="#thisis">关于本文档</a></li>
-      <li><a href="#basic">基础配置</a>
-          <ul>
-          <li><a href="#basic_config">pgpool.conf</a></li>
-          <li><a href="#basic_start">启动 pgpool</a></li>
-          </ul>
-      </li>
-      <li><a href="#try">试用看门狗</a>
-          <ul>
-          <li><a href="#try_vip">连接到虚拟 IP</a></li>
-          <li><a href="#try_switch">切换虚拟 IP</a></li>
-          </ul>
-      </li>
-      <li><a href="start#more">更多内容</a>
-          <ul>
-          <li><a href="#more_lifecheck">存活检测（lifecheck）</a></li>
-          <li><a href="#more_switch">虚拟 IP</a></li>
-          </ul>
-      </li>
-      </ul>
-    </div>
-
-    <div class="header_small" align="center">
-    [<a href="tutorial-watchdog-en.html">英文页面</a>]
-    </div>
-</div>
-
-<div id="manual">
-
-<!-- ================================================================================ -->
-
-<h1 id="thisis">关于本文档</h1>
-
-<p>在本教程中，我将讲解试用“看门狗”的简单方法。</p>
-<p>你需要的是两台装有 pgpool-II 的 Linux 测试环境以及一个 PostgreSQL 安装在这些相同机器或者其他机器。
-只需要一个后端（PostgreSQL）节点就够了。
-</p>
-<p>你可以在任何模式中使用基于内存的查询缓存：复制模式，主/备模式和原始模式。</p>
-
-<p>我使用 "osspc16" 作为活跃（Active）节点以及 "osspc20" 作为备用（Standby）节点。
-"Someserver" 表示其中一台。</p>
-
-<p><img src="watchdog.png" alt=""></p>
-
-<p class="top_link"><a href="#Top">返回顶部</a></p>
-
-<!-- ================================================================================ -->
-
-<h1 id="basic">基础配置</h1>
-
-<h2 id="basic_config">pgpool.conf</h2>
-
-<h3>同时在活跃节点和备用节点中配置</h3>
-<p>同时在活跃节点和备用节点中配置以下参数</p>
-
-<h4 id="basic_config_ebable">启用看门狗</h4>
-<p>首先，设置 "use_watchdog" 为 on 以启用看门狗。</p>
-<pre>use_watchdog = <b>on</b>
-                                    # Activates watchdog
-</pre>
-
-<h4 id="basic_config_upper">上游服务器</h4>
-<p>指定上游服务器（例如应用服务器）。留空就够了。</p>
-<pre>trusted_servers = ''
-                                    # trusted server list which are used
-                                    # to confirm network connection
-                                    # (hostA,hostB,hostC,...)
-</pre>
-
-<h4 id="basic_config_watchdog">看门狗</h4>
-<p>指定看门狗的端口</p>
-<pre>wd_port = 9000
-                                    # port number for watchdog service
-</pre>
-
-<h4 id="basic_config_vip">虚拟 IP</h4>
-<p>在 "delegate_IP" 中设置用于虚拟 IP 地址的 IP 地址，它不能被任何人使用。</p>
-<pre>delegate_IP = '<b>133.137.177.143</b>'
-                                    # delegate IP address
-</pre>
-
-<h3 id="basic_config_lifecheck">监控</h3>
-<p>下一步，为每个 pgpool 设置参数。</p>
-<p>指定 "other_pgpool_hostname0"，"other_pgpool_port0" 和 "other_wd_port0"，对应要监控的 pgpool 和看门狗。</p>
-<p>[*] other_pgpool_hostname0 必须是 hostname 命令返回的值。</p>
-
-<h4>活跃节点 (osspc16)</h4>
-<pre>other_pgpool_hostname0 = '<b>osspc20</b>'
-                                    # Host name or IP address to connect to for other pgpool 0
-other_pgpool_port0 = 9999
-                                    # Port number for othet pgpool 0
-other_wd_port0 = 9000
-                                    # Port number for othet watchdog 0
-</pre>
-
-<h4>备用节点 (osspc20)</h4>
-<pre>other_pgpool_hostname0 = '<b>osspc16</b>'
-                                    # Host name or IP address to connect to for other pgpool 0
-other_pgpool_port0 = 9999
-                                    # Port number for othet pgpool 0
-other_wd_port0 = 9000
-                                    # Port number for othet watchdog 0
-</pre>
-
-<!-- -------------------------------------------------------------------------------- -->
-
-<h2 id="basic_start">启动 pgpool</h2>
-
-<p>以 root 身份使用 "-n" 参数（表示以非守护进程模式）启动每个 pgpool-II 并重定向日志消息到 pgpool.log 中。
-
-<h3>启动活跃节点 (osspc16) 上的 pgpool</h3>
-<p>启动活跃节点上的 pgpool。</p>
-<pre>[user@osspc16]$ su -
-[root@osspc16]# {installed_dir}/bin/pgpool -n -f {installed_dir}/etc/pgpool.conf &gt; pgpool.log 2&gt;&amp;1
-</pre>
-
-<p>日志显示 pgpool 获得了虚拟 IP 并启动了看门狗进程。</p>
-<pre>ERROR: wd_create_send_socket: connect() is failed(Connection refused)
-LOG:   wd_escalation: eslcalated to master pgpool
-ERROR: wd_create_send_socket: connect() is failed(Connection refused)
-LOG:   wd_escalation:  <b>escaleted to delegate_IP holder</b>
-LOG:   wd_init: <b>start watchdog</b>
-LOG:   pgpool-II successfully started. version 3.2beta1 (namameboshi)
-</pre>
-
-<h3>启动备用节点 (osspc20) 上的 pgpool</h3>
-<p>启动备用节点上的 pgpool。</p>
-<pre>[user@osspc20]$ su -
-[root@osspc20]# {installed_dir}/bin/pgpool -n -f {installed_dir}/etc/pgpool.conf &gt; pgpool.log 2&gt;&amp;1
-</pre>
-
-<p>当 other_pgpool_hostname 列出的所有看门狗已经启动，存活检测启动。
-在本例中，osspc16 是除了本节点之外的唯一的其他看门狗，因此存活检测已经启动了。</p>
-<pre>LOG:   wd_init: start watchdog
-LOG:   pgpool-II successfully started. version 3.2beta1 (namameboshi)
-LOG:   watchdog: <b>lifecheck started</b>
-</pre>
-
-<p>在活跃节点中，存活检测也启动了。</p>
-<pre>LOG:   watchdog: <b>lifecheck started</b>
-</pre>
-
-<p class="top_link"><a href="#Top">返回顶部</a></p>
-
-<!-- ================================================================================ -->
-
-<h1 id="try">试用</h1>
-
-<h2 id="try_vip">连接到虚拟 IP</h2>
-<p>通过 ping 确认虚拟 IP 地址。</p>
-<pre>[user@someserver]$ ping 133.137.177.142
-PING 133.137.177.143 (133.137.177.143) 56(84) bytes of data.
-64 bytes from 133.137.177.143: icmp_seq=1 ttl=64 time=0.328 ms
-64 bytes from 133.137.177.143: icmp_seq=2 ttl=64 time=0.264 ms
-64 bytes from 133.137.177.143: icmp_seq=3 ttl=64 time=0.412 ms
-</pre>
-
-<p>确定首先启动的活跃节点获得了虚拟 IP 地址。</p>
-<pre>[root@osspc16]# ifconfig
-eth0      ...
-
-<b>eth0:0</b>    inet addr:133.137.177.143 ...
-
-lo        ...
-</pre>
-
-<p>确定不是最先启动的备用节点没有获得虚拟 IP 地址。</p>
-<pre>[root@osspc20]# ifconfig
-eth0      ...
-
-lo        ...
-</pre>
-
-<p>尝试使用 "psql -h delegate_IP -p port" 连接到 PostgreSQL。</p>
-<pre>[user@someserver]$ psql -h 133.137.177.142 -p 9999 -l
-</pre>
-
-<!-- -------------------------------------------------------------------------------- -->
-
-<h2 id="try_switch">切换虚拟 IP</h2>
-
-<p>确认在活跃节点无法提供服务的时候别用节点是如何工作的。</p>
-
-<p>停止在活跃节点上的 pgpool。</p>
-<pre>[root@osspc16]# {installed_dir}/bin/pgpool stop
-</pre>
-
-<p>然后，备用服务器开始使用虚拟 IP。日志显示：</p>
-<pre>LOG:   wd_escalation: <b>eslcalated to master pgpool</b>
-ERROR: wd_create_send_socket: connect() is failed(Connection refused)
-LOG:   wd_escalation:  escaleted to delegate_IP holder
-</pre>
-
-<p>通过 ping 这个 IP 地址以确认。</p>
-<pre>[user@someserver]$ ping 133.137.177.142
-PING 133.137.177.143 (133.137.177.143) 56(84) bytes of data.
-64 bytes from 133.137.177.143: icmp_seq=1 ttl=64 time=0.328 ms
-64 bytes from 133.137.177.143: icmp_seq=2 ttl=64 time=0.264 ms
-64 bytes from 133.137.177.143: icmp_seq=3 ttl=64 time=0.412 ms
-</pre>
-
-<p>确认原来活跃的服务器不在使用虚拟 IP 地址。</p>
-<pre>[root@osspc16]# ifconfig
-eth0      ...
-
-lo        ...
-</pre>
-
-<p>确认原来的备用节点使用了虚拟 IP 地址。</p>
-<pre>[root@osspc20]# ifconfig
-eth0      ...
-
-<b>eth0:0</b>    inet addr:133.137.177.143 ...
-
-lo        ...
-</pre>
-
-<p>尝试使用 "psql -h delegate_IP -p port" 连接到 PostgreSQL。</p>
-<pre>[user@someserver]$ psql -h 133.137.177.142 -p 9999 -l
-</pre>
-
-<p class="top_link"><a href="#Top">返回顶部</a></p>
-
-<!-- ================================================================================ -->
-
-<h1 id="more">更多内容</h1>
-
-<h2 id="more_lifecheck">存活检测（Lifecheck）</h2>
-
-<p>以下为一些用于看门狗的监控的参数。</p>
-
-<p>指定检测周期 "wd_interval"，重试次数 "wd_life_point" 以及检测用的查询语句 "wd_lifecheck_query"。</p>
-<pre>wd_interval = 10
-                                    # lifecheck interval (sec) &gt; 0
-wd_life_point = 3
-                                    # lifecheck retry times
-wd_lifecheck_query = 'SELECT 1'
-                                    # lifecheck query to pgpool from watchdog
-</pre>
-
-<!-- -------------------------------------------------------------------------------- -->
-
-<h2 id="more_switch">切换虚拟 IP 地址</h2>
-
-<p>以下为一些用于切换虚拟 IP 地址的参数。</p>
-
-<p>指定切换命令 "if_up_cmd" 和 "if_down_cmd" 以及到这些命令的路径 "ifconfig_path"，
-以及在发生切换后发送 ARP 请求的命令 "arping_cmd" 以及到这个命令的路径 "arping_path"。</p>
-
-<pre>ifconfig_path = '/sbin'
-                                    # ifconfig command path
-if_up_cmd = 'ifconfig eth0:0 inet $_IP_$ netmask 255.255.255.0'
-                                    # startup delegate IP command
-if_down_cmd = 'ifconfig eth0:0 down'
-                                    # shutdown delegate IP command
-
-arping_path = '/usr/sbin'           # arping command path
-
-arping_cmd = 'arping -U $_IP_$ -w 1'
-</pre>
-
-<p class="top_link"><a href="#Top">返回顶部</a></p>
-
-</div>
-
-<!-- ================================================================================ -->
-
-<div class="copyright" style="clear: both">
-<hr>
-<copyright>
-Copyright © 2003 – 2012 pgpool Global Development Group
-</copyright>
-</div>
-
-
-
-</body></html>
diff --git a/doc/tutorial-zh_cn.html b/doc/tutorial-zh_cn.html
deleted file mode 100644
index 9883dbe26..000000000
--- a/doc/tutorial-zh_cn.html
+++ /dev/null
@@ -1,537 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
-
-<html>
-
-<head>
-<title>pgpool-II 入门教程</title>
-<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
-<link href="pgpool.css" rel="stylesheet" type="text/css" />
-</head>
-
-<body>
-<h1>pgpool-II 入门教程</h1>
-<p>欢迎阅读 pgpool-II 入门教程。从本教程中，你将学会如何安装，设置 pgpool-II 以及使用 pgpool-II 运行并行查询和复制。我们假设你已经知道PostgreSQL的基础操作，所以如果有必要，请先参考 PostgreSQL 的文档。</p>
-
-<dl>
-  <dt><em>目录</em></dt>
-  <dt>1. <a href="#start">让我们开始吧！</a></dt>
-  <dd>1.1. <a href="#install">安装 pgpool-II</a></dd>
-  <dd>1.2. <a href="#config">配置文件</a></dd>
-  <dd>1.3. <a href="#pcp-config">配置 PCP 命令</a></dd>
-  <dd>1.4. <a href="#db-node">准备数据库节点</a></dd>
-  <dd>1.5. <a href="#start-shutdown">启动/停止 pgpool-II</a></dd>
-  <dt>2. <a href="#replication">你的第一个复制</a></dt>
-  <dd>2.1. <a href="#replication-config">配置复制</a></dd>
-  <dd>2.2. <a href="#replication-check">检查复制</a></dd>
-  <dt>3. <a href="#parallel">你的第一个并行查询</a></dt>
-  <dd>3.1. <a href="#parallel-config">配置并行查询</a></dd>
-  <dd>3.2. <a href="#system-db">配置系统数据库</a></dd>
-  <dd>3.3. <a href="#dist-def">定义分发规则</a></dd>
-  <dd>3.4. <a href="#replicate-def">定义复制规则</a></dd>
-  <dd>3.5. <a href="#parallel-check">检查并行查询</a></dd>
-</dl>
-
-
-<h2>1. <a name="start">让我们开始吧！</a></h2>
-
-<p>首先，在使用复制和并行查询前，我们必须学习如何安装、配置 pgpool-II 和数据库节点。</p>
-
-<h3>1.1. <a name="install">安装 pgpool-II</a></h3>
-
-<p>安装 pgpool-II 非常简单。在你解压源码 tar 包的目录中，执行以下命令。</p>
-
-<pre>
-$ ./configure
-$ make
-$ make install
-</pre>
-
-<p><code>configure</code> 脚本收集你的系统信息并用于编译过程。你可以通过传递命令行参数到 <code>configure</code> 脚本来改变它的默认行为，例如安装目录。默认情况下，pgpool-II将安装到 <code>/usr/local</code> 目录。</p>
-
-<p><code>make</code> 命令编译源码，<code>make install</code> 命令将安装执行文件。你必须对安装目录有写入权限。</p>
-
-<p>在本教材中，我们将安装 pgpool-II 到默认的 <code>/usr/local</code> 目录中。</p>
-
-<p><em>注</em>: pgpool-II 需要 PostgreSQL 7.4 或更高版本（版本 3 的协议）的 libpq 。如果 <code>configure</code> 脚本显示以下的错误信息，则可能是 libpq 库没有被安装或者它不是版本 3 的。</p>
-
-<pre>configure: error: libpq is not installed or libpq is old</pre>
-
-<p>如果是版本 3 的库，但还是显示了以上消息，则你的 libpq 库可能无法被 <code>configure</code> 脚本识别。</p>
-
-<p><code>configure</code> 脚本会在 <code>/usr/local/pgsql</code> 目录搜索 libpq 库。如果你安装 PostgreSQL 到 <code>/usr/local/pgsql</code> 之外的其他目录，在执行 <code>configure</code> 时，请使用 <code>--with-pgsql</code> ，或者同时使用 <code>--with-pgsql-includedir</code> 和 <code>--with-pgsql-libdir</code> 的命令行选项。</p>
-
-<h3>1.2. <a name="config">配置文件</a></h3>
-
-<p>pgpool-II 的配置参数保存在 <code>pgpool.conf</code> 文件中。文件以每行 “<code>parameter = value</code>” 的格式保存。当你安装 pgpool-II 后， <code>pgpool.conf.sample</code> 被自动建立。我们建议拷贝或者重命名它为 <code>pgpool.conf</code> ，然后你可以随意编辑它。</p>
-
-<pre>$ cp /usr/local/etc/pgpool.conf.sample /usr/local/etc/pgpool.conf</pre>
-
-<p>pgpool-II 默认只接受到 9999 端口的本地连接。如果你希望从其他主机接受连接，请设置 <code>listen_addresses</code> 为 '*'.</code></p>
-
-<pre>
-listen_addresses = 'localhost'
-port = 9999
-</pre>
-
-<p>在本教程中我们将使用默认参数。</p>
-
-<h3>1.3. <a name="pcp-config">配置 PCP 命令</a></h3>
-
-<p>pgpool-II 有一个用于管理功能的接口，用于通过网络获取数据库节点信息、关闭 pgpool-II 等。要使用 PCP 命令，必须进行用户认证。这种认证和 PostgreSQL 的用户认证不同。这需要在 <code>pcp.conf<code> 文件中定义一个用户和密码。在这个文件中，一个用户名和密码成对地出现在每一行中，它们用冒号（:）隔开。密码为用 md5 哈希加密的格式。</p>
-
-<pre>postgres:e8a48653851e28c69d0506508fb27fc5</pre>
-<p>在你安装 pgpool-II时， <code>pcp.conf.sample</code> 被自动建立。我们建议复制一份并重命名为 <code>pcp.conf</code> 并且编辑它。</p>
-<pre>$ cp /usr/local/etc/pcp.conf.sample /usr/local/etc/pcp.conf</pre>
-
-<p>为了加密你的密码为 md5 哈希格式，请使用 pg_md5 命令，它作为 pgpool-II 执行文件套件的一部分被安装。<code>pg_md5</code> 使用一个命令行参数，并显示它的 md5 哈希文本。</p>
-
-<p>例如，使用 “postgres” 作为命令行参数，<code>pg_md5</code> 会显示 md5 哈希的文本到标准输出。</p>
-
-<pre>
-$ /usr/bin/pg_md5 postgres
-e8a48653851e28c69d0506508fb27fc5
-</pre>
-
-<p>PCP 命令通过网络执行，所以必须在 <code>pgpool.conf</code> 文件中配置 <code>pcp_port</code> 端口。</p>
-
-<p>在本教程中，我们将使用默认的 9898 作为 <code>pcp_port</code> 的参数。</p>
-
-<pre>pcp_port = 9898</pre>
-
-<h3>1.4. <a name="db-node">准备数据库节点</a></h3>
-
-<p>现在，我们需要设置用于 pgpool-II 的后台 PostgreSQL 服务器了。这些服务器可以与 pgpool-II 在同一台主机上，也可以在独立的主机上。如果你决定将所有服务器都放在同一台主机上，必须为每个服务分配不同的端口。如果服务器被安置在不同的机器上，他们必须被正确以便可以通过网络接受 pgpool-II 的连接。</p>
-
-<p>在本教程中，我们将三台服务器放在与 pgpool-II 相同的机器上，分别给它们分配端口号 5432，5433，5434。要配置 pgpool-II，请如下编辑 <code>pgpool.conf</code>。<pre>
-backend_hostname0 = 'localhost'
-backend_port0 = 5432
-backend_weight0 = 1
-backend_hostname1 = 'localhost'
-backend_port1 = 5433
-backend_weight1 = 1
-backend_hostname2 = 'localhost'
-backend_port2 = 5434
-backend_weight2 = 1
-</pre>
-
-<p>
-分别为 <code>backend_hostname</code>，<code>backend_port</code>，<code>backend_weight</code> 设置节点的主机名，端口号和负载均衡系数。在每个参数串的后面，必须通过添加从0开始（例如 0，1，2，&hellip;）的整数来指出节点编号。
-</p>
-
-<p><code>backend_weight</code> 参数都为 1 ，这意味着 SELECT 查询被平均分配到三台服务器上。</p>
-
-<h3>1.5. <a name="start-shutdown">启动/停止 pgpool-II</a></h3>
-
-<p>要启动 pgpool-II，在终端中执行以下命令。</p>
-
-<pre>$ pgpool</pre>
-
-<p>
-然而，以上的命令不打印日志信息，因为 pgpool 脱离终端了。如果你想显示 pgpool 日志信息，你需要传递 <code>-n</code> 到 pgpool 命令。此时 pgpool-II 作为非守护进程模式运行，也就不会脱离终端了。
-</p>
-
-<pre>
-$ pgpool -n &
-</pre>
-
-<p>日志消息会打印到终端，所以推荐使用如下的选项。</p>
-
-<pre>$ pgpool -n -d &gt; /tmp/pgpool.log 2&gt;&1 &</pre>
-
-<p><code>-d</code> 选项启用调试信息生成。</p>
-
-<p>
-以上命令持续追加日志消息到 <code>/tmp/pgpool.log</code> 中。如果你需要切换日志文件，可以将日志传递到一个支持日志轮换功能的外部命令。例如，你可以使用 Apache2 带的 rotatelogs 工具。
-</p>
-
-<pre>
-$ pgpool -n 2>&1 | /usr/local/apache2/bin/rotatelogs \
-  -l -f /var/log/pgpool/pgpool.log.%A 86400 &
-</pre>
-<p>这将生成名称类似于 “<code>pgpool.log.Thursday</code>” 的日志文件，然后在每天午夜 00:00 轮换日志文件。如果日志文件已经存在，rotatelogs 将追加日志到这个文件中。如果想在轮换前删除旧日志文件，你可以使用 cron：</p>
-<pre>
-55 23 * * * /usr/bin/find /var/log/pgpool -type f -mtime +5 -exec /bin/rm -f '{}' \;
-</pre>
-<p>
-请注意 rotatelogs 在某些发行版中可能存在于 <code> /usr/sbin/rotatelogs2 </code> 。-f 选项让 rotatelogs 在启动的时候生成一个日志文件，这个功能随 apache 2.2.9 或更高版本提供。
-</p>
-
-<p> 
-而且 <a href="http://www.cronolog.org"><code>cronolog</code></a> 对你可能有用。
-</p>
-
-<pre>
-$ pgpool -n 2>&1 | /usr/sbin/cronolog \
-  --hardlink=/var/log/pgsql/pgpool.log \
-  '/var/log/pgsql/%Y-%m-%d-pgpool.log' &
-</pre>
-
-<p>要停止 pgpool-II 进程，执行以下的命令。</p>
-
-<pre>$ pgpool stop</pre>
-
-<p>
-如果还有客户端连接着， pgpool-II 等待它们断开连接，然后才结束运行。如果你想强制关闭 pgpool-II ，执行以下的命令来代替之前的命令。
-</p>
-
-<pre>$ pgpool -m fast stop</pre>
-
-<h2>2. <a name="replication">你的第一个复制</a></h2>
-
-<p>复制可以让相同的数据拷贝到多个数据库节点。</p>
-
-<p>
-在本节中，我们将使用三个已经在“1. <a href="#start">让我们开始吧！</a>”小节中设置好了的数据库节点，一步步建立数据库复制系统。用于复制的示例数据将由 pgbench 基准测试程序生成。
-</p>
-
-<h3>2.1. <a name="replication-config">配置复制</a></h3>
-
-<p>要启用数据库复制功能，需要设置 <code>pgpool.conf</code> 文件中的 <code>replication_mode</code> 为 true 。</p>
-
-<pre>replication_mode = true</pre>
-
-<p>当 <code>replication_mode</code> 被设置为 true，pgpool-II 将发送一份接收到的查询的拷贝到所有的数据库节点。</p>
-
-<p>当 <code>load_balance_mode</code> 被设置为 true，pgpool-II 将在数据库节点之间分发 SELECT 查询。</p>
-
-<pre>load_balance_mode = true</pre>
-
-<p>在本章中，我们将同时启用 <code>replication_mode</code> 和 <code>load_balance_mode</code> 。</p>
-
-<h3>2.2. <a name="replication-check">检查复制</a></h3>
-
-<p>要使 <code>pgpool.conf</code> 中的改动生效，必须重启 pgpool-II 。请参考“1.5 <a href="#start-shutdown">启动/停止 pgpool-II</a>”小节。</p>
-
-<p>在配置完 <code>pgpool.conf</code> 且重新启动 pgpool-II 后，让我们试试复制，检查它是否工作正常。</p>
-
-<p>首先，我们需要建立一个用于复制的数据库。我们将给它命名为“bench_replication”。这个数据库需要被建立在所有的节点中。在 pgpool-II 中使用 <code>createdb</code> 命令，数据库将被在所有节点中建立。</p>
-
-<pre>$ createdb -p 9999 bench_replication</pre>
-
-<p>然后，使用 <code>-i</code> 选项执行 pgbench。<code>-i</code> 使用预设的表和数据初始化这个数据库。</p>
-
-<pre>$ pgbench -i -p 9999 bench_replication</pre>
-
-<p>下表是通过 <code>pgbench -i</code> 建立的表和数据的摘要。如果在所有的节点中，列出的表和数据都被建立了，则说明复制运行正常。</p>
-
-<table border="1" align="center">
-<tr>
-<th>表名</th>
-<th>行数</th>
-</tr>
-<tr>
-<td>branches</td>
-<td>1</td>
-</tr>
-<tr>
-<td>tellers</td>
-<td>10</td>
-</tr>
-<tr>
-<td>accounts</td>
-<td>100000</td>
-</tr>
-<tr>
-<td>history</td>
-<td>0</td>
-</tr>
-</table>
-
-<p>让我们使用一个简单的 shell 脚本在所有节点中检查以上内容。以下脚本将显示所有的节点中 branches，tellers，accounts 和 history 表的行数。</p>
-
-<pre>$ for port in 5432 5433 5434; do
-&gt;     echo $port
-&gt;     for table_name in branches tellers accounts history; do
-&gt;         echo $table_name
-&gt;         psql -c &quot;SELECT count(*) FROM $table_name&quot; -p $port bench_replication
-&gt;     done
-&gt; done
-</pre>
-
-<h2>3. <a name="parallel">你的第一个并行查询</a></h2>
-<p>
-在并行查询中，不同范围的数据存储在两个或更多数据库节点中。这叫做分区。而且，即使在并行查询模式中，你也可以在数据库节点之间对一些表进行复制。
-</p>
-
-<p>为了在 pgpool-II 中启用并行查询，你必须设置另一个叫做“系统数据库”的数据库（本系统数据库为 pgpool-II 使用的用于存放信息的数据库）。</p>
-
-<p>系统数据库包含用户定义的用来确定数据将包含到哪个数据库中的规则。另一个系统数据库的用途是使用 dblink 将从数据库节点发回的数据合并。</p>
-
-<p>
-在本章，我们将使用我们在“1. <a href="#start">让我们开始吧！</a>”小节中设置好的三个数据库节点，并带领你一步步建立一个并行查询数据库系统。我们同样会再次使用 pgbench 来创建示例数据。
-</p>
-
-<h3>3.1. <a name="parallel-config">配置并行查询</a></h3>
-
-<p>要启用并行查询功能，请设置 <code>pgpool.conf</code> 文件中的<code>parallel_mode</code> 为 true 。</p>
-
-<pre>parallel_mode = true</pre>
-
-<p>仅仅设置 <code>paralle_mode</code> 为 true 不会自动启动并行查询。pgpool-II 需要系统数据库和用于分发数据到数据库节点的规则。</p>
-
-<p>而且，系统数据库使用的 dblink 需要连接到 pgpool-II。因此，需要设置 <code>listen_addresses</code> 以便 pgpool-II 接受这些连接。</p>
-
-<pre>listen_addresses = '*'</pre>
-
-<p>
-注意：进行了分区的表不会进行复制，不过并行查询和复制可以同时生效。
-</p>
-
-<p>
-注意：你可以同时拥有分区表和复制表。但是一个表不能同时被分区和复制。因为分区表和复制表的结构不同，“2. <a href="#replication">你的第一个复制</a>”小节中建立的“bench_replication”数据库无法用于并行查询模式。
-</p>
-
-<pre>
-replication_mode = true
-load_balance_mode = false
-</pre>
-<p>
-或者
-</p>
-<pre>
-replication_mode = false
-load_balance_mode = true
-</pre>
-
-<p>在本小节，我们将设置 <code>parallel_mode</code> 和 <code>load_balance_mode</code> 为 true，<code>listen_addresses</code> 为 '*'，<code>replication_mode</code>为 false 。</p>
-
-<h3>3.2. <a name="system-db">配置系统数据库</a></h3>
-
-<p>
-“系统数据库”实际上就是一个普通的数据库。只是必须在系统数据库中安装 dblink 函数和用于描述分区规则的 dist_def 表。你可以让系统数据库存放于某个数据库节点中，也可以通过级联的方式配置 pgpool-II，让多个数据库节点拥有系统数据库。
-</p>
-
-<p>在本小节，我们将在 5432 端口的节点建立 SystemDB。以下列出了系统数据库的配置参数。</p>
-
-<pre>
-system_db_hostname = 'localhost'
-system_db_port = 5432
-system_db_dbname = 'pgpool'
-system_db_schema = 'pgpool_catalog'
-system_db_user = 'pgpool'
-system_db_password = ''
-</pre>
-
-<p>实际上，以上为 <code>pgpool.conf</code> 的默认设置。现在，我们必须建立一个叫做“pgpool”的用户，并建立一个属主为“pgpool”的名为“pgpool”的数据库。</p>
-
-<pre>
-$ createuser -p 5432 pgpool
-$ createdb -p 5432 -O pgpool pgpool
-</pre>
-
-<h4><p>3.2.1. 安装 dblink</p></h4>
-
-<p>然后，我们必须在“pgpool”数据库中安装 dblink。dblink 是包含在 PostgreSQL 源码包 <code>contrib</code> 目录中包含的一个工具。</p>
-
-<p>要在你的系统中安装 dblink，请执行以下命令。</p>
-
-<pre>
-$ USE_PGXS=1 make -C contrib/dblink
-$ USE_PGXS=1 make -C contrib/dblink install
-</pre>
-
-<p>在 dblink 被安装到你的系统中后，我们将在“pgpool”数据库中定义 dblink 函数。如果 PostgreSQL 被安装到 <code>/usr/local/pgsql</code>，<code>dblink.sql</code>（一个包含函数定义的文件）应该被安装到了 <code>/usr/local/pgsql/share/contrib</code>。那么，执行以下的命令来定义 dblink 函数。</p>
-
-<pre>$ psql -f /usr/local/pgsql/share/contrib/dblink.sql -p 5432 pgpool</pre>
-
-<h4><p>3.2.2. 定义 dist_def 表</p></h4>
-
-<p>
-在数据库“pgpool”中定义一个“dist_def”表，用于保存分区规则。在 pgpool-II 安装后，你会得到一个 <code>system_db.sql</code>，它是一个可用于生成系统数据库的 <code>psql</code> 脚本。
-</p>
-<pre>
-$ psql -f /usr/local/share/system_db.sql -p 5432 -U pgpool pgpool
-</pre>
-<p> dist_def 表被建立到 pgpool_catalog 这个 schema 中。如果你配置 <code>system_db_schema</code> 使用了其他的 schema，你需要相应地编辑 <code>system_db.sql</code>。</p>
-
-<p>“dist_def的定义如下，且表名不能被改变。</p>
-
-<pre>
-CREATE TABLE pgpool_catalog.dist_def (
-    dbname text, -- database name
-    schema_name text, -- schema name
-    table_name text, -- table name
-    col_name text NOT NULL CHECK (col_name = ANY (col_list)), -- distribution key-column
-    col_list text[] NOT NULL, -- list of column names
-    type_list text[] NOT NULL, -- list of column types
-    dist_def_func text NOT NULL, -- distribution function name
-    PRIMARY KEY (dbname, schema_name, table_name)
-);
-</pre>
-
-<p>“dist_def”中保存的 tuple 可以被分为两类。</p>
-
-<ul>
-<li>分发规则 (col_name, dist_def_func)</li>
-<li>表的元信息 (dbname, schema_name, table_name, col_list, type_list)</li>
-</ul>
-
-<p>
-分发规则确定如何分发数据到特定节点。数据将依赖“col_name”的值来进行分发。“dist_def_func”是一个函数，它使用“col_name”列的值做参数，返回一个指出数据将要存储的数据库节点 ID 的适当整数。
-</p>
-
-<p>元信息用于重写查询。并行查询必须重写查询比便让从后台节点返回的数据可以被合并为一个结果集。</p>
-
-<h4><p>3.2.2. 定义 replicate_def 表</p></h4>
-<p>
-如果你想在 SELECT 语句的并行模式中使用复制的表，你需要在一个叫做 replicate_def 的表中注册这些表的信息（复制规则）。replicate_def 表在定义 dist_def 表的时候已经由 system_db.sql 创建。replicate_def 表的定义如下。
-</p>
-<pre>
-CREATE TABLE pgpool_catalog.replicate_def (
-    dbname text, -- database name
-    schema_name text, -- schema name
-    table_name text, -- table name
-    col_list text[] NOT NULL, -- list of column names
-    type_list text[] NOT NULL, -- list of column types
-    PRIMARY KEY (dbname, schema_name, table_name)
-);
-</pre>
-<p>
-replicate_def 包含了表的元数据信息 (dbname, schema_name, table_name, col_list, type_list)。
-</p>
-<p>
-所有的查询分析和查询重写过程都依赖于存储于 dist_def 以及/或 replicate_def 表中的这些信息（表，列以及类型）。
-如果信息不正确，分析和查询重写过程将导致错误的结果。
-</p>
-
-<h3>3.3. <a name="dist-def">定义分发规则</a></h3>
-
-<p>
-在本教材中，我们将定义规则用于分发 pgbench 的示例数据到三个数据库节点中。示例数据将通过“<code>pgbench -i -s 3</code>”（例如比例因子为3）建立。在本小节，我们将建立一个叫“bench_parallel”的新数据库。
-</p>
-
-<p>
-在 pgpool-II 的源码中在，你可以在 <code>sample</code> 目录中找到 <code>dist_def_pgbench.sql</code> 文件。我们将使用这个示例文件来为 pgbench 建立分发规则。在解压后的 pgpool-II 的源码目录中执行以下命令。
-</p>
-
-<pre>$ psql -f sample/dist_def_pgbench.sql -p 5432 pgpool</pre>
-
-<p>以下为 <code>dist_def_pgbench.sql</code> 的说明。</p>
-
-<p>在 <code>dist_def_pgbench.sql</code>中，我们往“dist_def”表中插入一行。这里有一个为 accounts 表准备的分发函数。作为关键列，aid 被定义在每个 accounts 表中（也是主键）。</p>
-
-<pre>
-INSERT INTO pgpool_catalog.dist_def VALUES (
-    'bench_parallel',
-    'public',
-    'accounts',
-    'aid',
-    ARRAY['aid', 'bid', 'abalance', 'filler'],
-    ARRAY['integer', 'integer', 'integer', 'character(84)'],
-    'pgpool_catalog.dist_def_accounts'
-);
-</pre>
-
-<p>
-现在，我们必须为 accounts 表定义分发函数。注意你可以对不同的表使用相同的函数。而且，你可以使用 SQL 之外的语言定义函数（例如 PL/pgSQL，PL/Tcl 等等）。
-</p>
-
-<p>accounts 表在初始化时指定了比例因子为 3，aid 的值为 1 到 300000。函数被定义为使数据平均分布到三个数据库节点中。</p>
-
-<p>
-SQL 函数将定义为返回数据库节点的编号。</p>
-
-</p>
-<pre>CREATE OR REPLACE FUNCTION pgpool_catalog.dist_def_branches(anyelement)
-RETURNS integer AS $$
-    SELECT CASE WHEN $1 &gt; 0 AND $1 &lt;= 1 THEN 0
-        WHEN $1 &gt; 1 AND $1 &lt;= 2 THEN 1
-        ELSE 2
-    END;
-$$ LANGUAGE sql;
-</pre>
-
-<h3>3.4. <a name="replicate-def">定义复制规则</a></h3>
-<p>复制规则是定义某个表是否被复制的规则。</p>
-
-<p>
-以下表是 pgbench 生成的。branches 表和 tellers 表已经注册。作为结果，accounts 表和使用 branches 表和 tellers 表的查询已经可用。
-</p>
-<pre>
-INSERT INTO pgpool_catalog.replicate_def VALUES (
-    'bench_parallel',
-    'public',
-    'branches',
-    ARRAY['bid', 'bbalance', 'filler'],
-    ARRAY['integer', 'integer', 'character(88)']
-);
-
-INSERT INTO pgpool_catalog.replicate_def VALUES (
-    'bench_parallel',
-    'public',
-    'tellers',
-    ARRAY['tid', 'bid', 'tbalance', 'filler'],
-    ARRAY['integer', 'integer', 'integer', 'character(84)']
-);
-</pre>
-<p>
-在 sample 目录中已经准备好了 replicate_def_pgbench.sql 文件。在源码目录中使用以下方法来定义一个复制规则。执行以下 psql 命令。
-</p>
-
-<pre>
-$ psql -f sample/replicate_def_pgbench.sql -p 5432 pgpool
-</pre>
-
-<h3>3.5. <a name="parallel-check">检查并行查询</a></h3>
-
-<p>要使 <code>pgpool.conf</code> 中的改动生效，pgpool-II 必须重启。请参考“1.5 <a href="#start-shutdown">启动/停止 pgpool-II</a>”小节。</p>
-
-<p>在配置好 <code>pgpool.conf</code> 并重启 pgpool-II 后，让我们试试并查看并行查询是否运行正常。</p>
-
-<p>
-首先，我们需要建立一个用于分发的数据库。我们将给它命名为“bench_parallel”。这个数据库需要在所有节点上被建立。通过 pgpool-II 使用 <code>createdb</code> 命令，则数据库将被奖励在所有节点上。
-</p>
-
-<pre>$ createdb -p 9999 bench_parallel</pre>
-
-<p>然后，我们将使用 <code>-i -s 3</code> 选项执行 pgbench 。<code>-i</code> 选项使用预定义的表和数据初始化数据库。 <code>-s</code> 选项指出用于初始化的比例因子。</p>
-
-<pre>$ pgbench -i -s 3 -p 9999 bench_parallel</pre>
-
-<p>建立的表和数据在 “3.3. <a href="#dist-def">定义分发规则</a>”小节中列出来了。</p>
-
-<p>
-检查数据是否被正确分发的一个方法是通过 pgpool-II 和直接在后台节点执行一个 SELECT 查询，然后比较两个结果。如果所有都配置正确，“bench_parallel”应该按以下样子分布。
-</p>
-
-<table border="1" align ="center">
-<tr>
-<th >表名</th>
-<th >行数</th>
-</tr>
-<tr>
-		<td>branches</td>
-		<td>3</td>
-</tr>
-<tr>
-		<td>tellers</td>
-		<td>30</td>
-</tr>
-<tr>
-		<td>accounts</td>
-		<td>300000</td>
-</tr>
-<tr>
-		<td>history</td>
-		<td>0</td>
-</tr>
-</table>
-
-<p>
-让我们使用一段简单的 shell 脚本来在所有的节点上和通过 pgpool-II 检查以上的内容。以下脚本将使用 5432，5433,5434 和 9999 端口显示 accounts 表中最小和最大的值。
-</p>
-
-<pre>$ for port in 5432 5433 5434 9999; do
-&gt;     echo $port
-&gt;     psql -c &quot;SELECT min(aid), max(aid) FROM accounts&quot; -p $port bench_parallel
-&gt; done
-</pre>
-
-<div class="copyright">
-<hr>
-<copyright>
-Copyright &copy; 2003 &ndash; 2011 pgpool Global Development Group
-</copyright>
-</div>
-</body>
-</html>
diff --git a/doc/watchdog.png b/doc/watchdog.png
deleted file mode 100644
index b22bd1d6b..000000000
Binary files a/doc/watchdog.png and /dev/null differ
diff --git a/doc/wd-en.html b/doc/wd-en.html
deleted file mode 100644
index 1c017f8cc..000000000
--- a/doc/wd-en.html
+++ /dev/null
@@ -1,236 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<html>
-<head>
-<meta http-equiv="content-type" content="text/html;charset=utf8">
-<link rel="stylesheet" href="./pgpool-ja.css" type="text/css">
-<title>Watchdog Manual</title>
-</head>
-<body>
-<h1>What is Watchdog</h1>
-<p>
-	"watchdog" is a sub process of pgpool-II aiming for adding high availability feature to it.
-	Features added by watchdog include:
-
-	<ul>
-	<li>Life checking of pgpool service</li>
-	<p>
-	watchdog monitors responses of pgpool <i>service</i> rather than process.
-	It sends queries to PostgreSQL via pgpool which is being monitored
-	by watchdog and watchdog checks the response.
-	Also watchdog monitors connections to up stream servers
-	(application servers etc.) from the pgpool.
-	The connection between the up stream servers and the pgpool is monitored as service of pgpool.
-	</p>
-
-	<li>Mutual monitoring of watchdog processes</li>
-	<p>
-	watchdog processes exchange information on the monitored servers
-	to keep the information up to date,
-	and to allow watchdog processes to mutually monitor each other. 
-	</p>
-
-	<li>Changing active/standby state in case of certain faults detected</li>
-	<p>
-	When a fault is detected in the pgpool service, watchdog notifies the other watchdogs of it.
-	Watchdogs decide the new active pgpool if previous active pgpool is broken
-	by voting and change active/standby state.
-	</p>
-
-	<li>Automatic virtual IP address assigning synchronous to server switching</li>
-	<p>
-	When a standby pgpool server promotes to active, the new active server brings up virtual IP interface.
-	Meanwhile, the previous active server brings down the virtual IP interface.
-	This enables the active pgpool to work using the same IP address even when servers is switched over.
-	</p>
-
-	<li>Automatic registration of a server as standby in recovery</li>
-	<p>
-	When broken server recovers or new server is attached,
-	the watchdog process notifies the other watchdog process along with information of the new server,
-	and the watchdog process receives information on the active server and other servers.	
- 	Then, the attached server is registered as standby.
-	</p>
-	</ul>
-</p>
-<h2>Server composition</h2>
-
-<p>
-Figure below describes how pgpool-II and watchdog process is configured.
-</p>
-<table align=center width=800>
-<tr><td>
-<img src="wd-en.jpg" alt="watchdog server composition" hight=70% width=70%>
-</td></tr>
-</table>
-<h2>Starting/stopping watchdog</h2>
-<p>
-watchdog process is started/stopped automatically by pgpool-II,
-therefore there is no dedicated command to start/stop it.
-However, pgpool-II must to be started with <font color="red">root privilege</font>
-because watchdog process needs to control the virtual IP interface.
-</p>
-<h2>Configuring watchdog (pgpool.conf)</h2>
-<p>
-	watchdog configuration parameters is described in pgpool.conf.
-	There is sample configuration in WATCHDOG section in pgpool.conf.sample file.
-	All following options are required to be specified in watchdog process.
-</p>
-
-<h3>Basic configuration</h3>
-<dl>
-
-<dt><a name="USE_WATCHDOG"></a>use_watchdog</dt>
-<dd>
-<p>
-If on, activates watchdog. Default is off.
-</p>
-</dd>
-
-<dt><a name="TRUSTED_SERVERS"></a>trusted_servers</dt>
-<dd>
-<p>
-	The list of trusted servers to check the up stream connections.
-	Each server is required to respond to ping.
-	Specify a comma separated list of servers such as "hostA,hostB,hostC".
-</p>
-</dd>
-
-<dt><a name="DELEGATE_IP"></a>delegate_IP</dt>
-<dd>
-<p>
-	Specifies the virtual IP address (VIP) of pgpool-II that is connected from
-	client servers (application servers etc.).
-	When a pgpool is switched from standby to active, the pgpool takes over this VIP.
-</p>
-</dd>
-
-<dt><a name="WD_HOSTNAME"></a>wd_hostname</dt>
-<dd>
-<p>
-	Specifies the hostname or IP address for mutual monitoring of watchdog processes.
-</p>
-</dd>
-
-<dt><a name="WD_PORT"></a>wd_port</dt>
-<dd>
-<p>
-	Specifies the port number for mutual monitoring of watchdog processes.
-</p>
-</dd>
-
-<dt><a name="WD_INTERVAL"></a>wd_interval</dt>
-<dd>
-<p>
-    This parameter specifies the interval between life checks of pgpool-II
-	in second. 
-	(A number greater than or equal to 1)
-
-</p>
-</dd>
-
-<dt><a name="PING_PATH"></a>ping_path</dt>
-<dd>
-<p>
-	This parameter specifies a path of ping command for monitoring connection
-	to the upper servers.
-	Set the only path such as "/bin".
-</p>
-</dd>
-
-<dt><a name="IFCONFIG_PATH"></a>ifconfig_path</dt>
-<dd>
-<p>
-	This parameter specifies a path of a command to switch the IP address.
-	Set the only path such as "/sbin".
-</p>
-</dd>
-
-<dt><a name="IF_UP_CMD"></a>if_up_cmd</dt>
-<dd>
-<p>
-	This parameter specifies a command to bring up the virtual IP.
-	Set the command and parameters such as 
-	"ifconfig eth0:0 inet $_IP_$ netmask 255.255.255.0".
-	$_IP_$ is replaced by the IP address specified in delegate_IP.
-</p>
-</dd>
-
-<dt><a name="IF_DOWN_CMD"></a>if_down_cmd</dt>
-<dd>
-<p>
-	This parameter specifies a command to bring down the virtual IP.
-	Set the command and parameters such as 
-	"ifconfig eth0:0 down".
-</p>
-</dd>
-
-<dt><a name="ARPING_PATH"></a>arping_path</dt>
-<dd>
-<p>
-	This parameter specifies a path of a command to send an ARP request
-	after the virtual IP is switched.
-	Set the only path such as "/usr/sbin".
-</p>
-</dd>
-
-<dt><a name="ARPING_CMD"></a>arping_cmd</dt>
-<dd>
-<p>
-	This parameter specifies a command to send an ARP request
-	after the virtual IP is switched.
-	Set the command and parameters such as 
-	"arping -U $_IP_$ -w 1".
-	$_IP_$ is replaced by the IP address specified in delegate_IP.
-</p>
-</dd>
-
-<dt><a name="WD_LIFE_POINT"></a>wd_life_point</dt>
-<dd>
-<p>
-    The times to retry a failed life check of pgpool-II.
-	(A number greater than or equal to 1)
-
-</p>
-</dd>
-
-<dt><a name="WD_LIFECHECK_QUERY"></a>wd_lifecheck_query</dt>
-<dd>
-<p>
-    Actual query to check pgpool-II.
-	Default is "SELECT 1"
-</p>
-</dd>
-
-</dl>
-
-<h3>Servers to be monitored</h3>
-<dl>
-<dt><a name="OTHER_PGPOOL_HOSTNAME"></a>other_pgpool_hostname<font color="red">0</font></dt>
-<dd>
-<p>
-	Specifies the hostname pgpool-II server to be monitored.
-	The number at the end of the parameter name is referred as "server id",
-	and it starts from 0.
-</p>
-</dd>
-
-<dt><a name="OTHER_PGPOOL_PORT"></a>other_pgpool_port<font color="red">0</font></dt>
-<dd>
-<p>
-	Specifies the port number for pgpool on pgpool-II server to be monitored.
-	The number at the end of the parameter name is referred as "server id",
-	and it starts from 0.
-</p>
-</dd>
-
-<dt><a name="OTHER_WD_PORT"></a>other_wd_port<font color="red">0</font></dt>
-<dd>
-<p>
-	Specifies the port number for watchdog on pgpool-II server to be monitored.
-	The number at the end of the parameter name is referred as "server id",
-	and it starts from 0.
-</p>
-</dd>
-</dl>
-</body>
-</html>
diff --git a/doc/wd-en.jpg b/doc/wd-en.jpg
deleted file mode 100644
index 9fc05b258..000000000
Binary files a/doc/wd-en.jpg and /dev/null differ
diff --git a/doc/wd-ja.html b/doc/wd-ja.html
deleted file mode 100644
index 031b3b68c..000000000
--- a/doc/wd-ja.html
+++ /dev/null
@@ -1,219 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<html>
-<head>
-<meta http-equiv="content-type" content="text/html;charset=utf8">
-<link rel="stylesheet" href="./pgpool-ja.css" type="text/css">
-<title>Watchdogマニュアル</title>
-</head>
-<body>
-<h1>Watchdog</h1>
-<p>
-	watchdogプロセスはpgpool-II本体から起動される、高可用性を目的としたプロセスです。 以下の機能を提供します。
-	<ul>
-	<li>pgpoolサービスの生死監視</li>
-	<p>
-	watchdogはpgpoolのプロセスではなく、サービスの応答を監視します。
-	監視対象のpgpoolからPostgreSQLに問い合わせを行い、その応答をチェックします。
-	またwatchdogは、pgpoolから上位のサーバ（アプリケーションサーバなど）への接続も監視します。上位サーバからPostgreSQLへの接続・応答をpgpoolのサービスとして生死監視します。
-	</p>
-	<li>watchdogプロセスの相互監視</li>
-	<p>
-	各watchdogはお互いの監視対象のサーバの情報を交換します。
-	これにより、pgpoolサーバの情報を最新に保てるだけでなく、各watchdogプロセスの相互監視を行っています。
-	</p>
-	<li>障害発生検知時のアクティブ、スタンバイ切り替え</li>
-	<p>
-	pgpoolのサービスに障害を検知した場合、watchdogは他のwatchdogに障害検知を通知します。
-	故障したpgpoolがアクティブの場合、他のwatchdogは新しいアクティブを投票で決め、アクティブ・スタンバイの切り替えを行います。
-	</p>
-	<li>サーバ切り替えと連動した仮想IPアドレスの自動付け替え</li>
-	<p>
-	スタンバイが新しいアクティブに昇格する際、新アクティブ機のwatchdogはアクティブ用の仮想IPインターフェースを起動します。
-	一方、旧アクティブ機のwatchdogはアクティブ用仮想IPインターフェースを停止します。
-	これにより、サーバが切り替わった後もアクティブは同じIPアドレスでサービスを継続することができます。
-	
-	</p>
-	<li>サーバ復旧時、スタンバイ機としての自動登録</li>
-	<p>
-	障害機の復旧や新規サーバを追加する場合、watchdogはサーバの情報を他のwatchdogに通知し、他のwatchdogからはアクティブや他のサーバの情報を受け取ります。これにより追加したサーバはスタンバイ機として自動的に追加されます。
-	</p>
-	</ul>
-</p>
-<h2>サーバ構成</h2>
-<p>
-watchdogプロセスを含むpgpool-IIサーバは以下の図のようなシステム構成をとります。
-</p>
-<table align=center width=800>
-<tr><td>
-<img src="wd-ja.jpg" alt="watchdog server composition" hight=70% width=70%>
-</td></tr>
-</table>
-
-<h2>watchdogの起動と停止</h2>
-<p>
-watchdogプロセスはpgpool-IIから自動的に起動・停止されますので、固有の起動・停止コマンドはありません。
-しかし、watchdogプロセスは仮想IPインターフェースの起動・停止を行いますので、
-pgpool-IIの起動は
-<font color="red">
-root権限で
-</font>行う必要があります。
-</p>
-
-<h2>pgpool.confの設定</h2>
-<p>
-	watchdogプロセスの設定項目はpgpool.confに記述します。
-	pgpool.conf.sampleファイルのWATCHDOGセクションにサンプルを記述していますので、参照してください。
-	watchdogプロセスは以下の項目すべてを指定する必要があります。
-</p>
-
-<h3>基本設定セクション</h3>
-<dl>
-
-<dt><a name="USE_WATCHDOG"></a>use_watchdog</dt>
-<dd>
-<p>
-	watchdog を有効にするには on にします。デフォルトは off です。
-</p>
-</dd>
-
-<dt><a name="TRUSTED_SERVERS"></a>trusted_servers</dt>
-<dd>
-<p>
-	上位接続を確認するための信頼できるサーバリストです。
-	pingの応答が得られる必要があります。
-	hostA,hostB,hostC...のようにカンマで区切って複数のサーバを指定できます。
-</p>
-</dd>
-
-<dt><a name="DELEGATE_IP"></a>delegate_IP</dt>
-<dd>
-<p>
-	（アプリケーションサーバなど）外部からの接続されるpgpool-IIの仮想IPアドレスです。
-	スタンバイからアクティブに切り替わる際、pgpoolはこの仮想IPを引き継ぎます。
-</p>
-</dd>
-
-<dt><a name="WD_HOSTNAME"></a>wd_hostname</dt>
-<dd>
-<p>
-	watchdogプロセスが相互監視を受信する為のホスト名またはIPアドレスです。
-</p>
-</dd>
-
-<dt><a name="WD_PORT"></a>wd_port</dt>
-<dd>
-<p>
-	watchdogプロセスが相互監視を受信する為のポート番号です。
-</p>
-</dd>
-
-<dt><a name="WD_INTERVAL"></a>wd_interval</dt>
-<dd>
-<p>
-	pgpool-IIへの生存監視の間隔（秒）です。
-	(1以上の数値)
-</p>
-</dd>
-
-<dt><a name="PING_PATH"></a>ping_path</dt>
-<dd>
-<p>
-	上位サーバへの接続監視に利用するpingコマンドのパスです。
-	/bin　のようにパスだけを指定します。
-</p>
-</dd>
-
-<dt><a name="IFCONFIG_PATH"></a>ifconfig_path</dt>
-<dd>
-<p>
-	IPアドレス切り替えに利用するコマンドのパスです。
-	/sbin　のようにパスだけを指定します。
-</p>
-</dd>
-
-<dt><a name="IF_UP_CMD"></a>if_up_cmd</dt>
-<dd>
-<p>
-	仮想IPを起動するために実行するコマンドです。
-	ifconfig eth0:0 inet $_IP_$ netmask 255.255.255.0
-	のようにコマンドとパラメータを指定します。
-	$_IP_$　はdelegate_IPで指定されたIPアドレスに置換されます。
-</p>
-</dd>
-
-<dt><a name="IF_DOWN_CMD"></a>if_down_cmd</dt>
-<dd>
-<p>
-	仮想IPを停止するために実行するコマンドです。
-	ifconfig eth0:0 down
-	のようにコマンドとパラメータを指定します。
-</p>
-</dd>
-
-<dt><a name="ARPING_PATH"></a>arping_path</dt>
-<dd>
-<p>
-	IPアドレス切り替え後にARPリクエストを送信するコマンドのパスです。
-	/usr/sbin　のようにパスだけを指定します。
-</p>
-</dd>
-
-<dt><a name="ARPING_CMD"></a>arping_cmd</dt>
-<dd>
-<p>
-	IPアドレス切り替え後にARPリクエストを送信するコマンドです。
-	arping -U $_IP_$ -w 1
-	のようにコマンドとパラメータを指定します。
-	$_IP_$　はdelegate_IPで指定されたIPアドレスに置換されます。
-</p>
-</dd>
-
-<dt><a name="WD_LIFE_POINT"></a>wd_life_point</dt>
-<dd>
-<p>
-	pgpool-IIの生死監視で応答が得られなかった場合のリトライ回数です。
-	(1以上の数値)
-</p>
-</dd>
-</dl>
-
-<dt><a name="WD_LIFECHECK_QUERY"></a>wd_lifecheck_query</dt>
-<dd>
-<p>
-	pgpool-II の死活監視のために発行されるクエリです。
-	デフォルトは "SELECT 1" です。
-</p>
-</dd>
-
-<h3>監視対象サーバ指定セクション</h3>
-<dl>
-<dt><a name="OTHER_PGPOOL_HOSTNAME"></a>other_pgpool_hostname<font color="red">0</font></dt>
-<dd>
-<p>
-	監視対象のpgpool-IIサーバのホスト名を指定します。	
-	数値の部分は監視対象サーバの番号です。
-	監視対象のサーバ毎に０からの連番にします。
-</p>
-</dd>
-
-<dt><a name="OTHER_PGPOOL_PORT"></a>other_pgpool_port<font color="red">0</font></dt>
-<dd>
-<p>
-	監視対象のpgpool-IIサーバのpgpool用のポート番号を指定します。	
-	数値の部分は監視対象サーバの番号です。
-	監視対象のサーバ毎に０からの連番にします。
-</p>
-</dd>
-
-<dt><a name="OTHER_WD_PORT"></a>other_wd_port<font color="red">0</font></dt>
-<dd>
-<p>
-	監視対象のpgpool-IIサーバのwatchdog用のポート番号を指定します。	
-	数値の部分は監視対象サーバの番号です。
-	監視対象のサーバ毎に０からの連番にします。
-</p>
-</dd>
-</dl>
-
-</body>
-</html>
diff --git a/doc/wd-ja.jpg b/doc/wd-ja.jpg
deleted file mode 100644
index 4616da158..000000000
Binary files a/doc/wd-ja.jpg and /dev/null differ
diff --git a/doc/wd-zh_cn.html b/doc/wd-zh_cn.html
deleted file mode 100644
index 8622b1af8..000000000
--- a/doc/wd-zh_cn.html
+++ /dev/null
@@ -1,201 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<html>
-<head>
-<meta http-equiv="content-type" content="text/html;charset=gbk">
-<link rel="stylesheet" href="./pgpool-ja.css" type="text/css">
-<title>���Ź��ֲ�</title>
-</head>
-<body>
-<h1>ʲô�ǿ��Ź�</h1>
-<p>
-  �����Ź�����һ�� pgpool-II ���ӽ��̣�����Ϊ pgpool-II ���Ӹ߿����Թ��ܡ����Ź����ӵĹ��ܰ�����
-
-	<ul>
-	<li>pgpool ����Ĵ����</li>
-	<p>
-	���Ź���� pgpool ��<i>����</i>�����ǽ��̡���ͨ�������Ź���ص� pgpool ���Ͳ�ѯ�� PostgreSQL �������Ӧ��
-	���ҿ��Ź���ش� pgpool �����η�������Ӧ�÷������ȣ�����·��
-	�����η������� pgpool ֮������ӱ��� pgpool �ķ���ķ�ʽ���м�ء�
-	</p>
-
-	<li>���Ź����̼��໥���</li>
-	<p>
-	���Ź����̽�������ط������ϵ���Ϣ��Ϣ�Ա�֤��Ϣ�����µģ����������Ź������໥��ضԷ���
-	</p>
-
-	<li>��ĳЩ���ϱ���⵽������¸ı��Ծ/����״̬</li>
-	<p>
-	�� pgpool ������̽�⵽���ϣ����Ź�����������֪ͨ���������Ź���
-	���Ź���ȷ�ϾɵĻ�Ծ�� pgpool �޷��ṩ����ʱ��ͨ��ͶƱȷ���µ� pgpool ��Ծ�ڵ㣬���ı��Ծ/����״̬��
-	</p>
-
-	<li>�ڷ����л���ʱ��ͬ��ʵ������ IP ��ַ����</li>
-	<p>
-	��һ�����õ� pgpool ��������Ϊ��Ծ״̬���µĻ�Ծ�������������� IP �ӿڡ�
-	Ҳ���ǣ�֮ǰ��Ծ�ķ�����ͣ������ IP �ӿڡ�
-	���û�Ծ�� pgpool ʹ����ͬ�� IP ��ַ����ʹ���ڷ����������л���ʱ��
-	</p>
-
-	<li>�ڻָ����Զ�ע�����Ϊ����״̬</li>
-	<p>
-	�����ϵķ������ָ����µķ����������룬���Ź�����ͬʱ��֪ͨ�����Ŀ��Ź����̹����·���������Ϣ��
-	���ڻ�Ծ�������Լ������������ϵĿ��Ź����̻������Щ��Ϣ��Ȼ���¼���ķ������ᱻע��Ϊ���ýڵ㡣
-	</p>
-	</ul>
-</p>
-<h2>�������ṹͼ</h2>
-
-<p>
-��ͼ������ pgpool-II �Ϳ��Ź����̵����������
-</p>
-<table align=center width=800>
-<tr><td>
-<img src="wd-en.jpg" alt="watchdog server composition" hight=70% width=70%>
-</td></tr>
-</table>
-<h2>����/ֹͣ���Ź�</h2>
-<p>
-���Ź������� pgpool-II һ����ͣ��Ҳ����˵��û�е�����������ͣ����
-Ȼ����pgpool-II ������ <font color="red">root Ȩ��</font>��������Ϊ���Ź�������Ҫ�������� IP �ӿڡ�
-</p>
-<h2>���ÿ��Ź� (pgpool.conf)</h2>
-<p>
-	���Ź������ò���Ҳ�� pgpool.conf �С��� pgpool.conf.sample �ļ��е� WATCHDOG С����ʾ�����á�
-	�������е�ѡ������ÿ��Ź���������Ҫ�ġ�
-</p>
-
-<h3>��������</h3>
-<dl>
-
-<dt><a name="USE_WATCHDOG"></a>use_watchdog</dt>
-<dd>
-<p>
-���Ϊ on���򼤻�Ź���Ĭ��Ϊ off��
-</p>
-</dd>
-
-<dt><a name="TRUSTED_SERVERS"></a>trusted_servers</dt>
-<dd>
-<p>
-  ���ڼ���������ӵĿ��ŷ������б���ÿ̨����������������Ӧ ping��
-  ָ��һϵ���ö��ŷָ��ķ������б������� "hostA,hostB,hostC"��
-</p>
-</dd>
-
-<dt><a name="DELEGATE_IP"></a>delegate_IP</dt>
-<dd>
-<p>
-	ָ���ͻ��˷�������Ӧ�÷������ȣ����ӵ��� pgpool-II ������ IP ��ַ(VIP)��
-	��һ�� pgpool �ӱ��ýڵ��л�����Ծ״̬��pgpool ��ʹ����� VIP��
-</p>
-</dd>
-
-<dt><a name="WD_HOSTNAME"></a>wd_hostname</dt>
-<dd>
-<p>
-	ָ�����ڻ����صĿ��Ź����̵��������� IP ��ַ��
-</p>
-</dd>
-
-<dt><a name="WD_PORT"></a>wd_port</dt>
-<dd>
-<p>
-	ָ�����ڻ����صĿ��Ź����̵Ķ˿ںš�
-</p>
-</dd>
-
-<dt><a name="WD_INTERVAL"></a>wd_interval</dt>
-<dd>
-<p>
-  ������ָ�� pgpoll-II ���ڴ����ļ������λΪ�루���ڻ���� 1 �����֣���
-</p>
-</dd>
-
-<dt><a name="PING_PATH"></a>ping_path</dt>
-<dd>
-<p>
-  ������ָ�����ڼ�����η������� ping �����·����ֻ��Ҫ����·������ "/bin" �� 
-</p>
-</dd>
-
-<dt><a name="IFCONFIG_PATH"></a>ifconfig_path</dt>
-<dd>
-<p>
-	T������ָ�������л� IP ��ַ�����������·���� ֻ����·�������� "/sbin"��
-</p>
-</dd>
-
-<dt><a name="IF_UP_CMD"></a>if_up_cmd</dt>
-<dd>
-<p>
-	������ָ��һ������������������ IP����������Ͳ��������� "ifconfig eth0:0 inet $_IP_$ netmask 255.255.255.0"��
-	���� $_IP_$ �ᱻ delegate_IP ���õ�ֵ�滻�� 
-</p>
-</dd>
-
-<dt><a name="IF_DOWN_CMD"></a>if_down_cmd</dt>
-<dd>
-<p>
-	������ָ��һ����������ͣ������ IP����������Ͳ��������� "ifconfig eth0:0 down"��
-</p>
-</dd>
-
-<dt><a name="ARPING_PATH"></a>arping_path</dt>
-<dd>
-<p>
-	������ָ���ڷ������� IP �л������ڷ���һ�� ARP ��������������·����ֻ����·�������� "/usr/sbin"��
-</p>
-</dd>
-
-<dt><a name="ARPING_CMD"></a>arping_cmd</dt>
-<dd>
-<p>
-	������ָ��һ�����������ڷ������� IP �л������ڷ���һ�� ARP ��������
-	��������Ͳ��������� "arping -U $_IP_$ -w 1"������ $_IP_$ �ᱻ delegate_IP ���õ�ֵ�滻��
-</p>
-</dd>
-
-<dt><a name="WD_LIFE_POINT"></a>wd_life_point</dt>
-<dd>
-<p>
-  ��ȷ�� pgpool-II ʧЧʱ�����Դ�����һ�����ڻ���� 1 �����֣���
-</p>
-</dd>
-
-<dt><a name="WD_LIFECHECK_QUERY"></a>wd_lifecheck_query</dt>
-<dd>
-<p>
-  ���ڼ�� pgpool-II �Ĳ�ѯ��Ĭ��Ϊ "SELECT 1"��
-</p>
-</dd>
-
-</dl>
-
-<h3>����صķ�����</h3>
-<dl>
-<dt><a name="OTHER_PGPOOL_HOSTNAME"></a>other_pgpool_hostname<font color="red">0</font></dt>
-<dd>
-<p>
-	ָ����Ҫ��ص� pgpool-II �����������������ڷ���/���ղ�ѯ�����ݰ���ͬʱҲ�ǿ��Ź��ı�ʶ��
-	����������������ֱ�ʾ��������š����� 0 ��ʼ�� 
-</p>
-</dd>
-
-<dt><a name="OTHER_PGPOOL_PORT"></a>other_pgpool_port<font color="red">0</font></dt>
-<dd>
-<p>
-	ָ����Ҫ��ص� pgpool-II �������� pgpool ����Ķ˿ڡ����ڲ�ѯģʽ��wd_lifecheck_query ָ���Ĳ�ѯ��佫�����͵�����˿ڡ�
-	����������������ֱ�ʾ��������š����� 0 ��ʼ�� 
-</p>
-</dd>
-
-<dt><a name="OTHER_WD_PORT"></a>other_wd_port<font color="red">0</font></dt>
-<dd>
-<p>
-	ָ����Ҫ��ص� pgpool-II �������Ŀ��Ź��Ķ˿ڡ�
-	����������������ֱ�ʾ��������š����� 0 ��ʼ�� 
-</p>
-</dd>
-</dl>
-</body>
-</html>
diff --git a/doc/where_to_send_queries.odg b/doc/where_to_send_queries.odg
deleted file mode 100644
index 6f33571b4..000000000
Binary files a/doc/where_to_send_queries.odg and /dev/null differ
diff --git a/doc/where_to_send_queries.pdf b/doc/where_to_send_queries.pdf
deleted file mode 100644
index 7d962054c..000000000
Binary files a/doc/where_to_send_queries.pdf and /dev/null differ


[parent: cd56fe83de29]