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