Skip site navigation (1) Skip section navigation (2)

Re: Sync Rep Design

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Sync Rep Design
Date: 2010-12-31 01:57:34
Message-ID: 1293760654.1892.29635.camel@ebony (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Thu, 2010-12-30 at 16:47 -0500, Robert Haas wrote:

> > It also does not address the more general (not sync rep specific) problem of
> > how to deal with max_keep_segments which is a wart and I was hoping we could
> > get rid of in 9.1 - but it would require a real standby registration or at
> > least standby management possibility on the master not a halfway done one -
> > so do we really need hot_standby_feedback as part of the inital sync-rep
> > patch?
> And this is really the key point on which previous discussions of sync
> rep stalled.  Simon is clearly of the opinion that any system where
> the slaves have an individual identities (aka "standby registration")
> is a bad idea, but the only justification he's offered for that
> position is the assertion that it doesn't allow any added
> functionality.  As you point out, and as has been pointed out before,
> this is not true, but unless Simon has changed his position since the
> last time we discussed this, he will not only refuse to include any
> kind of standby identifier in any of his proposals, but will also
> argue against including any such code even if it is written by someone
> else.  I don't understand why, but that's how it is.
> Synchronous replication would probably be done and committed by now if
> it weren't for this issue.

I'm not very clear what your response has to do with Stefan's comments.

My general perspective is that MySQL released a simple design a year
ahead of us, which should be to our collective shame. I will be working
towards delivering something useful in this release.

Standby registration is complicated and not necessary. If anybody needs
to justify anything, it is the people that claim it is somehow
essential. If you want increased complexity and features, you can have
it, one day, but don't prevent everybody else from benefiting from
simplicity, now. What we do need is performance, otherwise the feature
is mostly unusable for production systems, without splitting your
application into pieces.

I would rather concentrate on a minimal set of functionality that we can
all agree on. To show that, I have gone out of my way to include
features specified by others, including exact names and behaviours of

 Simon Riggs 
 PostgreSQL Development, 24x7 Support, Training and Services

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2010-12-31 01:58:20
Subject: Re: and it's not a bunny rabbit, either
Previous:From: Simon RiggsDate: 2010-12-31 01:38:32
Subject: Re: Sync Rep Design

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group