Re: Additional options for Sync Replication

On Sun, Mar 27, 2011 at 10:45 PM, Simon Riggs <simon(at)2ndquadrant(dot)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

4) Release - when only bugs are fixed

So the question becomes, what is a new feature versus a behaviour
change to an existing feature or a bug-fix. These are subjective
questions with a lot of room for ambiguity. Is this a new feature? Is
this existing code broken or unusable in some way that we don't want
to release and have to support?

We're not in a vacuum here and we all see Tom reworking major portions
of the collation patch while you're being told you can't squeak this
relatively small feature in. But the collation behaviour is something
we'll have to deal with and support for years and will have trouble
changing in subsequent versions without compatibility issues. This
behaviour is clearly something that can be added onto in subsequent
versions and the existing feature set is usable as it is.

Also, for what it's worth I prefer thinking of
synchronous_commit/synchronous_replication as one big multi-way
variable:

synchronous_commit = memory | disk | replica-memory | replica-disk |
replica-visible

--
greg