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