On Sun, Mar 27, 2011 at 10:45 PM, Simon Riggs<si...@2ndquadrant.com> wrote:
I was hoping to fine tune/tweak Sync Rep after feedback during beta,
but my understanding of current consensus is that that will be too
late to make user visible changes. So I'm proposing this change now,
before Beta, rather than during Beta.
For what it's worth I think this is a simplification. We have:
1) Development when new features are added
2) Feature freeze - when those features are tweaked and fixed based on
our own testing but no new features added
3) Beta - when features are tweaked and fixed in response to user
suggestions but no new features added
How to say this short: when testing the latest syncrep patches I've
wasted time looking where the recv|fsync|apply api was, to find out it
was gone. *shrug* didn't need it for my use case. But for others it
might well be frustration to find out that what's currently called
syncrep cannot be configured in a way it's suitable, and that they might
have wasted considerable time while finding that out.
The dba interface for recv|fsync|apply seems to be pretty stable, so
supporting that for years should be without risk. How it works under the
hood - the beta period seems like *the* opportunity to attrach mayor
testing from all people waiting to get their hands on syncrep.
An aspect of a good product is that it doesn't waste users time, like a
good piece of code needs little comment. Alarm bells should go off when
somebody is about to write a large piece of documentation writing what a
feature doesn't support. It would be better to just support it
(recv|fsync|apply), or no syncrep at all. Syncrep is incomplete without it.
--
Yeb Havinga
http://www.mgrid.net/
Mastering Medical Data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
