public inbox for [email protected]
help / color / mirror / Atom feedFrom: Jim C. Nasby <[email protected]>
To: Bruce Momjian <[email protected]>
Cc: Dawid Kuroczko <[email protected]>
Cc: [email protected]
Cc: [email protected]
Subject: Re: [HACKERS] Replication documentation addition
Date: Thu, 26 Oct 2006 13:27:33 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
On Thu, Oct 26, 2006 at 11:59:57AM -0400, Bruce Momjian wrote:
> Jim C. Nasby wrote:
> > 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.
>
> The problem is that we do have some solutions in our code, like doing
> data partitioning in the application, warm standby, or using a shared
> disk for failover, so how do we spell that out? I say there are
> multiple solutions, but I don't see how I can say that all are external
> and not included.
Good point... how about this?
--
Jim Nasby [email protected]
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
Index: doc/src/sgml/failover.sgml
===================================================================
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/failover.sgml,v
retrieving revision 1.2
diff -c -r1.2 failover.sgml
*** doc/src/sgml/failover.sgml 26 Oct 2006 17:07:03 -0000 1.2
--- doc/src/sgml/failover.sgml 26 Oct 2006 18:26:21 -0000
***************
*** 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,40 ----
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. A few of these solutions are
! provided with PostgreSQL itself, but it would be impractical for the core
! database to handle every scenario. That is why most solutions are implemented
! outside the database. PostgreSQL's unique extensibility is what allows this
! to happen, and 3rd-party solutions should not be thought of as
! <qoute>second-rate</> simply because they are not bundled with the database.
</para>
<para>
Attachments:
[text/plain] patch (1.4K, 2-patch)
download | inline:
Index: doc/src/sgml/failover.sgml
===================================================================
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/failover.sgml,v
retrieving revision 1.2
diff -c -r1.2 failover.sgml
*** doc/src/sgml/failover.sgml 26 Oct 2006 17:07:03 -0000 1.2
--- doc/src/sgml/failover.sgml 26 Oct 2006 18:26:21 -0000
***************
*** 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,40 ----
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. A few of these solutions are
! provided with PostgreSQL itself, but it would be impractical for the core
! database to handle every scenario. That is why most solutions are implemented
! outside the database. PostgreSQL's unique extensibility is what allows this
! to happen, and 3rd-party solutions should not be thought of as
! <qoute>second-rate</> simply because they are not bundled with the database.
</para>
<para>
view thread (117+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: [HACKERS] Replication documentation addition
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox