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
>