-<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.5 2006/11/21 18:15:45 momjian Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.6 2006/11/21 18:31:57 momjian Exp $ -->
<chapter id="high-availability">
<title>High Availability and Load Balancing</title>
</para>
<para>
- One limitation of this solution is that functions like
+ If queries are simply broadcast unmodified, functions like
<function>random()</>, <function>CURRENT_TIMESTAMP</>, and
- sequences can have different values on different servers. This
- is because each server operates independently, and because SQL
- queries are broadcast (and not actual modified rows). If this
- is unacceptable, applications must query such values from a
- single server and then use those values in write queries.
- Also, care must be taken that all transactions either commit
- or abort on all servers, perhaps using two-phase commit (<xref
- linkend="sql-prepare-transaction"
+ sequences would have different values on different servers.
+ This is because each server operates independently, and because
+ 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
+ transactions either commit or abort on all servers, perhaps
+ using two-phase commit (<xref linkend="sql-prepare-transaction"
endterm="sql-prepare-transaction-title"> and <xref
linkend="sql-commit-prepared" endterm="sql-commit-prepared-title">.
Pgpool is an example of this type of replication.