On Wed, 2011-03-02 at 17:23 +0200, Heikki Linnakangas wrote:
> On 02.03.2011 17:07, Robert Haas wrote:
> > On Wed, Mar 2, 2011 at 9:53 AM, Heikki Linnakangas
> > <heikki.linnakangas@enterprisedb.com> wrote:
> >> On 02.03.2011 12:40, Simon Riggs wrote:
> >>>
> >>> allow_standalone_primary seems to need to be better through than it is
> >>> now, yet neither of us think its worth having.
> >>>
> >>> If the people that want it can think it through a little better then it
> >>> might make this release, but I propose to remove it from this current
> >>> patch to allow us to commit with greater certainty and fewer bugs.
> >>
> >> If you leave it out, then let's rename the feature to "semi-synchronous
> >> replication" or such. The point of synchronous replication is
> >> zero-data-loss, and you don't achieve that with allow_standalone_primary=on.
> >
> > I think that'd just be adding confusion. Replication will still be
> > synchronous; it'll just be more likely to be not happening when you
> > think it is.
>
> The defining property of synchronous replication is that when a
> transaction is acknowledged as committed to the client, it has also been
> replicated to the standby. You don't achieve that with
> allow_standalone_primary=on, plain and simple. That's fine for a lot of
> people, most people don't actually want synchronous replication because
> they're not willing to pay the availability penalty. But IMHO it would
> be disingenuous to call it synchronous replication if you can't achieve
> zero data loss with it.
I agree with some of what you say, but that focuses on one corner case
and not on the whole solution.
Yes, if we pick the allow_standalone_primary=on behaviour AND you are
stupid enough to lose *all* of your sync standbys then you may get data
loss.
What I've spent a lot of time doing is trying to ensure that we never
lose all our sync standbys, via clear recommendation to use multiple
servers AND functionality to allow that the standbys work together to
give true high availability without data loss. The current design allows
for an arbitrary number of potential standby servers so your risk of
data loss can be as many 9s as you care to make it.
Not really bothered what we call it, but if you intend to make a song
and dance about whether it is "proper" or not, then I would object to
that because you're not presenting the full situation.
-- Simon Riggs http://www.2ndQuadrant.com/books/PostgreSQL Development, 24x7 Support, Training and Services
