Skip site navigation (1) Skip section navigation (2)

Re: Core team statement on replication in PostgreSQL

From: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Smith <gsmith(at)gregsmith(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org, Bruce Momjian <bruce(at)momjian(dot)us>, David Fetter <david(at)fetter(dot)org>, Josh Berkus <josh(at)agliodbs(dot)com>, Marko Kreen <markokr(at)gmail(dot)com>
Subject: Re: Core team statement on replication in PostgreSQL
Date: 2008-05-30 19:16:29
Message-ID: 200805301516.30049.xzilla@users.sourceforge.net (view raw or flat)
Thread:
Lists: pgsql-advocacypgsql-hackers
On Friday 30 May 2008 01:10:20 Tom Lane wrote:
> Greg Smith <gsmith(at)gregsmith(dot)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

In response to

Responses

pgsql-hackers by date

Next:From: Robert TreatDate: 2008-05-30 19:16:34
Subject: Re: Core team statement on replication in PostgreSQL
Previous:From: Zdenek KotalaDate: 2008-05-30 19:02:51
Subject: move hash_any from hash to utils

pgsql-advocacy by date

Next:From: Robert TreatDate: 2008-05-30 19:16:34
Subject: Re: Core team statement on replication in PostgreSQL
Previous:From: Guido BarosioDate: 2008-05-30 18:55:39
Subject: Re: World largest database runs on PostgreSQL?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group