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 200805301516.30049.xzilla@users.sourceforge.net
Whole thread Raw
In response to Re: Core team statement on replication in PostgreSQL  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Core team statement on replication in PostgreSQL  (Hannu Krosing <hannu@krosing.net>)
List pgsql-hackers
On Friday 30 May 2008 01:10:20 Tom Lane wrote:
> Greg Smith <gsmith@gregsmith.com> writes:
> > I fully accept that it may be the case that it doesn't make technical
> > sense to tackle them in any order besides sync->read-only slaves because
> > of dependencies in the implementation between the two.
>
> Well, it's certainly not been my intention to suggest that no one should
> start work on read-only-slaves before we finish the other part.  The
> point is that I expect the log shipping issues will be done first
> because they're easier, and it would be pointless to not release that
> feature if we had it.
>
> But since you mention it: one of the plausible answers for fixing the
> vacuum problem for read-only slaves is to have the slaves push an xmin
> back upstream to the master to prevent premature vacuuming.  The current
> design of pg_standby is utterly incapable of handling that requirement.
> So there might be an implementation dependency there, depending on how
> we want to solve that problem.
>

Sure, but whose to say that after synchronous wal shipping is "finished" it 
wont need a serious re-write due to new needs from the hot standby feature. I 
think going either way carries some risk. 

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


pgsql-hackers by date:

Previous
From: "David E. Wheeler"
Date:
Subject: Shouldn't Natural JOINs Follow FK Constraints?
Next
From: Robert Treat
Date:
Subject: Re: Core team statement on replication in PostgreSQL