Re: Core team statement on replication in PostgreSQL

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