On Tue, Mar 29, 2011 at 3:49 AM, Dimitri Fontaine <dimi...@2ndquadrant.fr> wrote: >> It would be better to just support it (recv|fsync|apply), >> or no syncrep at all. Syncrep is incomplete without it. > > Agreed.
I have trouble viewing the idea that it would be better not to ship sync rep at all than to add more features to it as a serious proposal. Presumably, anyone who is sad that sync rep doesn't have all of the options they might want would be even sadder to hear that we went through a whole development cycle and ended up with nothing at all. Even if we did agree to take this patch, there will certainly be more features that someone might want and not have, such as the ability to sync with multiple standbys at once. > More than that, I think we should evaluate this patch on a cost/benefit > ratio, rather than trying to apply to it all those procedural fences > that we don't have, and that we don't have the size to benefit from. As a community, we've adopted a development plan that proceeds in cycles. For the last several releases, we have had four CommitFests in each release cycle, followed by a feature freeze and eventually by beta and final release. It's certainly a valid question to ask how well that procedure has served us. It does not seem likely to me that we can continue to produce quality releases if we don't at some point cut off the flow of new features into the source tree and work on stabilizing the code we've already got, and I believe the point for that was agreed by a large number of developers who sat in a room at PGCon last year to be on or about February 15th. We ended up extending that by a couple of weeks, to make sure that we had a process that was FAIR: we didn't want patches that had been in the pipeline for a very long time to get postponed to 9.2 because no committer had had a chance to work on them yet. However, we also bumped MANY patches to 9.2 because they weren't in sufficiently good shape soon enough. If we accept this patch now because a bunch of people say they really, really want it, isn't that unfair to the people to whom we've already said "sorry, the deadline has passed"? Of course, there is always going to be some gray area. I argued for committing the replication_timeout patch because I believe the fact that we haven't got that feature is almost a bug - it interferes significantly with the usability of replication in general, and it will be an even more serious problem with sync rep, where a hung standby connection will not only mean that nothing is replicating but also that no write transactions can be processed at all. However, you could make the opposite argument - that it's really a new feature - and therefore we ought not to commit it. So far no one has taken that position, but it's certainly a reasonable argument. Likewise, there is ongoing discussion on the collations thread about which of those changes are necessary for this release, and which ones are things that ought to be postponed to a future release. I haven't gotten too involved in those discussions because I don't really understand the underlying issues, but I think that's an important discussion. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
