Update Statement-Based Replication Middleware docs to be more general.

This commit is contained in:
Bruce Momjian 2006-11-21 18:31:57 +00:00
parent dd92a8c33f
commit de597154a8
1 changed files with 10 additions and 10 deletions

View File

@ -1,4 +1,4 @@
<!-- $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>
@ -166,16 +166,16 @@ protocol to make nodes agree on a serializable transactional order.
</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.