Re: Core team statement on replication in PostgreSQL - Mailing list pgsql-hackers

From Robert Treat
Subject Re: Core team statement on replication in PostgreSQL
Date
Msg-id 200805291742.17495.xzilla@users.sourceforge.net
Whole thread Raw
In response to Re: Core team statement on replication in PostgreSQL  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Core team statement on replication in PostgreSQL  ("Joshua D. Drake" <jd@commandprompt.com>)
Re: Core team statement on replication in PostgreSQL  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Core team statement on replication in PostgreSQL  (Dimitri Fontaine <dim@hi-media.com>)
List pgsql-hackers
On Thursday 29 May 2008 12:13:20 Bruce Momjian wrote:
> David Fetter wrote:
> > On Thu, May 29, 2008 at 11:58:31AM -0400, Bruce Momjian wrote:
> > > Josh Berkus wrote:
> > > > Publishing the XIDs back to the master is one possibility.  We
> > > > also looked at using "spillover segments" for vacuumed rows, but
> > > > that seemed even less viable.
> > > >
> > > > I'm also thinking, for *async replication*, that we could simply
> > > > halt replication on the slave whenever a transaction passes minxid
> > > > on the master.  However, the main focus will be on synchrounous
> > > > hot standby.
> > >
> > > Another idea I discussed with Tom is having the slave _delay_
> > > applying WAL files until all slave snapshots are ready.
> >
> > Either one of these would be great, but something that involves
> > machines that stay useless most of the time is just not going to work.
>
> Right, the ultimate target is to have the slave be read-only, but we
> need to get the streaming of WAL logs done first.
>

I would have thought the read only piece would have been more important than 
the synchronous piece. In my experience readable slaves is the big selling 
point in both Oracle and MySQL's implementations, and people are not nearly 
as concerned if there is a small asynchronous window.  

It would also be easier to implement on some level; we have already solved the 
asynchronus wal shipping problem, so we would just need to solve the 
read-only bits. For synchronus hot standby, you have to solve both the 
synchronus shipping and the read-only bits. Seems like more work with less 
upside that read-only slaves vs. pitr warm standby we have now. 

Interesting that core views this differently. 

-- 
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL


pgsql-hackers by date:

Previous
From: Mathias Brossard
Date:
Subject: Re: Core team statement on replication in PostgreSQL
Next
From: "Joshua D. Drake"
Date:
Subject: Re: Core team statement on replication in PostgreSQL