I have added the attached documentation patch to explain how
master/slave can be combined with pgpool to avoid the problems with
non-deterministic functions. You can read more details here:
http://momjian.us/main/blogs/pgblog/2010.html#April_26_2010_2
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
Index: doc/src/sgml/high-availability.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/high-availability.sgml,v
retrieving revision 1.62
diff -c -c -r1.62 high-availability.sgml
*** doc/src/sgml/high-availability.sgml 21 Apr 2010 03:32:53 -0000 1.62
--- doc/src/sgml/high-availability.sgml 26 Apr 2010 18:06:37 -0000
***************
*** 199,205 ****
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">
and <xref linkend="sql-commit-prepared">.
--- 199,209 ----
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. 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">.