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

Re: Core team statement on replication in PostgreSQL

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

> 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.  If that's the
> case, it would be nice to explicitly spell out what that was to deflect
> criticism of the planned prioritization.

There's a very simple reason to prioritize the synchronous log shipping first; 
NTT may open source their solution and we'll get it a lot sooner than the 
other components.  

That is, we expect that synch log shipping is *easier* than read-only slaves 
and will get done sooner.  Since there are quite a number of users who could 
use this, whether or not they can run queries on the slaves, why not ship 
that feature as soon as its done?

There's also a number of issues with using the currently log shipping method 
for replication.  In additon to the previously mentioned setup pains, there's 
the 16MB chunk size for shipping log segments, which is fine for data 
warehouses but kind of sucks for a web application with a 3GB database which 
may take 2 hours to go though 16MB.  So we have to change the shipping method 
anyway, and if we're doing that, why not work on synch?

Mind you, if someone wanted to get started on read-only slaves *right now* I 
can't imagine anyone would object.  There's a number of problems to solve 
with recovery mode, table locking etc. that can use some work even before we 
deal with changes to log shipping, or XID writeback or any of the other 
issues.  So, volunteers?

-- 
Josh Berkus
PostgreSQL @ Sun
San Francisco

In response to

Responses

pgsql-hackers by date

Next:From: Euler Taveira de OliveiraDate: 2008-05-30 02:22:11
Subject: Re: Initial max_connections for initdb on FreeBSD.
Previous:From: Joshua D. DrakeDate: 2008-05-30 01:25:49
Subject: Re: Core team statement on replication in PostgreSQL

pgsql-advocacy by date

Next:From: Andrew SullivanDate: 2008-05-30 02:38:28
Subject: Re: Core team statement on replication in PostgreSQL
Previous:From: Joshua D. DrakeDate: 2008-05-30 01:25:49
Subject: Re: Core team statement on replication in PostgreSQL

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