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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy pgsql-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

Browse pgsql-advocacy by date

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

Browse pgsql-hackers by date

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