On Wed, Oct 25, 2006 at 08:42:07PM -0400, Bruce Momjian wrote: > Jim C. Nasby wrote: > > Something else worth doing though is to have a paragraph explaining why > > there's no built-in replication. I don't have time to write something > > right now, but I can do it later tonight if no one beats me to it. > > I thought that was implied in the early paragraph about why there are > many solutions.
I think we should explicitely spell it out, especially considering how many times people ask about it. How about... This multitude of choices is why PostgreSQL does not ship with a replication solution by default; any bundled solution would only satisfy a subset of replication needs. (sorry for the non-standard patch, but anoncvs isn't sync'd up yet). -- Jim Nasby [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
*** failover.sgml.org Thu Oct 26 10:32:45 2006 --- failover.sgml Thu Oct 26 10:55:03 2006 *************** *** 29,35 **** working together. Because there is no single solution that eliminates the impact of the sync problem for all use cases, there are multiple solutions. Each solution addresses this problem in a different way, and ! minimizes its impact for a specific workload. </para> <para> --- 29,37 ---- working together. Because there is no single solution that eliminates the impact of the sync problem for all use cases, there are multiple solutions. Each solution addresses this problem in a different way, and ! minimizes its impact for a specific workload. This multitude of choices is ! why PostgreSQL does not ship with a replication solution by default; any ! bundled solution would only satisfy a subset of replication needs. </para> <para>
---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match