On Thu, 2008-05-29 at 13:37 -0400, Tom Lane wrote: > David Fetter <[EMAIL PROTECTED]> 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 > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
