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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
