Re: Additional options for Sync Replication - Mailing list pgsql-hackers

On Tue, Mar 29, 2011 at 3:49 AM, Dimitri Fontaine
<dimitri@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'thave 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