Re: Core team statement on replication in PostgreSQL

On Thu, 2008-05-29 at 13:37 -0400, Tom Lane wrote:
> David Fetter <david@fetter.org> writes:
> > On Thu, May 29, 2008 at 08:46:22AM -0700, Joshua D. Drake wrote:
> >> The only question I have is... what does this give us that PITR
> >> doesn't give us?
> 
> > It looks like a wrapper for PITR to me, so the gain would be ease of
> > use.
> 
> A couple of points about that:
> 
> * Yeah, ease of use is a huge concern here.  We're getting beat up
> because people have to go find a separate package (and figure out
> which one they want), install it, learn how to use it, etc.  It doesn't
> help that the most mature package is Slony which is, um, not very
> novice-friendly or low-admin-complexity.  I personally got religion
> on this about two months ago when Red Hat switched their bugzilla
> from Postgres to MySQL because the admins didn't want to deal with Slony
> any more.  People want simple.
> 
> * The proposed approach is trying to get to "real" replication
> incrementally.  Getting rid of the loss window involved in file-by-file
> log shipping is step one, 

Actually we can already do better than file-by-file by using
pg_xlogfile_name_offset() which was added sometime in 2006. SkyTools for
example does this to get no more than a few seconds failure window.

Doing this synchronously would be of course better.

probably we should use the same "modes/protocols" as DRBD when
determining when a "sync" wal write is "done"

quote from 
http://www.slackworks.com/~dkrovich/DRBD/usingdrbdsetup.html#AEN76


Table 1. DRBD Protocols

Protocol           Description                A
A write operation is complete as
soon as the data is written to disk
and sent to the network.                B
A write operation is complete as
soon as a reception acknowledgement
arrives.                C
A write operation is complete as
soon as a write acknowledgement
arrives.

There are also additional paramaters you can pass to the disk and net
options. See the drbdsetup man page for additional information

/end quote

> and I suspect that step two is going to be
> fixing performance issues in WAL replay to ensure that slaves can keep
> up.  After that we'd start thinking about how to let slaves run
> read-only queries.  But even without read-only queries, this will be
> a useful improvement for HA/backup scenarios.
> 
>             regards, tom lane
>