From 132c40424abe3bb8acd551c52c996e15969717b0 Mon Sep 17 00:00:00 2001
From: Bruce Momjian <bruce@momjian.us>
Date: Mon, 26 Apr 2010 19:09:25 +0000
Subject: [PATCH] Document that pgpool can be used with master/slave servers to
avoid problems with non-deterministic functions.
---
doc/src/sgml/high-availability.sgml | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index 766d223bd2b..463bac1f480 100644
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.62 2010/04/21 03:32:53 tgl Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.63 2010/04/26 19:09:25 momjian Exp $ -->
<chapter id="high-availability">
<title>High Availability, Load Balancing, and Replication</title>
@@ -199,7 +199,11 @@ protocol to make nodes agree on a serializable transactional order.
SQL queries are broadcast (and not actual modified rows). If
this is unacceptable, either the middleware or the application
must query such values from a single server and then use those
- values in write queries. Also, care must be taken that all
+ values in write queries. Another option is to use this replication
+ option with a traditional master-slave setup, i.e. data modification
+ queries are sent only to the master and are propogated to the
+ slaves via master-slave replication, not by the replication
+ middleware. Care must also be taken that all
transactions either commit or abort on all servers, perhaps
using two-phase commit (<xref linkend="sql-prepare-transaction">
and <xref linkend="sql-commit-prepared">.
--
GitLab