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

Re: Core team statement on replication in PostgreSQL

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, 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>, 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 03:02:56
Message-ID: 483F6E60.1090109@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-advocacypgsql-hackers

Josh Berkus wrote:
> 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.  
>   

I have been reading the slides from the NTT presentation, and I now 
really regret not having gone to that talk.

It does seem quite heavy, though, including new background processes, 
heartbeat etc.
> 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?
>   

Indeed.

> 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?
>   

Well, yes, but you do know about archive_timeout, right? No need to wait 
2 hours.


cheers

andrew


In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2008-05-30 05:10:20
Subject: Re: Core team statement on replication in PostgreSQL
Previous:From: Merlin MoncureDate: 2008-05-30 02:59:21
Subject: Re: Core team statement on replication in PostgreSQL

pgsql-advocacy by date

Next:From: Tom LaneDate: 2008-05-30 05:10:20
Subject: Re: Core team statement on replication in PostgreSQL
Previous:From: Merlin MoncureDate: 2008-05-30 02:59:21
Subject: Re: Core team statement on replication in PostgreSQL

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