* Tom Lane <tgl@sss.pgh.pa.us> [080529 20:22]:
> "Joshua D. Drake" <jd@commandprompt.com> writes:
> > I think maybe my actual argument isn't coming through. What I am arguing
> > for is not shipping XY without Z. That is all. (and no, I don't think we
> > should hold up 8.4).
>
> So we should keep all the work out of the tree until every part is done?
> No thanks; especially not when there is a perfectly respectable use-case
> for parts X and Y alone (whether it suits *your* uses or not).
Thank you.
I would be really disappointed if some sort of synchronous WAL shipping
patch was done and considered good, but just not applied because some
semi-related "read only queries while WAL applying" patch wasn't yet
considered done and good...
Then again, the opposite is also true. If someone sat down and did the
hard work and made read-only queries runnable on a slave applying WAL
and the patch was considered done and good, I would be disappointed if it
wasn't applied because the synchronous WAL shipping wasn't done.
Both features are worthy on their own. But the first done should not be
held up because the other is not ready.
But because core specifically mentioned "ease of use" as one of the
goals, I really think the "built-in WAL shipping" should be *their*
focuss first. Having read-only queries that no-one can use (well, sure,
some of us could set it up reliably) isn't that useful to "general
PostgreSQL" community that I think they were thinking of when deciding
on this. But their focus doesn't force anybody interested in other
features to not work on their features. It's an OSS community...
And the fact that NTT had a nice presentation on it means it's
probably actually doable for
8.4:http://www.pgcon.org/2008/schedule/attachments/61_Synchronous%20Log%20Shipping%20Replication.pdf
a.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.
