RubyGems - prestogres - Versions diffs - 0.1.0 - Mend

prestogres 0.1.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (393) hide show

data/.gitignore +4 -0
data/Gemfile +2 -0
data/Gemfile.lock +20 -0
data/LICENSE +202 -0
data/NOTICE +22 -0
data/README.md +217 -0
data/Rakefile +13 -0
data/VERSION +1 -0
data/bin/prestogres +254 -0
data/config/pcp.conf.sample +28 -0
data/config/pgpool.conf +678 -0
data/config/pool_hba.conf +84 -0
data/config/pool_passwd +0 -0
data/config/postgresql.conf +2 -0
data/ext/.gitignore +6 -0
data/ext/depend +26 -0
data/ext/extconf.rb +4 -0
data/ext/prestogres_config.c +12 -0
data/pgpool2/.gitignore +36 -0
data/pgpool2/AUTHORS +4 -0
data/pgpool2/COPYING +12 -0
data/pgpool2/ChangeLog +1 -0
data/pgpool2/INSTALL +1 -0
data/pgpool2/Makefile.am +159 -0
data/pgpool2/Makefile.in +1187 -0
data/pgpool2/NEWS +4960 -0
data/pgpool2/README +1 -0
data/pgpool2/README.euc_jp +1 -0
data/pgpool2/README.online-recovery +62 -0
data/pgpool2/TODO +103 -0
data/pgpool2/ac_func_accept_argtypes.m4 +85 -0
data/pgpool2/aclocal.m4 +1088 -0
data/pgpool2/c-compiler.m4 +134 -0
data/pgpool2/c-library.m4 +325 -0
data/pgpool2/child.c +2097 -0
data/pgpool2/config.guess +1532 -0
data/pgpool2/config.h.in +332 -0
data/pgpool2/config.sub +1640 -0
data/pgpool2/configure +15752 -0
data/pgpool2/configure.in +392 -0
data/pgpool2/depcomp +522 -0
data/pgpool2/doc/basebackup.sh +17 -0
data/pgpool2/doc/pgpool-de.html +4220 -0
data/pgpool2/doc/pgpool-en.html +5738 -0
data/pgpool2/doc/pgpool-fr.html +4118 -0
data/pgpool2/doc/pgpool-ja.css +198 -0
data/pgpool2/doc/pgpool-ja.html +11279 -0
data/pgpool2/doc/pgpool-zh_cn.html +4445 -0
data/pgpool2/doc/pgpool.css +280 -0
data/pgpool2/doc/pgpool_remote_start +13 -0
data/pgpool2/doc/recovery.conf.sample +117 -0
data/pgpool2/doc/tutorial-en.html +707 -0
data/pgpool2/doc/tutorial-ja.html +422 -0
data/pgpool2/doc/tutorial-memqcache-en.html +325 -0
data/pgpool2/doc/tutorial-memqcache-ja.html +370 -0
data/pgpool2/doc/tutorial-memqcache-zh_cn.html +322 -0
data/pgpool2/doc/tutorial-watchdog-en.html +306 -0
data/pgpool2/doc/tutorial-watchdog-ja.html +343 -0
data/pgpool2/doc/tutorial-watchdog-zh_cn.html +301 -0
data/pgpool2/doc/tutorial-zh_cn.html +537 -0
data/pgpool2/doc/watchdog.png +0 -0
data/pgpool2/doc/wd-en.html +236 -0
data/pgpool2/doc/wd-en.jpg +0 -0
data/pgpool2/doc/wd-ja.html +219 -0
data/pgpool2/doc/wd-ja.jpg +0 -0
data/pgpool2/doc/wd-zh_cn.html +201 -0
data/pgpool2/doc/where_to_send_queries.odg +0 -0
data/pgpool2/doc/where_to_send_queries.pdf +0 -0
data/pgpool2/general.m4 +166 -0
data/pgpool2/getopt_long.c +200 -0
data/pgpool2/getopt_long.h +44 -0
data/pgpool2/install-sh +251 -0
data/pgpool2/ltmain.sh +8406 -0
data/pgpool2/m4/libtool.m4 +7360 -0
data/pgpool2/m4/ltoptions.m4 +368 -0
data/pgpool2/m4/ltsugar.m4 +123 -0
data/pgpool2/m4/ltversion.m4 +23 -0
data/pgpool2/m4/lt~obsolete.m4 +92 -0
data/pgpool2/main.c +2971 -0
data/pgpool2/md5.c +444 -0
data/pgpool2/md5.h +28 -0
data/pgpool2/missing +360 -0
data/pgpool2/mkinstalldirs +40 -0
data/pgpool2/parser/Makefile.am +50 -0
data/pgpool2/parser/Makefile.in +559 -0
data/pgpool2/parser/copyfuncs.c +3310 -0
data/pgpool2/parser/gram.c +39100 -0
data/pgpool2/parser/gram.h +940 -0
data/pgpool2/parser/gram.y +13408 -0
data/pgpool2/parser/gramparse.h +74 -0
data/pgpool2/parser/keywords.c +32 -0
data/pgpool2/parser/keywords.h +39 -0
data/pgpool2/parser/kwlist.h +425 -0
data/pgpool2/parser/kwlookup.c +88 -0
data/pgpool2/parser/list.c +1156 -0
data/pgpool2/parser/makefuncs.c +518 -0
data/pgpool2/parser/makefuncs.h +83 -0
data/pgpool2/parser/memnodes.h +79 -0
data/pgpool2/parser/nodes.c +29 -0
data/pgpool2/parser/nodes.h +609 -0
data/pgpool2/parser/outfuncs.c +5790 -0
data/pgpool2/parser/parsenodes.h +2615 -0
data/pgpool2/parser/parser.c +262 -0
data/pgpool2/parser/parser.h +46 -0
data/pgpool2/parser/pg_class.h +158 -0
data/pgpool2/parser/pg_config_manual.h +273 -0
data/pgpool2/parser/pg_list.h +352 -0
data/pgpool2/parser/pg_trigger.h +147 -0
data/pgpool2/parser/pg_wchar.h +492 -0
data/pgpool2/parser/pool_memory.c +342 -0
data/pgpool2/parser/pool_memory.h +77 -0
data/pgpool2/parser/pool_parser.h +222 -0
data/pgpool2/parser/pool_string.c +121 -0
data/pgpool2/parser/pool_string.h +37 -0
data/pgpool2/parser/primnodes.h +1280 -0
data/pgpool2/parser/scan.c +4094 -0
data/pgpool2/parser/scan.l +1451 -0
data/pgpool2/parser/scanner.h +120 -0
data/pgpool2/parser/scansup.c +221 -0
data/pgpool2/parser/scansup.h +28 -0
data/pgpool2/parser/snprintf.c +1102 -0
data/pgpool2/parser/stringinfo.c +294 -0
data/pgpool2/parser/stringinfo.h +178 -0
data/pgpool2/parser/value.c +78 -0
data/pgpool2/parser/value.h +62 -0
data/pgpool2/parser/wchar.c +2048 -0
data/pgpool2/pcp.conf.sample +28 -0
data/pgpool2/pcp/Makefile.am +40 -0
data/pgpool2/pcp/Makefile.in +771 -0
data/pgpool2/pcp/libpcp_ext.h +250 -0
data/pgpool2/pcp/md5.c +444 -0
data/pgpool2/pcp/md5.h +28 -0
data/pgpool2/pcp/pcp.c +1652 -0
data/pgpool2/pcp/pcp.h +61 -0
data/pgpool2/pcp/pcp_attach_node.c +172 -0
data/pgpool2/pcp/pcp_detach_node.c +185 -0
data/pgpool2/pcp/pcp_error.c +87 -0
data/pgpool2/pcp/pcp_node_count.c +160 -0
data/pgpool2/pcp/pcp_node_info.c +198 -0
data/pgpool2/pcp/pcp_pool_status.c +166 -0
data/pgpool2/pcp/pcp_proc_count.c +166 -0
data/pgpool2/pcp/pcp_proc_info.c +261 -0
data/pgpool2/pcp/pcp_promote_node.c +185 -0
data/pgpool2/pcp/pcp_recovery_node.c +172 -0
data/pgpool2/pcp/pcp_stop_pgpool.c +179 -0
data/pgpool2/pcp/pcp_stream.c +385 -0
data/pgpool2/pcp/pcp_stream.h +52 -0
data/pgpool2/pcp/pcp_systemdb_info.c +194 -0
data/pgpool2/pcp/pcp_watchdog_info.c +211 -0
data/pgpool2/pcp_child.c +1493 -0
data/pgpool2/pg_md5.c +305 -0
data/pgpool2/pgpool.8.in +121 -0
data/pgpool2/pgpool.conf +553 -0
data/pgpool2/pgpool.conf.sample +666 -0
data/pgpool2/pgpool.conf.sample-master-slave +665 -0
data/pgpool2/pgpool.conf.sample-replication +664 -0
data/pgpool2/pgpool.conf.sample-stream +664 -0
data/pgpool2/pgpool.spec +264 -0
data/pgpool2/pgpool_adm/TODO +7 -0
data/pgpool2/pgpool_adm/pgpool_adm--1.0.sql +85 -0
data/pgpool2/pgpool_adm/pgpool_adm.c +558 -0
data/pgpool2/pgpool_adm/pgpool_adm.control +5 -0
data/pgpool2/pgpool_adm/pgpool_adm.h +46 -0
data/pgpool2/pgpool_adm/pgpool_adm.sql.in +85 -0
data/pgpool2/pool.h +655 -0
data/pgpool2/pool_auth.c +1390 -0
data/pgpool2/pool_config.c +5007 -0
data/pgpool2/pool_config.h +284 -0
data/pgpool2/pool_config.l +3281 -0
data/pgpool2/pool_config_md5.c +29 -0
data/pgpool2/pool_connection_pool.c +812 -0
data/pgpool2/pool_error.c +242 -0
data/pgpool2/pool_globals.c +27 -0
data/pgpool2/pool_hba.c +1723 -0
data/pgpool2/pool_hba.conf.sample +67 -0
data/pgpool2/pool_ip.c +567 -0
data/pgpool2/pool_ip.h +65 -0
data/pgpool2/pool_ipc.h +38 -0
data/pgpool2/pool_lobj.c +242 -0
data/pgpool2/pool_lobj.h +32 -0
data/pgpool2/pool_memqcache.c +3818 -0
data/pgpool2/pool_memqcache.h +268 -0
data/pgpool2/pool_params.c +163 -0
data/pgpool2/pool_passwd.c +249 -0
data/pgpool2/pool_passwd.h +41 -0
data/pgpool2/pool_path.c +193 -0
data/pgpool2/pool_path.h +81 -0
data/pgpool2/pool_process_context.c +247 -0
data/pgpool2/pool_process_context.h +62 -0
data/pgpool2/pool_process_query.c +5001 -0
data/pgpool2/pool_process_reporting.c +1671 -0
data/pgpool2/pool_process_reporting.h +44 -0
data/pgpool2/pool_proto2.c +671 -0
data/pgpool2/pool_proto_modules.c +3524 -0
data/pgpool2/pool_proto_modules.h +185 -0
data/pgpool2/pool_query_cache.c +1020 -0
data/pgpool2/pool_query_context.c +1871 -0
data/pgpool2/pool_query_context.h +105 -0
data/pgpool2/pool_relcache.c +284 -0
data/pgpool2/pool_relcache.h +78 -0
data/pgpool2/pool_rewrite_outfuncs.c +9060 -0
data/pgpool2/pool_rewrite_query.c +715 -0
data/pgpool2/pool_rewrite_query.h +192 -0
data/pgpool2/pool_select_walker.c +1150 -0
data/pgpool2/pool_select_walker.h +68 -0
data/pgpool2/pool_sema.c +161 -0
data/pgpool2/pool_session_context.c +952 -0
data/pgpool2/pool_session_context.h +203 -0
data/pgpool2/pool_shmem.c +185 -0
data/pgpool2/pool_signal.c +158 -0
data/pgpool2/pool_signal.h +61 -0
data/pgpool2/pool_ssl.c +339 -0
data/pgpool2/pool_stream.c +962 -0
data/pgpool2/pool_stream.h +61 -0
data/pgpool2/pool_system.c +659 -0
data/pgpool2/pool_timestamp.c +1215 -0
data/pgpool2/pool_timestamp.h +38 -0
data/pgpool2/pool_type.h +171 -0
data/pgpool2/pool_worker_child.c +384 -0
data/pgpool2/ps_status.c +404 -0
data/pgpool2/recovery.c +435 -0
data/pgpool2/redhat/pgpool.conf.sample.patch +52 -0
data/pgpool2/redhat/pgpool.init +201 -0
data/pgpool2/redhat/pgpool.sysconfig +7 -0
data/pgpool2/redhat/rpm_installer/basebackup-replication.sh +53 -0
data/pgpool2/redhat/rpm_installer/basebackup-stream.sh +55 -0
data/pgpool2/redhat/rpm_installer/config_for_script +17 -0
data/pgpool2/redhat/rpm_installer/failover.sh +64 -0
data/pgpool2/redhat/rpm_installer/getsources.sh +141 -0
data/pgpool2/redhat/rpm_installer/install.sh +1363 -0
data/pgpool2/redhat/rpm_installer/pgpool_recovery_pitr +47 -0
data/pgpool2/redhat/rpm_installer/pgpool_remote_start +15 -0
data/pgpool2/redhat/rpm_installer/recovery.conf +4 -0
data/pgpool2/redhat/rpm_installer/uninstall.sh +57 -0
data/pgpool2/sample/dist_def_pgbench.sql +73 -0
data/pgpool2/sample/pgpool.pam +3 -0
data/pgpool2/sample/pgpool_recovery +20 -0
data/pgpool2/sample/pgpool_recovery_pitr +19 -0
data/pgpool2/sample/pgpool_remote_start +13 -0
data/pgpool2/sample/replicate_def_pgbench.sql +18 -0
data/pgpool2/sql/insert_lock.sql +15 -0
data/pgpool2/sql/pgpool-recovery/pgpool-recovery.c +280 -0
data/pgpool2/sql/pgpool-recovery/pgpool-recovery.sql.in +19 -0
data/pgpool2/sql/pgpool-recovery/pgpool_recovery--1.0.sql +24 -0
data/pgpool2/sql/pgpool-recovery/pgpool_recovery.control +5 -0
data/pgpool2/sql/pgpool-recovery/uninstall_pgpool-recovery.sql +3 -0
data/pgpool2/sql/pgpool-regclass/pgpool-regclass.c +206 -0
data/pgpool2/sql/pgpool-regclass/pgpool-regclass.sql.in +4 -0
data/pgpool2/sql/pgpool-regclass/pgpool_regclass--1.0.sql +7 -0
data/pgpool2/sql/pgpool-regclass/pgpool_regclass.control +5 -0
data/pgpool2/sql/pgpool-regclass/uninstall_pgpool-regclass.sql +1 -0
data/pgpool2/sql/system_db.sql +38 -0
data/pgpool2/strlcpy.c +85 -0
data/pgpool2/test/C/test_extended.c +98 -0
data/pgpool2/test/jdbc/.cvsignore +2 -0
data/pgpool2/test/jdbc/AutoCommitTest.java +45 -0
data/pgpool2/test/jdbc/BatchTest.java +55 -0
data/pgpool2/test/jdbc/ColumnTest.java +60 -0
data/pgpool2/test/jdbc/CreateTempTableTest.java +48 -0
data/pgpool2/test/jdbc/InsertTest.java +34 -0
data/pgpool2/test/jdbc/LockTest.java +36 -0
data/pgpool2/test/jdbc/PgpoolTest.java +75 -0
data/pgpool2/test/jdbc/README.euc_jp +73 -0
data/pgpool2/test/jdbc/RunTest.java +83 -0
data/pgpool2/test/jdbc/SelectTest.java +37 -0
data/pgpool2/test/jdbc/UpdateTest.java +32 -0
data/pgpool2/test/jdbc/expected/CreateTempTable +1 -0
data/pgpool2/test/jdbc/expected/autocommit +10 -0
data/pgpool2/test/jdbc/expected/batch +1 -0
data/pgpool2/test/jdbc/expected/column +100 -0
data/pgpool2/test/jdbc/expected/insert +1 -0
data/pgpool2/test/jdbc/expected/lock +100 -0
data/pgpool2/test/jdbc/expected/select +2 -0
data/pgpool2/test/jdbc/expected/update +1 -0
data/pgpool2/test/jdbc/pgpool.properties +7 -0
data/pgpool2/test/jdbc/prepare.sql +54 -0
data/pgpool2/test/jdbc/run.sh +6 -0
data/pgpool2/test/parser/.cvsignore +6 -0
data/pgpool2/test/parser/README +32 -0
data/pgpool2/test/parser/expected/copy.out +17 -0
data/pgpool2/test/parser/expected/create.out +64 -0
data/pgpool2/test/parser/expected/cursor.out +37 -0
data/pgpool2/test/parser/expected/delete.out +10 -0
data/pgpool2/test/parser/expected/drop.out +12 -0
data/pgpool2/test/parser/expected/insert.out +13 -0
data/pgpool2/test/parser/expected/misc.out +28 -0
data/pgpool2/test/parser/expected/prepare.out +4 -0
data/pgpool2/test/parser/expected/privileges.out +31 -0
data/pgpool2/test/parser/expected/scanner.out +30 -0
data/pgpool2/test/parser/expected/select.out +89 -0
data/pgpool2/test/parser/expected/transaction.out +38 -0
data/pgpool2/test/parser/expected/update.out +11 -0
data/pgpool2/test/parser/expected/v84.out +37 -0
data/pgpool2/test/parser/expected/v90.out +25 -0
data/pgpool2/test/parser/expected/var.out +22 -0
data/pgpool2/test/parser/input/alter.sql +2 -0
data/pgpool2/test/parser/input/copy.sql +17 -0
data/pgpool2/test/parser/input/create.sql +64 -0
data/pgpool2/test/parser/input/cursor.sql +37 -0
data/pgpool2/test/parser/input/delete.sql +10 -0
data/pgpool2/test/parser/input/drop.sql +12 -0
data/pgpool2/test/parser/input/insert.sql +13 -0
data/pgpool2/test/parser/input/misc.sql +28 -0
data/pgpool2/test/parser/input/prepare.sql +4 -0
data/pgpool2/test/parser/input/privileges.sql +31 -0
data/pgpool2/test/parser/input/scanner.sql +34 -0
data/pgpool2/test/parser/input/select.sql +89 -0
data/pgpool2/test/parser/input/transaction.sql +38 -0
data/pgpool2/test/parser/input/update.sql +11 -0
data/pgpool2/test/parser/input/v84.sql +37 -0
data/pgpool2/test/parser/input/v90.sql +38 -0
data/pgpool2/test/parser/input/var.sql +22 -0
data/pgpool2/test/parser/main.c +96 -0
data/pgpool2/test/parser/parse_schedule +16 -0
data/pgpool2/test/parser/pool.h +13 -0
data/pgpool2/test/parser/run-test +62 -0
data/pgpool2/test/pdo-test/README.euc_jp +58 -0
data/pgpool2/test/pdo-test/SQLlist/test1.sql +3 -0
data/pgpool2/test/pdo-test/SQLlist/test2.sql +3 -0
data/pgpool2/test/pdo-test/collections.inc +11 -0
data/pgpool2/test/pdo-test/def.inc +7 -0
data/pgpool2/test/pdo-test/log.txt +0 -0
data/pgpool2/test/pdo-test/mod/database.inc +36 -0
data/pgpool2/test/pdo-test/mod/def.inc +0 -0
data/pgpool2/test/pdo-test/mod/errorhandler.inc +27 -0
data/pgpool2/test/pdo-test/pdotest.php +11 -0
data/pgpool2/test/pdo-test/regsql.inc +56 -0
data/pgpool2/test/pgpool_setup +898 -0
data/pgpool2/test/regression/README +39 -0
data/pgpool2/test/regression/clean.sh +21 -0
data/pgpool2/test/regression/libs.sh +16 -0
data/pgpool2/test/regression/regress.sh +166 -0
data/pgpool2/test/regression/tests/001.load_balance/test.sh +128 -0
data/pgpool2/test/regression/tests/002.native_replication/PgTester.java +47 -0
data/pgpool2/test/regression/tests/002.native_replication/create.sql +6 -0
data/pgpool2/test/regression/tests/002.native_replication/test.sh +71 -0
data/pgpool2/test/regression/tests/003.failover/expected.r +6 -0
data/pgpool2/test/regression/tests/003.failover/expected.s +6 -0
data/pgpool2/test/regression/tests/003.failover/test.sh +45 -0
data/pgpool2/test/regression/tests/004.watchdog/master.conf +12 -0
data/pgpool2/test/regression/tests/004.watchdog/standby.conf +19 -0
data/pgpool2/test/regression/tests/004.watchdog/test.sh +52 -0
data/pgpool2/test/regression/tests/050.bug58/test.sh +50 -0
data/pgpool2/test/regression/tests/051.bug60/bug.sql +12 -0
data/pgpool2/test/regression/tests/051.bug60/database-clean.sql +6 -0
data/pgpool2/test/regression/tests/051.bug60/database-setup.sql +28 -0
data/pgpool2/test/regression/tests/051.bug60/test.sh +79 -0
data/pgpool2/test/regression/tests/052.do_query/test.sh +44 -0
data/pgpool2/test/regression/tests/053.insert_lock_hangs/test.sh +81 -0
data/pgpool2/test/regression/tests/054.postgres_fdw/test.sh +67 -0
data/pgpool2/test/regression/tests/055.backend_all_down/test.sh +52 -0
data/pgpool2/test/regression/tests/056.bug63/jdbctest2.java +66 -0
data/pgpool2/test/regression/tests/056.bug63/test.sh +47 -0
data/pgpool2/test/regression/tests/057.bug61/test.sh +40 -0
data/pgpool2/test/regression/tests/058.bug68/jdbctest3.java +45 -0
data/pgpool2/test/regression/tests/058.bug68/test.sh +47 -0
data/pgpool2/test/timestamp/expected/insert.out +16 -0
data/pgpool2/test/timestamp/expected/misc.out +3 -0
data/pgpool2/test/timestamp/expected/update.out +6 -0
data/pgpool2/test/timestamp/input/insert.sql +16 -0
data/pgpool2/test/timestamp/input/misc.sql +3 -0
data/pgpool2/test/timestamp/input/update.sql +6 -0
data/pgpool2/test/timestamp/main.c +129 -0
data/pgpool2/test/timestamp/parse_schedule +3 -0
data/pgpool2/test/timestamp/run-test +69 -0
data/pgpool2/version.h +1 -0
data/pgpool2/watchdog/Makefile.am +17 -0
data/pgpool2/watchdog/Makefile.in +505 -0
data/pgpool2/watchdog/test/stab.c +266 -0
data/pgpool2/watchdog/test/test.c +85 -0
data/pgpool2/watchdog/test/wd_child_t.c +87 -0
data/pgpool2/watchdog/test/wd_lifecheck_t.c +87 -0
data/pgpool2/watchdog/test/wd_packet_t.c +87 -0
data/pgpool2/watchdog/test/wd_ping_t.c +20 -0
data/pgpool2/watchdog/watchdog.c +408 -0
data/pgpool2/watchdog/watchdog.h +209 -0
data/pgpool2/watchdog/wd_child.c +444 -0
data/pgpool2/watchdog/wd_ext.h +123 -0
data/pgpool2/watchdog/wd_heartbeat.c +577 -0
data/pgpool2/watchdog/wd_if.c +216 -0
data/pgpool2/watchdog/wd_init.c +126 -0
data/pgpool2/watchdog/wd_interlock.c +347 -0
data/pgpool2/watchdog/wd_lifecheck.c +512 -0
data/pgpool2/watchdog/wd_list.c +429 -0
data/pgpool2/watchdog/wd_packet.c +1159 -0
data/pgpool2/watchdog/wd_ping.c +330 -0
data/pgpool2/ylwrap +223 -0
data/pgsql/presto_client.py +346 -0
data/pgsql/prestogres.py +156 -0
data/pgsql/setup_functions.sql +21 -0
data/pgsql/setup_language.sql +3 -0
data/prestogres.gemspec +23 -0
metadata +496 -0

data/pgpool2/doc/pgpool-fr.html ADDED Viewed

@@ -0,0 +1,4118 @@
+<!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>