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