From: Hannu Krosing <hannu@2ndquadrant.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Simon Riggs <simon@2ndquadrant.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Sync Rep Design
Date: Fri, 31 Dec 2010 08:50:43 +0100
Message-ID: <4D1D8B53.7000108@2ndquadrant.com> (raw)
In-Reply-To: <AANLkTi=59VVrA8-LfhRw0V8NAaxp4rP+6HnU+S91fxJb@mail.gmail.com>
References: <1293729972.1892.23804.camel@ebony>
<4D1CC47E.7050207@kaltenbrunner.cc>
<1293735853.1892.24886.camel@ebony>
<4D1CEEAF.8050209@kaltenbrunner.cc>
<AANLkTi=rGTp59iB5Qpf0ymwzn31F0oVOVuVCR_TAMPi5@mail.gmail.com>
<1293760654.1892.29635.camel@ebony>
<AANLkTi=59VVrA8-LfhRw0V8NAaxp4rP+6HnU+S91fxJb@mail.gmail.com>
On 31.12.2010 6:02, Robert Haas wrote:
> On Thu, Dec 30, 2010 at 8:57 PM, Simon Riggs<simon@2ndquadrant.com> wrote:
>> 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.
> I don't feel ashamed of our feature set and I am not out to beat MySQL
> or anyone else, just to deliver the best product that we can.
The key word here is "deliver" . The aim is to "deliver" sync rep, not
"specify, leaving out
controversial details". The registration part has been left out for a
reason - while the
registration itself is easy, deciding all the interactions with already
running replication is
not. Doing just the minimal support for sync rep (need acknowledge from
at least one
standby) and leaving the management of standbys to user enables us to
get to actual
working code instead of a pie-in-the-sky wishlist.
> Our
> community has different interests than the MySQL community and that is
> fine. Still, I don't disagree that we should be aiming at feature
> parity.
>
> <reads MySQL documentation>
>
> I see now that you've tried to design this feature in a way that is
> similar to MySQL's offering, which does have some value. But it
> appears to me that the documentation you've written here is
> substantially similar to the MySQL 5.5 reference documentation. That
> could get us into a world of legal trouble - that documentation is not
> even open source, let alone BSD.
>
> http://dev.mysql.com/doc/refman/5.5/en/replication-semisync.htmlMaybe we should get someone who has not read mysql docs to re-write a
spec in a
"clean room" fashion, by just inspecting code and asking Simon et.al.
>> I would rather concentrate on a minimal set of functionality that we can
>> all agree on.
> Me too; and perhaps your proposal is it. But I think it's a shame we
> didn't put more work into standby registration when we had time to get
> that done.
When you need _just_ the registration, then make a table and two functions
pg_standby_register(name) and pg_standby_unregister(name)
For a little more added functionality add a third one
pg_standby_last_seen(name)
to update last seen timestamp and a script that polls all standbys and
calls this.
> It might not be necessary, but it would have delivered
> some nice functionality that we are now not going to have for 9.1.
There are tons of "nice functionality we are not going to have for 9.1",
lets just not
make this cause even more nice functionality being left out !
---------------------
Hannu Krosing
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: hannu@2ndquadrant.com, robertmhaas@gmail.com, simon@2ndquadrant.com
Subject: Re: Sync Rep Design
In-Reply-To: <4D1D8B53.7000108@2ndquadrant.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox